[MAL] > It doesn't have anything to do with icache conflicts or > other esoteric magic at dye-level. The reason for the slowdown > is that the benchmark uses integers as keys and these have to > go through the whole rich compare machinery to find their way into > the dictionary. But insertdict doesn't do any compares at all (besides C pointer comparison to NULL). There's more than one mystery here. The one I was addressing is why the profiler said *insertdict* got slower. Jeremy's profile did not give any reason to suspect that lookdict got slower (which is where the compares are); to the contrary, it said lookdict got 4.5% *faster* in 2.1. > Please see my other post on the subject -- I think we need > an optimized API especially for checking for equality. Quite possibly, but if Jeremy remains keen to help with investigating timing puzzles, he needs to figure out why his profiling approach is pointing him at the wrong functions. That has long-term value far beyond patching the regression du jour. it's-not-either/or-it's-both-ly y'rs -tim
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