Author dabeaz
Recipients beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, r.david.murray, techtonik, torsten
Date 2010-04-19.01:59:03
SpamBayes Score 0.000612063
Marked as misclassified No
Message-id <1271642346.65.0.693982607664.issue8299@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-04-19 01:59:06dabeazsetrecipients: + dabeaz, loewis, beazley, pitrou, kristjan.jonsson, techtonik, r.david.murray, flox, torsten
2010-04-19 01:59:06dabeazsetmessageid: <1271642346.65.0.693982607664.issue8299@psf.upfronthosting.co.za>
2010-04-19 01:59:04dabeazlinkissue8299 messages
2010-04-19 01:59:03dabeazcreate