But 2x was just with the initial, non-optimized patch. A language like Java seems to perform quite well even with fine-grained locking, so it's possible.
And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.
I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not wanting to deal with the complexity of maintaining the patch. It's a shame because the future is definitely going to have lots of cores, and not all problems are well-suited to multiprocessing.
The difference is that Java's memory model was designed from the ground up to work with multiple threads. Python's semantics are that only 1 thread is running at any point in time. Keeping that illusion while running multiple threads in parallel is what causes the huge overhead. The alternative is to do away with CPython semantics, but that would break a ton of existing code.
>And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.
People want to use Python for lots of CPU bound processes. A big Python niche is numeric and scientific computing.
You say that it is "primarily used for scripting and other non-CPU-bound purposes", but this is also a consequence of it being slow. If it was faster it would open MORE uses. LUA and C# got the games action. Go gets attention on the networking apps end, etc...
And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.
I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not wanting to deal with the complexity of maintaining the patch. It's a shame because the future is definitely going to have lots of cores, and not all problems are well-suited to multiprocessing.