John Williams wrote: > On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed <eternal...@gmail.com> > wrote: >> Actually, I said "Sure" here, but this isn't strictly true. At some >> point, you're more memory-bound than CPU-bound, and with CPU intrinsic >> instructions (like SPARC and recent x86 have for SHA) you're often past >> that. Then, you're not going to see any real difference - and the >> accelerated cryptographic hashes may even win out, because the intrinsics >> may be faster (less stuff of the I$, pipelined single instruction beating >> multiple simpler instructions, etc) than the software non-cryptographic >> hash. > > In practice, I am skeptical whether any 128- or 256-bit crypto hashes > will be as fast as the non-crypto hashes I mentioned, even on CPUs > with specific instructions for the crypto hashes. The non-crypto > hashes can (and do) take advantage of special CPU instructions as > well. > > But even if true that the crypto hashes approach the speed of > non-crypto hashes on certain CPUs, that does not provide a strong > argument for using the crypto hashes, since on the common x64 CPUs, > the non-crypto hashes I mentioned are significantly faster than the > equivalent crypto hashes. > > So, you have some rare architectures where the crypto hashes may > almost be as fast as the non-crypto, and common CPUs where the > non-crypto are much faster. That makes the non-crypto hash functions I > mentioned the obvious choice in the vast majority of systems.
And as I said upthread, one benefit of the Crypto API is that the filesystem developers _no longer have to choose_. By using the shash or ahash interface to the Crypto API, the _user_ can choose *any* hash the kernel supports. And the default is (and will almost certainly continue to be) crc32, so the user would need to specify a hash anyway - making whether some other non- cryptographic hash is the "obvious choice" a completely moot point. -- 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
