Three weeks ago, Antoine Pitrou posted the pybench results
for 2.6 trunk:
http://mail.python.org/pipermail/python-dev/2008-August/081951.html
The big discovery in those results were TryExcept being 48% slower,
but there was a patch in the bug tracker to improve things. I've
re-run the tests to
A.M. Kuchling amk at amk.ca writes:
Bad news: the big slowdowns are:
[snip]
I don't get the same results, but there can be significant variations between
two pybench runs. Did use the same compiler and the same flags for both Python
versions?
___
On Sat, 13 Sep 2008 08:03:50 -0400, A.M. Kuchling [EMAIL PROTECTED] wrote:
Three weeks ago, Antoine Pitrou posted the pybench results
for 2.6 trunk:
http://mail.python.org/pipermail/python-dev/2008-August/081951.html
The big discovery in those results were TryExcept being 48% slower,
but there
A.M. Kuchling wrote:
Antoine, your Recursion results were actually about the same (+2.2%)
from 2.5 to 2.6, so this big slowdown is novel. I wonder if these
tests are simply slower on MacOS for some reason (compiler, CPU cache
size, etc.). Does anyone see similar results? Any idea what might
The change to universal binaries, perhaps?
That shouldn't really matter - the machine code should still be the
same, and it should all get loaded at program startup. IOW, startup
and imports may get slower, but otherwise, it should have no impact.
Regards,
Martin
Nick Coghlan ncoghlan at gmail.com writes:
That said, I'm seeing big enough swings in the percentages between runs
that I'd like to get some tips on how to smooth out the variations -
e.g. will increasing the warp factor increasing the amount of time each
individual run takes?
Increasing
On Sep 13, 2008, at 1:03 PM, Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
That said, I'm seeing big enough swings in the percentages between
runs
that I'd like to get some tips on how to smooth out the variations -
e.g. will increasing the warp factor increasing the
On Sat, Sep 13, 2008 at 6:05 PM, Leonardo Santagada [EMAIL PROTECTED] wrote:
I would sugest compiling 2.5 and 2.6 from source, run the benchmark x times
and take the smallest time of each test (so os and cpu scalling don't
influence so much the benchmark) and then comparing the results.
I
