libgcrypt: POWER GHASH Vector Acceleration
Open, LowPublic

Description

Use POWER8 and POWER9 ISA enhancements to improve the performance of GHASH. Demonstrate why achieved performance of AES-GCM is close to optimal for the platform (i.e matching or beating OpenSSL performance).

Optimized assembly implementations in the Cryptogams repository[1] may serve as useful reference. C-based intrinsic implementations are discouraged. Financial bounty upon completion, community acceptance of patches, and bounty reviewer input.

[1] https://github.com/dot-asm/cryptogams/

johnmar created this task.Jul 16 2019, 6:32 PM
johnmar created this object in space S1 Public.
werner added a subscriber: werner.Jul 17 2019, 12:07 PM

Please STOP adding such bug reports or feature requests. They are not helpful and such discussion are better done at the mailing list. In case you want to spend money to speed up things you may contact gnupg.com for a quote.

werner triaged this task as Low priority.Jul 17 2019, 12:07 PM
werner added a project: Feature Request.

@werner I would be willing to share 20% to the reviewer of my patches. (or 25% in this case, as @jwilk went through the effort to even write a test to point out a bug in my code). However, so far that has been entirely @jwilk who has been reviewing my patches.

jukivili claimed this task.Aug 25 2019, 6:12 PM
jukivili added a subscriber: jukivili.

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

jwilk removed a subscriber: jwilk.Aug 25 2019, 6:23 PM
jukivili reassigned this task from jukivili to slandden.Aug 31 2019, 11:13 AM
johnmar updated the task description. (Show Details)Thu, Nov 7, 11:14 PM
C-based intrinsic implementations are discouraged.

What do you mean? This means that the compiler can do the register allocation, and I just learned clang can even do unrolling of loops for you. The openssl version for single-block (no unrolling) aes was half the speed of a c-based intrinsic implementation because there were things in the loop that didn't need to be there.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.

@jukivili, thanks for the heads up.

@slandden, would you please point me to the single-block AES code you mentioned? Are you also referring to https://dev.gnupg.org/rC92f38a619b1cf759057e9cd532ae7c1d0331100f ?

El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:

johnmar added a comment.

Allow me to clarify. For bounty purposes, as long as the intrinsic
implementation matches or beats OpenSSL performance, it is acceptable.
There have been cases where the use of certain intrinsics may yield better
performing, but sub optimal results.

@jukivili https://dev.gnupg.org/p/jukivili/, thanks for the heads up.

@slandden https://dev.gnupg.org/p/slandden/, would you please point me
to the single-block AES code you mentioned? Are you also referring to
https://dev.gnupg.org/rC92f38a619b1cf759057e9cd532ae7c1d0331100f ?

Yes, and the opendsl code is here
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesp8-ppc.pl#L464

While the register allocator is good (and reduces the number of things to
keep in ones head while ñrogramming dramatically), as well as the loop
optimizer. I don't think the compiler can generate constants loadable only
from the instruction stream. Openssl shows one way to do this, and it would
also be possible to unconditionally jump over data placed in the
instruction stream.

*TASK DETAIL*
https://dev.gnupg.org/T4630

*EMAIL PREFERENCES*
https://dev.gnupg.org/settings/panel/emailpreferences/

*To: *slandden, johnmar
*Cc: *raksprak, jukivili, slandden, werner, gcwilson, johnmar, pmgdeb,
srgblnchtrn, gp_ast, lumag

  • This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.