Tim Peters wrote: > > [MAL] > > Looks like Jeremy's machine has a problem or this is the result > > of different compiler optimizations. > > Are you using an AMD chip? They have different cache behavior than the > Pentium I expect Jeremy is using. Different flavors of Pentium also have > different cache behavior. If the slowdown his box reports in insertdict is > real (which I don't know), cache effects are the most likely cause (given > that the code has not changed at all). Yes, I ran the tests on an AMK K6 233. Don't know about the internal cache size or their specific cache strategy, but since much of today's performance is achieved via cache strategies, this would be a possible explanation. > > On my machine using the same compiler and optimization settings > > I get the following figure for DictCreation (2.1a1 vs. 2.0): > > > > DictCreation: 1869.35 ms 12.46 us +8.77% > > > > That's below noise level (+/-10%). > > Jeremy saw "about 15%". So maybe that's just *loud* noise <wink>. > > noise-should-be-measured-in-decibels-ly y'rs - tim Hmm, that would introduce a logarithmic scale to these benchmarks ... perhaps not a bad idea :-) BTW, I've added a special test for string key and float keys to the benchmark. The results are surprising: string keys are 100% faster than float keys. Part of this is certainly due to the string key optimizations. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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