[Python-Dev] Reworking the GIL (original) (raw)
Collin Winter collinw at gmail.com
Mon Oct 26 22:50:14 CET 2009
- Previous message: [Python-Dev] Reworking the GIL
- Next message: [Python-Dev] One obvious way to do interning [Was: Retrieve an arbitrary element from a set without removing it]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Oct 26, 2009 at 2:43 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
Collin Winter <collinw gmail.com> writes: [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: iterativecount: 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 "iterativecount" results. Since iterativecount 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 agree those numbers are out of line with the others and make no sense. I've run it with two threads several times and the results are consistent on this machine. I'm digging into it a bit more.
Collin
- Previous message: [Python-Dev] Reworking the GIL
- Next message: [Python-Dev] One obvious way to do interning [Was: Retrieve an arbitrary element from a set without removing it]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]