From: Alex Elsayed <eternaleye@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option
Date: Mon, 01 Dec 2014 15:05:19 -0800 [thread overview]
Message-ID: <m5is7h$peq$1@ger.gmane.org> (raw)
In-Reply-To: CAJBj3venQGosBDUrKicGK1qgymBEBF=VWSiJjQiPpnis+Rrhpg@mail.gmail.com
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed <eternaleye@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.
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...
next prev parent reply other threads:[~2014-12-01 23:05 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 5:23 [RFC PATCH] Btrfs: add sha256 checksum option Liu Bo
2014-11-24 5:23 ` [RFC PATCH] Btrfs-progs: support sha256 checksum algorithm Liu Bo
2014-11-24 8:23 ` [RFC PATCH] Btrfs: add sha256 checksum option Holger Hoffstätte
2014-11-24 18:55 ` Duncan
2014-11-24 19:34 ` John Williams
2014-11-25 10:30 ` Liu Bo
2014-11-25 10:52 ` Daniel Cegiełka
2014-11-25 23:17 ` John Williams
2014-11-26 12:50 ` Holger Hoffstätte
2014-11-26 17:53 ` John Williams
2014-11-25 10:28 ` Liu Bo
2014-11-24 20:07 ` Chris Mason
2014-11-24 20:58 ` Hugo Mills
2014-11-25 3:04 ` Qu Wenruo
2014-11-25 5:13 ` Zygo Blaxell
2014-11-25 11:30 ` Liu Bo
2014-11-26 13:36 ` Brendan Hide
2014-11-25 16:47 ` David Sterba
2014-11-25 19:45 ` Bardur Arantsson
2014-11-26 13:38 ` Brendan Hide
2014-11-26 13:58 ` Austin S Hemmelgarn
2014-12-01 18:37 ` David Sterba
2014-12-01 20:35 ` Austin S Hemmelgarn
2014-12-01 20:51 ` John Williams
2014-12-01 23:23 ` Alex Elsayed
2014-12-15 18:47 ` David Sterba
2014-11-25 16:39 ` David Sterba
2014-11-27 3:52 ` Liu Bo
2014-12-01 18:51 ` David Sterba
2014-11-29 20:38 ` Alex Elsayed
2014-11-29 21:00 ` John Williams
2014-11-29 21:07 ` Alex Elsayed
2014-11-29 21:21 ` John Williams
2014-11-29 21:27 ` Alex Elsayed
2014-12-01 12:39 ` Austin S Hemmelgarn
2014-12-01 17:22 ` John Williams
2014-12-01 17:42 ` Austin S Hemmelgarn
2014-12-01 17:49 ` John Williams
2014-12-01 19:28 ` Alex Elsayed
2014-12-01 19:34 ` Alex Elsayed
2014-12-01 20:26 ` Austin S Hemmelgarn
2014-12-01 19:58 ` John Williams
2014-12-01 20:04 ` Alex Elsayed
2014-12-01 20:08 ` Alex Elsayed
2014-12-01 20:46 ` John Williams
2014-12-01 22:56 ` Alex Elsayed
2014-12-01 23:05 ` Alex Elsayed [this message]
2014-12-01 23:37 ` John Williams
2014-12-01 23:46 ` Alex Elsayed
2014-12-02 0:03 ` John Williams
2014-12-02 0:15 ` Alex Elsayed
2014-12-02 0:30 ` John Williams
2014-12-02 0:34 ` Alex Elsayed
2014-12-02 0:11 ` John Williams
2014-12-01 23:48 ` John Williams
2014-12-02 0:06 ` Alex Elsayed
2014-12-02 0:10 ` Alex Elsayed
2014-12-02 0:16 ` John Williams
2014-12-02 0:28 ` Christoph Anton Mitterer
2014-12-02 0:43 ` Alex Elsayed
2014-12-02 0:53 ` Christoph Anton Mitterer
2014-12-02 1:25 ` Alex Elsayed
2014-12-02 1:32 ` Alex Elsayed
2014-11-30 22:51 ` Christoph Anton Mitterer
2014-11-30 22:59 ` Christoph Anton Mitterer
2014-11-30 23:05 ` Dimitri John Ledkov
2014-12-01 2:55 ` Christoph Anton Mitterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='m5is7h$peq$1@ger.gmane.org' \
--to=eternaleye@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.