From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Martin Willi <martin@strongswan.org>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH crypto-next v2 1/3] crypto: poly1305 - add new 32 and 64-bit generic versions
Date: Thu, 12 Dec 2019 14:08:54 +0100 [thread overview]
Message-ID: <CAHmME9ovvwX3Or1ctRH8U5PjpNNMe9ixOZLi3F0vbO9SqA04Ow@mail.gmail.com> (raw)
In-Reply-To: <d55e0390c7187b09f820e123b05df1e5e680df0b.camel@strongswan.org>
Hi Martin,
On Thu, Dec 12, 2019 at 1:03 PM Martin Willi <martin@strongswan.org> wrote:
> Can you provide some numbers to testify that? In my tests, the 32-bit
> version gives me exact the same results.
On 32-bit, if you only call update() once, then the results are the
same. However, as soon as you call it more than once, this new version
has increasing gains. Other than that, they should behave pretty much
identically.
> The 64-bit version is roughly 10% faster. However, what are the
> platforms where the 64-bit version matters? Won't any SIMD version
> outperform the 64-bit version anyway?
Depending on the platform, it's sometimes more than 10% faster. Not
all 64-bit platforms have the luxury of a SIMD version. And not all
code paths wind up hitting the SIMD version, either. The code is very
short and simple -- and compiles shorter than the 32-bit one actually
-- and placed side by side with the new 32-bit one, you can pretty
easily compare them as clean standalone things. I think there's no
good reason for being attached to your old code here; it's all mostly
Andrew's stuff anyway.
Jason
next prev parent reply other threads:[~2019-12-12 13:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 17:09 [PATCH crypto-next v1] crypto: poly1305 - add new 32 and 64-bit generic versions Jason A. Donenfeld
2019-12-11 19:06 ` Eric Biggers
2019-12-11 22:04 ` Jason A. Donenfeld
2019-12-12 9:30 ` [PATCH crypto-next v2 1/3] " Jason A. Donenfeld
2019-12-12 9:30 ` [PATCH crypto-next v2 2/3] crypto: x86_64/poly1305 - add faster implementations Jason A. Donenfeld
2019-12-12 10:26 ` Jason A. Donenfeld
2019-12-12 15:34 ` Martin Willi
2019-12-12 15:39 ` Jason A. Donenfeld
2019-12-15 17:04 ` Andy Polyakov
2019-12-12 9:30 ` [PATCH crypto-next v2 3/3] crypto: arm/arm64/mips/poly1305 - remove redundant non-reduction from emit Jason A. Donenfeld
2019-12-12 14:59 ` Ard Biesheuvel
2019-12-12 12:03 ` [PATCH crypto-next v2 1/3] crypto: poly1305 - add new 32 and 64-bit generic versions Martin Willi
2019-12-12 13:08 ` Jason A. Donenfeld [this message]
2019-12-12 13:46 ` Jason A. Donenfeld
2019-12-12 14:26 ` Ard Biesheuvel
2019-12-12 14:30 ` Jason A. Donenfeld
2019-12-12 15:30 ` Martin Willi
2019-12-12 15:35 ` Jason A. Donenfeld
2019-12-13 3:28 ` Eric Biggers
2019-12-14 8:56 ` Herbert Xu
2019-12-14 12:21 ` Jason A. Donenfeld
2019-12-14 13:05 ` Jason A. Donenfeld
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=CAHmME9ovvwX3Or1ctRH8U5PjpNNMe9ixOZLi3F0vbO9SqA04Ow@mail.gmail.com \
--to=jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=martin@strongswan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).