Parallelization on muli-CPU hardware?
nicolas at lehuen.com
Wed Oct 13 03:39:20 CEST 2004
> 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
>>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