Dual Core outlook

[Xavier Morel]

malv wrote:
> Of course, multiprocessing has been used for many years but this always
> involved a much higher level of sophistication on the part of the
> designers. This point seems to be largely hidden from the public,
> ignorant and semi-ignorant, by the chip manufacturers.
> Will new languages see the light rendering the spreading of
> applications over many processors quasi transparent?
> What is the outlook for Python? Would Ironpython with .net do better?
> What about talk by the Java lobby that Java would be very much suited
> for taking advantage of dual-core? Is there any thruth to this?
> 
Python has support for OS threads, but it also has the GIL (a global 
lock from the interpreter). This means that Python behaves the same way 
Java or C# do as far as threads are concerned but for one field: 
multiprocessor (or multicore) situations.

While C# or Java can execute two threads of the same process on two 
separate cores/processors Python can't.

This means that you can't choke a multiprocessor/multicores machine with 
Python threads, and that if you want to scale in a 
multiprocessor/multicore environment (e.g. make use of all the available 
cores/processors) you have to use processes not threads (e.g. you have 
to launch multiple instances of the Python interpreter, each one having 
the ability to execute on a different core/processor).

Now the question is: do you want to do it? Do you have several extremely 
demanding computational threads? If yes, then Python probably isn't what 
you need (unless you implement your computations in specific C modules 
and get rid of the GIL issue). If not (a single computational thread and 
several low-resources GUI/network/whatever threads), it's a non-issue.