On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed <eternal...@gmail.com> wrote:
> I think there's a fundamental set of points being missed. That may be true, but it is not me who is missing them. > * The Crypto API can be used to access non-cryptographic hashes. Full stop. Irrelevant to my point. I am talking about specific non-cryptographic hashes, and they are not currently in the Crypto API. > * He was comparing CRC32 (a 32-bit non-cryptographic hash, *via the Crypto > API*) against SHA-1 (a 128-bit cryptographic hash, via the Crypto API), and > SHA-1 _still_ won. CRC32 tends to beat the pants off 128-bit non- > cryptographic hashes simply because those require multiple registers to > store the state if nothing else; which makes this a rather strong argument > that _hardware matters a heck of a lot_, quite possibly _more_ than the > algorithm. Again, irrelevant. The Spooky2, CityHash256, and Murmur3 hashes that I am talking about can and do take advantage of CPU architecture. For 128- and 256-bit hashes, one (or more) of those three will be significantly faster than any crypto hash in the Crypto API, regardless of the CPU it is run on. As for the possibility of adding more hash functions to Crypto API for btrfs to use, I do not believe I have argued against it, so I am not sure why you repeated the point. It seems to me that is a discussion that must be had with the maintainer(s) of Crypto API (will they accept additional non-crypto 128- and 256-bit hash functions, etc.) -- 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
