[issue8299] Improve GIL in 2.7

David Beazley report at bugs.python.org
Sat Apr 17 05:18:11 CEST 2010

David Beazley <dave at dabeaz.com> added the comment:

I'm not trying to be a pain here, but do you have any explanation as to why, with fair scheduling, the observed execution time of multiple CPU-bound threads is substantially worse than with unfair scheduling?

>From your own benchmarks, consider this result (Fair scheduling)

Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)

Versus this result with unfair scheduling:

Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)

If I'm reading this right, it takes the three threads with fair locking almost twice as long to complete (1.01s) as the three threads with unfair locking (0.55s) .  If so, why would I want fair locking?   Wouldn't I want the solution that offers the fastest overall execution time?


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list