[Python-Dev] tiny optimization in ceval mainloop

Jack Jansen Jack.Jansen@oratrix.com
Fri, 30 Aug 2002 22:21:27 +0200

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 -