[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):
Thanks!
[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.
Regards
Antoine.
More information about the Python-Dev
mailing list