[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 -