David Beazley <d...@dabeaz.com> added the comment: Here are the results of running the fair.py test on a Mac OS-X system using a "fair" GIL implementation (modified condition variable):
[ Fair GIL, Dual-Core, OS-X ] Sequential execution slow: 5.490943 (0 left) fast: 0.369257 (0 left) Threaded execution slow: 6.122093 (0 left) fast: 6.179179 (0 left) Treaded, balanced execution: fast C: 3.345452 (0 left) fast B: 3.389235 (0 left) fast A: 3.426407 (0 left) Treaded, balanced execution, with quickstop: fast C: 2.557972 (0 left) fast B: 2.558551 (35087 left) fast A: 2.558914 (13142 left) Here is the same test with the original GIL. [Unfair GIL, original implementation] Sequential execution slow: 5.444754 (0 left) fast: 0.361340 (0 left) Threaded execution slow: 5.542008 (0 left) fast: 5.225690 (0 left) Treaded, balanced execution: fast C: 1.381929 (0 left) fast B: 1.499969 (0 left) fast A: 1.549571 (0 left) Treaded, balanced execution, with quickstop: fast A: 1.284043 (0 left) fast B: 1.295507 (32490 left) fast C: 1.294981 (274777 left) Please observe that the performance of threads under the "fair" GIL are significantly worse than with the "unfair" GIL. Having studied this in more depth, I have to say that I would much rather have fast-running unfair threads than slow-running fair threads. Although I agree that there are other benefits to fairness, they just aren't enough to compensate for the huge performance hit. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8299> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com