On Nov 9, 1:45 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Martin Vilcans" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > | But that's not what my question was about. It was about whether it > | would make sense to, on the same python installation, select between > | the GIL and fine-grained locks at startup. Because even if the locks > | slows down the interpreter, if they let you utilize a 32 core CPU, it > | may not be so bad anymore. Or am I missing something? > > 1. The need for some group to develop and maintain what anounts to a forked > version of CPython.
That's pretty much what I'm doing. > 2. If micro-locked Python ran, say, half as fast, then you can have a lot > of IPC (interprocess communition) overhead and still be faster with > multiple processes rather than multiple threads. Of course you'd be faster still if you rewrote key portions in C. That's usually not necessary though, so long as Python gives a roughly constant overhead compared to C, which in this case would be true so long as Python scaled up near 100% with the number of cores/threads. The bigger question is one of usability. We could make a usability/ performance tradeoff if we had more options, and there's a lot that can give good performance, but at this point they all offer poor to moderate usability, none having good usability. The crux of the "multicore crisis" is that lack of good usability. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list
