Parallelization on muli-CPU hardware?

Nicolas Lehuen nicolas at
Wed Oct 13 03:39:20 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>,
 > Nicolas Lehuen <nicolas.lehuen at> 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.



More information about the Python-list mailing list