28 ms·

From the readme: "On a single core of a 2.67GHz Intel Xeon X5550, CityHashCrc256 peaks at about 6.09 bytes/cycle. The other CityHashCrc functions are wrappers

From the readme: "On a single core of a 2.67GHz Intel Xeon X5550, CityHashCrc256 peaks at about 6.09 bytes/cycle. The other CityHashCrc functions are wrappers around CityHashCrc256 and should have similar performance on long strings. CityHash128 peaks at about 4.31 bytes/cycle." I think it's fascinating that they're able to determine the number of bytes their code processes during a single cycle. Does anyone know where to start looking to learn more about how to do that? It reminds me of a comment I think I read on here a month or two ago about the number of pixels that could be processed per cycle with an algorithm implemented on a 500MHz FPGA. Edit: Thanks for the answers!

kevingadd 15y ago
I think it ends up being simple arithmetic once you access your processor's cycle counter. For example, on x86 you used to do it via http://en.wikipedia.org/wiki/Time_Stamp_Counter http://en.wikipedia.org/wiki/Time_Stamp_Counter and that may still work given the right circumstances.
vilda 15y ago
Timestamp counter: https://en.wikipedia.org/wiki/Time_Stamp_Counter https://en.wikipedia.org/wiki/Time_Stamp_Counter The question is how representative this measurement really is. Performance of a hash function depends heavily on memory caches. This looks like a test with many iteration where all data are as close to the processor as possible - hardly a real-life scenario.
- dalke 15y ago
  This is meant for high-speed hashing, so the comparison is this algorithm vs. another high-speed hash algorithm. In that case, how does memory cache affect the comparison between the two algorithms? That is, if the data isn't "as close to the processor" then won't another hash algorithm in this class be affected the same way? The only thing is that it would deemphasize the performance differences, but it wouldn't change that one is faster than another, would it?
martincmartin 15y ago
People have been suggesting the time stamp counter, but that's actually not ideal, because it has a lot of overhead. On my desktop at work (a very beefy Intel Xeon) it adds about 30 cpu cycles. It also drains all the pipelines. For a microbenchmark like this, I find it's usually better to call it in a loop 1,000,000 times, and compute the total time. That's often a "best case" scenario, where e.g. the cpu doesn't need to decode the instructions every iteration because they fit in appropriate cache. But it avoids the overhead of the timestamp counter.
jedbrown 15y ago
Note that this chip, when fitted with DDR3-1333, has a theoretical peak system bandwidth of 32 GB/s (achievable peak will be somewhat lower). This hash, running on a single core, claims to process 16.2 GB/s. There are 4 cores (8 threads) on the X5550, so the hash is already limited by memory bandwidth.

kevingadd 15y ago

I think it ends up being simple arithmetic once you access your processor's cycle counter. For example, on x86 you used to do it via http://en.wikipedia.org/wiki/Time_Stamp_Counter http://en.wikipedia.org/wiki/Time_Stamp_Counter and that may still work given the right circumstances.

vilda 15y ago

Timestamp counter: https://en.wikipedia.org/wiki/Time_Stamp_Counter https://en.wikipedia.org/wiki/Time_Stamp_Counter The question is how representative this measurement really is. Performance of a hash function depends heavily on memory caches. This looks like a test with many iteration where all data are as close to the processor as possible - hardly a real-life scenario.

dalke 15y ago
This is meant for high-speed hashing, so the comparison is this algorithm vs. another high-speed hash algorithm. In that case, how does memory cache affect the comparison between the two algorithms? That is, if the data isn't "as close to the processor" then won't another hash algorithm in this class be affected the same way? The only thing is that it would deemphasize the performance differences, but it wouldn't change that one is faster than another, would it?

martincmartin 15y ago

People have been suggesting the time stamp counter, but that's actually not ideal, because it has a lot of overhead. On my desktop at work (a very beefy Intel Xeon) it adds about 30 cpu cycles. It also drains all the pipelines. For a microbenchmark like this, I find it's usually better to call it in a loop 1,000,000 times, and compute the total time. That's often a "best case" scenario, where e.g. the cpu doesn't need to decode the instructions every iteration because they fit in appropriate cache. But it avoids the overhead of the timestamp counter.

jedbrown 15y ago

Note that this chip, when fitted with DDR3-1333, has a theoretical peak system bandwidth of 32 GB/s (achievable peak will be somewhat lower). This hash, running on a single core, claims to process 16.2 GB/s. There are 4 cores (8 threads) on the X5550, so the hash is already limited by memory bandwidth.