This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dabeaz
Recipients beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, r.david.murray, techtonik, torsten
Date 2010-04-16.11:21:26
SpamBayes Score 0.00025349096
Marked as misclassified No
Message-id <1271416888.97.0.561783906683.issue8299@psf.upfronthosting.co.za>
In-reply-to
Content
I've attached a test "fair.py" that gives an example of the fair CPU scheduling issue.  In this test, there are two threads, one of which has fast-running ticks, one of which has slow-running ticks.  

Here is their sequential performance (OS-X, Python 2.6):

slow: 5.71
fast: 0.32

Here is their threaded performance (OS-X, Python 2.6.4):

slow : 5.99
fast : 6.04    (Notice : Huge jump in execution, unfair CPU)

Here is their threaded performance using the Py3K New GIL:

slow : 5.96
fast : 0.67    (Notice : Fair CPU use--time only doubled)

Using Linux with semaphores gives no benefit here.  The fast code is stalled in the same way.   For example: here are my Linux results (Ubuntu 8.10, Python-2.6.4, dual-core, using semaphores):

Sequential:
    slow : 6.24
    fast : 0.59
Threaded:
    slow : 6.40
    fast : 6.69    (even slower than the slow code!)
History
Date User Action Args
2010-04-16 11:21:29dabeazsetrecipients: + dabeaz, loewis, beazley, pitrou, kristjan.jonsson, techtonik, r.david.murray, flox, torsten
2010-04-16 11:21:28dabeazsetmessageid: <1271416888.97.0.561783906683.issue8299@psf.upfronthosting.co.za>
2010-04-16 11:21:27dabeazlinkissue8299 messages
2010-04-16 11:21:27dabeazcreate