From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:52464 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932094AbaLAUKE (ORCPT ); Mon, 1 Dec 2014 15:10:04 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XvXIJ-0005Ti-6j for linux-btrfs@vger.kernel.org; Mon, 01 Dec 2014 21:10:03 +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 ; Mon, 01 Dec 2014 21:10:03 +0100 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Dec 2014 21:10:03 +0100 To: linux-btrfs@vger.kernel.org From: Alex Elsayed Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option Date: Mon, 01 Dec 2014 12:08:36 -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: Alex Elsayed wrote: > John Williams wrote: >> 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. > > Sure. 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.