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, techtonik, torsten
Date 2010-04-11.12:22:03
SpamBayes Score 2.2018828e-07
Marked as misclassified No
Message-id <1270988525.5.0.297197736712.issue8299@psf.upfronthosting.co.za>
In-reply-to
Content
I must be missing something, but why, exactly would you want multiple CPU-bound threads to yield every 100 ticks?   Frankly, that sounds like a horrible idea that is going to hammer your system with excessive context switching overhead and cache performance problems---an effect that you, yourself have actually observed.   The results of ccbench also show worse performance for the round-robin GIL because of this.

Although the legacy GIL signals every 100  ticks, threads do not context switch that rapidly.  In fact, on single CPU systems, they context switch at about the same rate as the system time-slice (5-10 milliseconds on most systems).     The new GIL implemented by Antoine also does not rapidly switch CPU-bound threads.

Again, I must be missing something, but I don't see how this round-robin GIL and all of this forced thread switching is anything that you would ever want--especially for CPU-bound threads. It seems to go against just about every design goal that people usually have for schedulers (especially the goal of minimizing context switching overhead).

Again, maybe I'm just being dense and missing something.
History
Date User Action Args
2010-04-11 12:22:05dabeazsetrecipients: + dabeaz, loewis, beazley, pitrou, kristjan.jonsson, techtonik, flox, torsten
2010-04-11 12:22:05dabeazsetmessageid: <1270988525.5.0.297197736712.issue8299@psf.upfronthosting.co.za>
2010-04-11 12:22:04dabeazlinkissue8299 messages
2010-04-11 12:22:03dabeazcreate