3 ms·

> It's much slower than AES based hashes. I must have misinterpreted the following: > So the fastest hash functions on x86_64 without quality problems are: >

> It's much slower than AES based hashes. I must have misinterpreted the following: > So the fastest hash functions on x86_64 without quality problems are: > > - wyhash > - t1ha > - [...] I interpreted that to be an ordered list, saying that wyhash was the fastest. But looking at the actual table I am confused. There are MB/s numbers and cycles/hash numbers. In cycles/hash wyhash appears to beat all FarmHash variants, but in MiB/s it is slower than some of them. I don't understand why these two performance measures would not track perfectly, since the CPUs should be running a constant number of cycles/second.

stcredzero 8y ago
I don't understand why these two performance measures would not track perfectly, since the CPUs should be running a constant number of cycles/second. x86 isn't RISC and not all operations take the same number of cycles. Also, the code might have different levels of possible parallelism and might impact the pipeline differently. Comp Sci education for the low level basics is often completely neglected nowadays. This should be freshman year stuff. I'm certainly not an expert, myself, just familiar with the issues. (Know enough to know what you don't know.)
- haberman 8y ago
  > x86 isn't RISC and not all operations take the same number of cycles. Yes but it doesn't say instructions per hash, it says cycles per hash. Unless some kind of frequency scaling is going on, the number of cycles per second should be very consistent. If bytes/hash is held constant and cycles/second is constant, then MiB/second and cycles/hash should be exact inverses. I don't understand why this is not the case in these tables. > Also, the code might have different levels of possible parallelism and might impact the pipeline differently. Again this can affect the number of instructions being retired, but not the number of cycles. A cycle is a cycle, regardless of how much work is actually being accomplished. > Comp Sci education for the low level basics is often completely neglected nowadays. This should be freshman year stuff. I'm a low-level junkie who lives in godbolt.org and Agner Fog's tables, writes JIT compilers, and does FPGA design for fun on the side. It's possible that I'm mistaken here, but I do have a fair amount of background in this.
  - ncmncm 8y ago
    I wonder if the first number is sustained, pipelined rate for big values, and the second number is cycles for the first iteration, still assuming everything is in L1 cache. Those would be the useful numbers.

stcredzero 8y ago

I don't understand why these two performance measures would not track perfectly, since the CPUs should be running a constant number of cycles/second. x86 isn't RISC and not all operations take the same number of cycles. Also, the code might have different levels of possible parallelism and might impact the pipeline differently. Comp Sci education for the low level basics is often completely neglected nowadays. This should be freshman year stuff. I'm certainly not an expert, myself, just familiar with the issues. (Know enough to know what you don't know.)

haberman 8y ago
> x86 isn't RISC and not all operations take the same number of cycles. Yes but it doesn't say instructions per hash, it says cycles per hash. Unless some kind of frequency scaling is going on, the number of cycles per second should be very consistent. If bytes/hash is held constant and cycles/second is constant, then MiB/second and cycles/hash should be exact inverses. I don't understand why this is not the case in these tables. > Also, the code might have different levels of possible parallelism and might impact the pipeline differently. Again this can affect the number of instructions being retired, but not the number of cycles. A cycle is a cycle, regardless of how much work is actually being accomplished. > Comp Sci education for the low level basics is often completely neglected nowadays. This should be freshman year stuff. I'm a low-level junkie who lives in godbolt.org and Agner Fog's tables, writes JIT compilers, and does FPGA design for fun on the side. It's possible that I'm mistaken here, but I do have a fair amount of background in this.
- ncmncm 8y ago
  I wonder if the first number is sustained, pipelined rate for big values, and the second number is cycles for the first iteration, still assuming everything is in L1 cache. Those would be the useful numbers.