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 amount of time >> each >> individual run takes? > > Increasing the number of rounds (-n) is probably better. > Also, if you are on a laptop or a modern desktop machine, check that > CPU > frequency scaling is disabled before running any benchmark (on Linux, > "cpufreq-set -g performance" does the trick). I don't think there is any way to stop cpu frequency scalling on mac os x. Also comparing 2.6 rc1 to system python 2.5 is not fair either (does anyone really knows how apple compiled its python?). Also the performance of 2 diferent processor lines on different os insert a fair amount of variables to any comparison. 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. -- Leonardo Santagada santagada at gmail.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4