On Thu, Feb 19, 2009 at 7:16 PM, Paul Rubin <http> wrote: > 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.
Actually, Mono supports IronPython so it will work on M-a-c, L-i-n-u-x, S-o-l-a-r-i-s, and possibly even W-i-i and P-l-a-y-s-t-a-t-i-o-n-3. > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list
