Parallelization on muli-CPU hardware?

Nicolas Lehuen nicolas at lehuen.com
Wed Oct 13 03:38:33 CEST 2004


Aahz wrote:
> BTW, Nicolas, it'd be nice if you did not post quoted-printable.  I'm
> leaving the crud in so you can see it.

I write non-ASCII emails, since I'm french (using accentuated characters 
and all that), what is the encoding you would suggest me to use ? AFAIK, 
quoted-printable is a standard encoding (though a poor one). The MUA I 
used may have chosed a bad encoding, since it was Outlook Express. At 
home, I use Thunderbird 0.8, tell me if you feel better with the 
encoding it uses.

> In article <416bd75f$0$10909$afc38c87 at news.easynet.fr>,
> Nicolas Lehuen <nicolas.lehuen at thecrmcompany.com> wrote:
> 
>>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.
> 
> 
> Python itself cannot, but there's nothing preventing anyone from writing
> numeric extensions that release the GIL.

There is nothing preventing anyone from writing a new language from 
scratch, either. What I was suggesting was that we could try to make 
Python a more thread-friendly language, so that we could write more 
CPU-efficient code in the new context of multicore or multi-CPU machines 
  without having to revert to a low-level language like C.

If only I could tell the Python Interpreter 'OK, this bit of Python code 
is thread-safe, so you don't need to hold the GIL on it', maybe I could 
be more efficient, but as of today, this is a thing that can only be 
done in C, not in Python. Of course, being able to release the GIL from 
Python code is not a true solution. A true solution would be to get rid 
of the GIL itself.

Regards,

Nicolas



More information about the Python-list mailing list