[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size - Performance

2019-02-28 13:11:33
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 28, 2019 12:38 AM, Neal H. Walfield 
<neal(_at_)walfield(_dot_)org> 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

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 {



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.

Attachment: signature.asc
Description: OpenPGP digital signature

openpgp mailing list
<Prev in Thread] Current Thread [Next in Thread>