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@[...].com>         
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -


_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev