From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:34987 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932557AbaLAXFf (ORCPT ); Mon, 1 Dec 2014 18:05:35 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xva29-0001xP-2R for linux-btrfs@vger.kernel.org; Tue, 02 Dec 2014 00:05:33 +0100 Received: from 50.245.141.77 ([50.245.141.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Dec 2014 00:05:33 +0100 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Dec 2014 00:05:33 +0100 To: linux-btrfs@vger.kernel.org From: Alex Elsayed Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option Date: Mon, 01 Dec 2014 15:05:19 -0800 Message-ID: References: <1416806586-18050-1-git-send-email-bo.li.liu@oracle.com> <20141125163905.GJ26471@twin.jikos.cz> <547C618C.8020201@gmail.com> <547CA870.9040904@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: linux-btrfs-owner@vger.kernel.org List-ID: John Williams wrote: > On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed > 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. Incidentally, you can be 'skeptical' all you like - per Austin's message upthread, he was testing the Crypto API. Thus, skeptical as you may be, hard evidence shows that SHA-1 was equal to or faster than CRC32, which is unequivocally simpler and faster than CityHash (though CityHash comes close). And the CPUs in question are *not* particularly rare - Intel since Sandy Bridge or so, the majority of SPARC systems, a goodly number of ARM systems via coprocessors...