linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Martin Willi <martin@strongswan.org>,
	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 15:30:39 +0100	[thread overview]
Message-ID: <CAHmME9oQ-Yj2WWuvNj1KNm=d4+PgnVFOusnh8HG0=yYWdi2UXQ@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu80EVN-_aHPSYUu=0TvFJERBMKFvQS-gce3z_jx=X7www@mail.gmail.com>

On Thu, Dec 12, 2019 at 3:26 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Thu, 12 Dec 2019 at 14:47, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > On Thu, Dec 12, 2019 at 2:08 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > >
> > > 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.
> >
> > Oh, you asked for numbers. I just fired up an Armada 370/XP and am
> > seeing a 8% increase in performance on calls to the update function.
>
> It would help if we could get some actual numbers. I usually try to
> capture the performance delta for a small set of block sizes that are
> significant for the use case at hand, e.g., like so [0], and also
> include blocksizes that are not 2^n. If the change improves the
> general case without causing any significant regressions elsewhere, I
> don't think we need to continue this debate.

I'm not sure I understand why the 32x32 performance discussion is even
happening in the first place. The new 32x32 code most certainly
doesn't make anything worse. It most likely makes some things better
in some places -- 8% on that machine I fired up, maybe more and maybe
less other places. But who even cares? The principle advantage of this
patchset is the 64x64 code, and I think we gain something else,
immeasurable, by having parallel and comparable implementations.
Please, let's not turn this into another pointless debate.

  reply	other threads:[~2019-12-12 14:30 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
2019-12-12 13:46       ` Jason A. Donenfeld
2019-12-12 14:26         ` Ard Biesheuvel
2019-12-12 14:30           ` Jason A. Donenfeld [this message]
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='CAHmME9oQ-Yj2WWuvNj1KNm=d4+PgnVFOusnh8HG0=yYWdi2UXQ@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=ard.biesheuvel@linaro.org \
    --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).