Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: Paul Jones <paul@pauljones.id.au>
Cc: "Peter Becker" <floyd.net@gmail.com>,
	"Holger Hoffstätte" <holger@applied-asynchrony.com>,
	"Linux BTRFS Mailinglist" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 0/4] Support xxhash64 checksums
Date: Fri, 23 Aug 2019 19:08:45 +0200	[thread overview]
Message-ID: <20190823170845.GD17075@angband.pl> (raw)
In-Reply-To: <SYCPR01MB5086BAB60D850EBC8FE046E49EA40@SYCPR01MB5086.ausprd01.prod.outlook.com>

On Fri, Aug 23, 2019 at 09:43:22AM +0000, Paul Jones wrote:
> > > Am Do., 22. Aug. 2019 um 16:41 Uhr schrieb Holger Hoffstätte
> > > <holger@applied-asynchrony.com>:
> > > > but how does btrfs benefit from this compared to using crc32-intel?
> > >
> > > As i know, crc32c  is as far as ~3x faster than xxhash. But xxHash was
> > > created with a differend design goal.
> > > If you using a cpu without hardware crc32 support, xxHash provides you
> > > a maximum portability and speed. Look at arm, mips, power, etc. or old
> > > intel cpus like Core 2 Duo.
> > 
> > I've got a modified version of smhasher
> > (https://github.com/PeeJay/smhasher) that tests speed and cryptographics
> > of various hashing functions.
> 
> I forgot to add xxhash32
>  
> Crc32 Software -  379.91 MiB/sec
> Crc32 Hardware - 7338.60 MiB/sec
> XXhash64 Software - 12094.40 MiB/sec
> XXhash32 Software - 6060.11 MiB/sec
> 
> Testing done on a 1st Gen Ryzen. Impressive numbers from XXhash64.

Newest biggest Threadripper (2990WX, no 3* version released yet):
crc32      -   492.75 MiB/sec
crc32hw    -  9447.37 MiB/sec
crc64      -  1959.51 MiB/sec
xxhash32   -  7479.29 MiB/sec
xxhash64   - 14911.58 MiB/sec

An old Skylake (i7-6700):
crc32      -   359.32 MiB/sec
crc32hw    - 21119.68 MiB/sec
crc64      -  1656.34 MiB/sec
xxhash32   -  5989.87 MiB/sec
xxhash64   - 11949.41 MiB/sec

Cascade Lake (0000%@):
crc32hw 1.92× as fast as xxhash64.

So you want crc32hw on Intel, xxhash64 on AMD.

crc32 also allows going back to old kernels; the improved collision
resistance of xxhash64 is not a reason as if you intend to dedupe you want
a crypto hash so you don't need to verify.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋  The root of a real enemy is an imaginary friend.
⠈⠳⣄⠀⠀⠀⠀

  reply	other threads:[~2019-08-23 17:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 11:40 [PATCH v2 0/4] Support xxhash64 checksums Johannes Thumshirn
2019-08-22 11:40 ` [PATCH v2 1/4] btrfs: turn checksum type define into a enum Johannes Thumshirn
2019-08-22 11:40 ` [PATCH v2 2/4] btrfs: create structure to encode checksum type and length Johannes Thumshirn
2019-08-22 12:11   ` Johannes Thumshirn
2019-08-22 13:22   ` [PATCH v2.1] " Johannes Thumshirn
2019-08-22 11:40 ` [PATCH v2 3/4] btrfs: use xxhash64 for checksumming Johannes Thumshirn
2019-08-22 11:40 ` [PATCH v2 4/4] btrfs: sysfs: export supported checksums Johannes Thumshirn
2019-08-22 12:28 ` [PATCH v2 0/4] Support xxhash64 checksums Holger Hoffstätte
2019-08-22 12:54   ` Johannes Thumshirn
2019-08-22 15:40   ` Peter Becker
2019-08-23  9:38     ` Paul Jones
2019-08-23  9:43       ` Paul Jones
2019-08-23 17:08         ` Adam Borowski [this message]
2019-08-26 12:27           ` Austin S. Hemmelgarn
2019-08-27  0:33             ` Adam Borowski

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=20190823170845.GD17075@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=floyd.net@gmail.com \
    --cc=holger@applied-asynchrony.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=paul@pauljones.id.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox