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