Nick Maclaren wrote: > as the ones that you have to play for threaded programs. Yes, I know > that it is a bit Irish for the best way to use a shared memory system > to be to not share memory, but that's how it is.
Thank you for clearing that up. In any case, this means that Python can happily keep its GIL, as the CPU bound 'HPC' tasks for which the GIL does matter should be done using multiple processes (not threads) anyway. That leaves threads as a tool for programming certain i/o tasks and maintaining 'responsive' user interfaces, for which the GIL incidentally does not matter. I wonder if too much emphasis is put on thread programming these days. Threads may be nice for programming web servers and the like, but not for numerical computing. Reading books about thread programming, one can easily get the impression that it is 'the' way to parallelize numerical tasks on computers with multiple CPUs (or multiple CPU cores). But if threads are inherently designed and implemented to stay idle most of the time, that is obviously not the case. I like MPI. Although it is a huge API with lots of esoteric functions, I only need to know a handfull to cover my needs. Not to mention the fact that I can use MPI with Fortran, which is frowned upon by computer scientists but loved by scientists and engineers specialized in any other field. -- http://mail.python.org/mailman/listinfo/python-list
