On 2009-08-19, Stefan Behnel wrote:
> Dennis Lee Bieber wrote:
>> If they are number crunchers (CPU-bound) and don't make use of
>> binary extension libraries that release the GIL (for the most common
>> Python implementation), they'll run faster being called in sequence
>> since you won't h
sturlamolden wrote:
> On 18 Aug, 11:41, Stefan Behnel wrote:
>
>> I think the canonical answer is to use the threading module or
>> (preferably) the multiprocessing module, which is new in Py2.6.
>>
>>
http://docs.python.org/library/threading.htmlhttp://docs.python.org/library/multiprocessing.h
On 19 Aug, 05:27, Dave Angel wrote:
> But if you do it that way, it's slower than sequential. And if you have
> a multi-core processor, or two processors, or ... then it gets much
> slower yet, and slows down other tasks as well.
>
> With the current GIL implementation, for two CPU-bound tasks
On 18 Aug, 11:41, Stefan Behnel wrote:
> I think the canonical answer is to use the threading module or (preferably)
> the multiprocessing module, which is new in Py2.6.
>
> http://docs.python.org/library/threading.htmlhttp://docs.python.org/library/multiprocessing.html
>
> Both share a (mostly)
On 19 Aug, 05:34, Hendrik van Rooyen wrote:
> The GIL does apply - I was talking nonsense again. Misread the OP's
> intention.
It depends on what the OP's functions "doStuff1" and "doStuff2"
actually do. If they release the GIL (e.g. make I/O calls) it does not
apply. The GIL only serialize acc
On 19 Aug, 05:27, Dave Angel wrote:
> With the current GIL implementation, for two CPU-bound tasks, you either
> do them sequentially, or make a separate process.
I'd also like to add that most compute-bound code should be delegated
to specialized C libraries, many of which are prewritten. For e
On Wednesday 19 August 2009 10:13:41 Paul Rubin wrote:
> Hendrik van Rooyen writes:
> > Just use thread then and thread.start_new_thread.
> > It just works.
>
> The GIL doesn't apply to threads made like that?!
The GIL does apply - I was talking nonsense again. Misread the OP's
intention.
- He
On 19 Aug, 05:16, sturlamolden wrote:
> You should know about the GIL. It prevents multiple threads form using
> the Python interpreter simultaneously. For parallel computing, this is
> a blessing and a curse. Only C extensions can release the GIL; this
> includes I/0 routines in Python's standar
sturlamolden wrote:
The human brain is bad at detecting
computational bottlenecks though. So it almost always pays off to
write everything in Python first, and use the profiler to locate the
worst offenders.
+1 QOTW
--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoni
On 18 Aug, 13:45, Robert Dailey wrote:
> Really, all I'm trying to do is the most trivial type of
> parallelization. Take two functions, execute them in parallel. This
> type of parallelization is called "embarrassingly parallel", and is
> the simplest form. There are no dependencies between the
Hendrik van Rooyen wrote:
On Tuesday 18 August 2009 22:45:38 Robert Dailey wrote:
Really, all I'm trying to do is the most trivial type of
parallelization. Take two functions, execute them in parallel. This
type of parallelization is called "embarrassingly parallel", and is
the simplest form
On 18 Aug, 11:19, Robert Dailey wrote:
> I'm looking for a way to parallelize my python script without using
> typical threading primitives. For example, C++ has pthreads and TBB to
> break things into "tasks".
In C++, parallelization without "typical threading primitives" usually
means one of t
Hendrik van Rooyen writes:
> Just use thread then and thread.start_new_thread.
> It just works.
The GIL doesn't apply to threads made like that?!
--
http://mail.python.org/mailman/listinfo/python-list
On Tuesday 18 August 2009 22:45:38 Robert Dailey wrote:
> Really, all I'm trying to do is the most trivial type of
> parallelization. Take two functions, execute them in parallel. This
> type of parallelization is called "embarrassingly parallel", and is
> the simplest form. There are no dependenc
Dennis Lee Bieber wrote:
> On Tue, 18 Aug 2009 13:45:38 -0700 (PDT), Robert Dailey wrote:
>> Really, all I'm trying to do is the most trivial type of
>> parallelization. Take two functions, execute them in parallel. This
>> type of parallelization is called "embarrassingly parallel", and is
>> the
On Aug 18, 3:41 pm, Jonathan Gardner
wrote:
> On Aug 18, 11:19 am, Robert Dailey wrote:
>
>
>
>
>
> > I'm looking for a way to parallelize my python script without using
> > typical threading primitives. For example, C++ has pthreads and TBB to
> > break things into "tasks". I would like to see s
On Aug 18, 11:19 am, Robert Dailey wrote:
> I'm looking for a way to parallelize my python script without using
> typical threading primitives. For example, C++ has pthreads and TBB to
> break things into "tasks". I would like to see something like this for
> python. So, if I have a very linear sc
Robert Dailey wrote:
> I'm looking for a way to parallelize my python script without using
> typical threading primitives. For example, C++ has pthreads and TBB to
> break things into "tasks". I would like to see something like this for
> python. So, if I have a very linear script:
>
> doStuff1()
18 matches
Mail list logo
