John Williams wrote: > On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed <eternal...@gmail.com> wrote: >> And I'm not sure what is "convoluted" or "incorrect" about saying "Look, >> empirical evidence!" > > No empirical evidence of the speed of SpookyHash or CityHash versus > SHA-1 was cited. The only empirical data mentioned was on an > UltraSPARC CPU, and did not include any SpookyHash or CityHash > measurements, and yet you made a claim about the speeds on Intel and > ARM CPUs.
There's a thing called the transitive property. When CRC32 is faster than SpookyHash and CityHash (while admittedly weaker), and SHA-1 on SPARC is faster than CRC32, there are comparisons that can be made. And what I've been trying to say this whole time is not some point about an individual architecture. It's that the flat assertion that "CityHash/SpookyHash/etc is always faster" is _unwarranted_, as hardware acceleration _has a huge effect_. On SPARC, it's empirically enough for SHA-1 to match CRC32. On ARMv8, it brings SHA-1 from 4-8 cycles per byte down to _2_. On Intel, when the Skylake SHA extensions land, it will likely have an enormous impact as well. Broad, sweeping generalizations are great - so long as they are _properly qualified_. For instance, I would agree *wholeheartedly* that a good software implementation of CityHash/SpookyHash/etc would beat the *pants* off a good software implementation of SHA-1. No question. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
