[Python-Dev] Python parallel benchmark (original) (raw)
Matthieu Brucher matthieu.brucher at gmail.com
Fri May 16 14:20:02 CEST 2008
- Previous message: [Python-Dev] Python parallel benchmark
- Next message: [Python-Dev] Python parallel benchmark
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2008/5/16 Hrvoje Nikšić <hrvoje.niksic at avl.com>:
On Fri, 2008-05-16 at 08:04 -0400, Tom Pinckney wrote: > Here's one example, albeit from a few years ago > > http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/1625465
Thanks for the pointer. I'm not sure I fully understand Konrad Hinsen's concerns, but maybe the problem is that Numpy's "number-crunching" needs to call back into Python frequently. The notion of "releasing the GIL for number-crunching" assumes that the code is structured like this: 1. code that works with python objects ... 2. acquire pointer to a C struct/array ... 3. release GIL 4. work with C objects ("crunch the numbers") without calling any Python code and without touching Python objects or refcounts 5. reacquire GIL If step 4 needs to call into Python frequently, then this strategy won't really work.
Hi,
The current version of Numpy releases as soon as possible the GIL. The usual macros for starting and stopping a GIL release (as advertised in the documentation) are present for every step 4 work, whenever is possible (for instance it is the case for universal functions which are used in a lot of numpy's functions).
Matthieu
French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20080516/14abe80c/attachment.htm>
- Previous message: [Python-Dev] Python parallel benchmark
- Next message: [Python-Dev] Python parallel benchmark
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]