[Jack Jansen] > On vrijdag, augustus 30, 2002, at 06:12 , Tim Peters wrote: Jack, I'm never on vrijdag -- vrijdag is illegal in the US <wink>. > ... > 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. Guido already agreed to try boosting it to 100. > 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. On a pthreads system under 2.3, using semaphores, chances are good it will always switch. But unless you're trying to fake soft realtime, it's a real drag on performance to switch so often We can't out-guess this, because it depends on what the *app* wants. Most apps aren't trying to fake soft realtime, so favoring less frequent switches is a good default. > - 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). You need a model for what it is you're trying to optimize here. I'm just trying to cut useless overheads <wink>.
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