On vrijdag, augustus 30, 2002, at 06:12 , Tim Peters wrote: > [Skip Montanaro] >> ... >> My guess is that the code is avoiding a lot of pointer dereferences. >> Oh, wait a minute. I muffed a bit. I initialized the ticker and >> checkinterval variables to 100. Should have been 10. > > Someone <wink> may wish to question the historical 10 too. A > few weeks ago > on c.l.py, a number of programs were posted showing that, on Linux, the > thread scheduling is such the the *offer* to switch threads every 10 > bytecodes was usually declined: the thread that got the GIL was > overwhelmingly most often the thread that released it, so that > the whole > dance was overwhelmingly most often pure overhead. And it costs! Running pystone without another thread active I get 5500 pystones out of my machine. Running it with another thread active (in a sleep(1000)) I get 4200. After setcheckinterval(100) I'm back up to 5200. For completeness' sake: with no other thread active raising setcheckinterval() doesn't make a difference (it's in the noise, in my measurement it was actually 0.5% slower). We could get a serious speedup for multithreaded programs if we could raise the check interval. Some wild ideas: - Use an exponential (or linear?) backoff. If you attempt to switch and nothing happens you double the check interval, up to a maximum. If you do switch you reset to the minimum. - Combine the above with resetting (to zero? to minimum value if currently >= minimum?) the check interval on anything we know could influence thread schedule (releasing a lock, etc). -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4