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. -- http://mail.python.org/mailman/listinfo/python-list