Re: [openpgp] AEAD Chunk Size - Performance

[Bart Butler <[e-mail]>]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 28, 2019 12:38 AM, Neal H. Walfield <[e-mail]> wrote:

> Hi Bart,
> 

> Thanks for your feedback.
> 

> On Wed, 27 Feb 2019 22:34:09 +0100,
> Bart Butler wrote:
> 

> > In our AEAD implementation for OpenPGP.js we settled on a default
> > `c` of 12 rather than 8 after some performance benchmarking showed
> > that 256 kiB chunks were more performant for the most common message
> > sizes. Our result was specific to the web crypto API, and therefore
> > specific to OpenPGP.js, but in general libraries may want to use
> > different default sizes depending on implementation details like
> > this.
> 

> I don't need exact numbers, but I'd appreciate it if you could you
> comment on the approximate performance of 256 kiB chunks relative to
> 16 kiB chunks (e.g., factor 1.2 speedup). Of course, if you still
> have the numbers lying around, that would be even better!
> 

> There are two reasons that I find 16 kiB intuitively appealing from
> a performance perspective: a typical L2 cache is about 256 kiB these
> days. So a 16 kiB buffer has a good chance of staying completely in
> L2. Second, on all desktop and mobile operating systems, it is almost
> always reasonable to stack allocate a 16 kiB buffer whereas 256 kiB is
> a bit big.
> 

> From a robustness perspective, I'd like to avoid introducing a
> threshold and having to do something brittle like:
> 

> void *buffer;
> if size > 16 kiB {
> 

>     buffer = malloc(size);
>     

> 

> } else {
> buffer = alloca(size);
> }
> 

> ...
> 

> if size > 16 kiB {
> 

>     free(buffer);
>     

> 

> }
> 

> Unfortunately, I haven't benchmarked this type of thing in the context
> of AEAD so this is just drawing from my limited prior experience with
> sizing these sorts of things.
> 

> :) Neal

So, quoted from Daniel Huigens, who did the original benchmarking:

"Re. Neal's request, I didn't have the numbers anymore, so I unscientifically created some new ones

It looks like either Chrome or we have actually fixed the performance issues there with c=8 since the last time I tested it, as for most message sizes the performance is the same as c=12 or even a bit faster, except 128KB-256KB, which fits in one chunk with c=12 and there c=8 is about 1.1x - 1.5x slower.

In Firefox, for >=64KB messages, c=8 is still about 1.5x - 2.5x slower than c=12, however, it looks like most of the overhead of smaller chunks comes from the streams polyfill, not the web crypto API. So that should probably be possible for us to fix."

I see your logic on 16 kiB but in particular for file encryption I think there's some value to being able to go bigger in the future (L2 cache sizes have changed in the last 20 years as well and will probably change in the next two decades), and to keep the size byte to be able to configure this rather than have an entirely new packet. I think a SHOULD for 16 kiB though is totally appropriate now though for the reasons you mentioned.