Eric Dumazet wrote: > Now I am quite confused. > > George said : >> Cycles per byte on 1024 bytes of data: >> Pentium Core 2 Ivy >> 4 Duo Bridge >> SipHash-2-4 38.9 8.3 5.8 >> HalfSipHash-2-4 12.7 4.5 3.2 >> MD5 8.3 5.7 4.7 > > That really was for 1024 bytes blocks, so pretty much useless for our > discussion ? No, they're actually quite relevant, but you have to interpret them correctly. I thought I explained in the text following that table, but let me make it clearer: To find the time to compute the SipHash of N bytes, round (N+17) up to the next multiple of 8 bytes and multiply by the numbers above. To find the time to compute the HalfSipHash of N bytes, round (N+9) up to the next multiple of 4 bytes and multiply by the numbers above. To find the time to compute the MD5 of N bytes, round (N+9) up to the next multiple of 64 bytes and multiply by the numbers above. It's the different rounding rules that make all the difference. For small input blocks, SipHash can be slower per byte yet still faster because it hashes fewer bytes. > Reading your numbers last week, I thought SipHash was faster, but George > numbers are giving the opposite impression. SipHash annihilates the competition on 64-bit superscalar hardware. SipHash dominates the field on 64-bit in-order hardware. SipHash wins easily on 32-bit hardware *with enough registers*. On register-starved 32-bit machines, it really struggles. As I explained, in that last case, SipHash barely wins at all. (On a P4, it actually *loses* to MD5, not that anyone cares. Running on a P4 and caring about performance are mutually exclusive.) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
