Page MenuHome GnuPG

Better performance with OCB encryption + sign
Closed, ResolvedPublic

Description

In T6561, we see OCB AEAD encryption is quite fast.

If we can do such an improvement for buffering (for hashing for signature), it will be another motivation for a user to migrate to newer GnuPG.

Revisions and Commits

Event Timeline

gniibe triaged this task as Normal priority.Jul 3 2023, 10:42 AM
gniibe created this task.

It seemed I was wrong that it is due to buffering.
In the use case of --sign and --encrypt, hashing is done with IOBUF's 64KiB buffer (already).

I'm trying to use a thread for computation of hashing. It works, but no performance gain, due to nPth.
I do:

npth_unprotect ();
gcry_md_write (mfx->md, mfx->buf, mfx->written);
npth_protect ();

to expect hashing is done in parallel.

So far, it doesn't go well. Another thread is waiting the lock when it computes the hash. I need to introduce more controlled threads.

This is a patch for master (which uses nPth for gpg):

With this patch --sign + --encrypt can be as fast as --sign.

Updated the patch:

It uses double-buffer.

I can observe it's a bit faster (lower latency), due to hiding input+memcpy things while it computes the hash.

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

So some more data from 2.4.3. Once unpatched and once with your patch.

The problem is that heat seems to be an issue or at least some boosting of some cores or so. While continuning the tests the results were slower and slower. So after testing with your patched version I reinstalled 2.4.3 unpatched to repeat the tests twice again with that and got different, even slower results.

Still there is clearly a measurable improvement here.

But even with your patch with signing my disk io never went above 350MB/s for sign & encrypt. Where libgcrypt itself munched through 2200MB/s SHA256 hashing on the same system in the bench slope test and the disk does sequential read writes at around 3000MB/s. (See F4883964 )

Measure-Command { gpg --yes -z0 -o 10gb-ocb.tar.gpg -er ldata-aead .\10gb.tar }
Unpatched: First test: 11.3s -> Last tests: 18.3s 21.8s
Patched: 18.5s 22.4s 18.3s

Measure-Command { gpg --yes -z0 -o 10gb-ocb-sig.tar.gpg -er ldata-aead -su ldata-aead .\10gb.tar }
Unpatched: First test: 49.2s -> Last tests: 65s, 62s
Patched: 35.1s 30.7s 39,3s

Update the patch to allow --compatibility-flags hashing-in-parallel.

My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.

gniibe changed the task status from Open to Testing.Jul 25 2023, 6:09 AM

Applied to master.

If you tested it yourself I would say this is enough to move such a task to resolved. If someone else should test it you should remove yourself as the assignee. I will test this by comparing 2.4 performance to master. We need to clean up the WIP tasks in our workboard.

gpg (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
gpg -z0 --yes --batch -esu ldata-test -r ldata-test 10gb-random.dat > 10gb.gp 13,37s user 22,54s system 95% cpu 37,421 total

With;
gpg (GnuPG) 2.5.0-beta179
libgcrypt 1.11.0
gpg -z0 --yes --batch -esu ldata-test -r ldata-test 10gb-random.dat > 10gb.gp 12,89s user 22,49s system 97% cpu 36,138 total

So the same.

With the compatibility flag my CPU usage also got up:
gpg -z0 --yes --batch --compatibility-flags parallelized -esu ldata-test -r 14,68s user 21,36s system 112% cpu 32,015 total

So it is definitely an improvement but less then I had hoped for. I would also very much like to see this option enabled by default and the compatibility flag to be to disable it. But that is then for a different issue.