[Python-Dev] Reworking the GIL

Antoine Pitrou solipsis at pitrou.net
Mon Oct 26 22:43:50 CET 2009

Collin Winter <collinw <at> gmail.com> writes:
> My results for an 2.4 GHz Intel Core 2 Duo MacBook Pro (OS X 10.5.8):


[the Dave Beazley benchmark]
> The results below are benchmarking py3k as the control, newgil as the
> experiment. When it says "x% faster", that is a measure of newgil's
> performance over py3k's.
> With two threads:
> iterative_count:
> Min: 0.336573 -> 0.387782: 13.21% slower  # I've run this
> configuration multiple times and gotten the same slowdown.
> Avg: 0.338473 -> 0.418559: 19.13% slower

Those numbers are not very in line with the other "iterative_count" results.
Since iterative_count just runs the loop N times in a row, results should be
proportional to the number N ("number of threads").

Besides, there's no reason for single-threaded performance to be degraded since
the fast path of the eval loop actually got a bit streamlined (there is no
volatile ticker to decrement).

> I'd be interested in multithreaded benchmarks with less-homogenous workloads.

So would I.



More information about the Python-Dev mailing list