Terry Reedy <tjre...@udel.edu> writes: > > The slowness itself can be addressed by technical means, such as > > native-code compilation and eliminating the GIL. > > Given that the GIL remains to make Python run faster in the usual (up > to now, at least) case of 1 processor, that seems a strange statement.
We've had this discussion before. The 1-processor slowdown that you refer to comes from replacing the GIL with the blunt instrument of a lock around each reference count operation. That has the advantage of not breaking CPython in a million places, but has the drawback of taking a big performance hit. The long term fix is to replace reference counts with a tracing GC. That is apparently not feasible in the framework of CPython and the many extension modules that have been written for it, so it would have to be accompanied by an implementation switch (e.g. PyPy). Steve Holden has mentioned Jython and Ironpython a few times in this thread. Those are reasonable proofs of the concept of a GIL-less Python, but for various reasons (spelled J-V-M and W-i-n-d-o-w-s) are not all that suitable for many current Python users. -- http://mail.python.org/mailman/listinfo/python-list
