David Beazley <d...@dabeaz.com> added the comment: 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. ---------- _______________________________________ 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
