Parallelization on muli-CPU hardware?

Nicolas Lehuen nicolas.lehuen at thecrmcompany.com
Tue Oct 12 17:08:29 CEST 2004


<exarkun at divmod.com> a écrit dans le message de news:mailman.4751.1097589011.5135.python-list at python.org...
> On Tue, 12 Oct 2004 15:08:46 +0200, "Nicolas Lehuen" <nicolas.lehuen at thecrmcompany.com> wrote:
> > [snip]
> > 
> > Yeah I know this. My point was that when benchmarking single-threaded
> > programs vs multithreaded ones, you have to choose the kind of program
> > you use : CPU-intensive vs IO-intensive. On a single CPU machine,
> > CPU-intensive program will always run better in a single-threaded model.
> > But of course, if you have 2 procs and a nice threading model, you can
> > even do 2 CPU-intensive tasks simultaneously, which Python cannot do if
> > I've understood everything so far.
> 
>   The way to do this is to write an extension module, implement your CPU-intensive tasks, and release the GIL around it.  You can argue that this is not "in Python", but it is possible, widely practiced, supported by the language, developer community, and existing APIs, and lets you adjust Python's threading behavior _specific to your application_, rather than requiring every Python program written by every Python programmer comply with your wishes for the language.
> 
>   Jp

And then I have to tackle all these ugly INCREFs and DECREFs and forget about using a marvellous language. I'm sorry but if I switched from Java to Python, it's not to write C again. I did, though, since I wrote a ternary search tree in C with a SWIG interface to Python, but I won't do it again if I can help it.

Building a language is about bringing a service to the developers. Every language has its limitations, but since it has been proved that other language can handle threading more gracefully, I think the question can be opened without being deferred to another language which is NOT very kind to developers (putting the obligatory "I'm a C h4cker" snobbery aside).

I want to write Python extensions in D !

Regards,
Nicolas




More information about the Python-list mailing list