‐‐‐‐‐‐‐ 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
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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp