From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:38653 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752934AbaLBAUF (ORCPT ); Mon, 1 Dec 2014 19:20:05 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XvbCG-00054B-5G for linux-btrfs@vger.kernel.org; Tue, 02 Dec 2014 01:20:04 +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 01:20:04 +0100 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Dec 2014 01:20:04 +0100 To: linux-btrfs@vger.kernel.org From: Alex Elsayed Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option Date: Mon, 01 Dec 2014 16:15:21 -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 3:46 PM, Alex Elsayed 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.