3 ms·
The code looks pretty big, I'm afraid this will affect negatively the instruction cache.
by shin_lao 14y ago
The code looks pretty big, I'm afraid this will affect negatively the instruction cache.
- unwind 14y agoThe announcement claims: On a single core of a 2.67GHz Intel Xeon X5550, CityHashCrc256 peaks at about 5 to 5.5 bytes/cycle. That is pretty impressive, I don't think there's room for a lot of cache missing in that performance envelope.
- kevingadd 14y agoYou have to understand that you can't measure the impact of an algorithm on the icache by just benchmarking it in a loop. If the algorithm being benchmarked fits into icache, it'll perform great in that loop, but when you drop it into your application it could blow everything out of the icache each time you call it and degrade the performance of the rest of your application. It'll also perform worse in your application since it's not remaining in icache either.
- ComputerGuru 14y agoActually, it's rather ironic in that past a certain point, in order to optimize for cache size your lines of code will grow to a huge amount. Case in point: Judy arrays [0] [1]. That is some of the most heavily-optimized code I have ever seen, optimized through-and-through for each and every possible CPU-related factor including the various cache levels, instruction pipeline optimizations, and more. Yet the codebase is positively gargantuan compared to any other implementation of a dynamic array or hash table, mainly as a result of these optimizations. Don't be so quick to judge by LoC. 0: http://judy.sourceforge.net/ http://judy.sourceforge.net/ 1: http://linux.die.net/man/3/judy http://linux.die.net/man/3/judy