Mailing List Archive: gcrypt, MPI, GMP and powerpc64

Hi,

I'm benchmarking NuFW on PowerPC 64 bits and I see that MPI is using 80 to
90% of the CPU during gnutls_handshake(). Here are the top 5 functions:
45.94% _gcry_mpih_submul_1
21.46% _gcry_mpih_addmul_1
6.17% _gcry_mpih_add_n
4.64% _gcry_mpih_sub_n
2.88% _gcry_mpih_divrem
2.59% _gcry_mpih_mul_1

I dig into gnutls and gcrypt, and I see that there is no assembler version
of MPI (for ppc64). I also learned that MPI is based on old GMP release
(which release?).

So questions:
- Can someone write assembler code for ppc64? It should be easy since GMP
prototypes look to be the same, and assembler code for ppc64 already exist
in GMP.
- Would it possible to use GMP in gcrypt?
- Why using MPI instead of GMP?

For GMP, download http://ftp.sunet.se/pub/gnu/gmp/gmp-4.2.1.tar.bz2 and
read mpn/powerpc64/mode64/*.asm.

I see that a 32 bits mode exists, but I don't need it. The computer is
running in full 64 bits mode.

Victor Stinner aka haypo

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Tue, 25 Jul 2006 18:21, Victor Stinner said:

> So questions:
> - Can someone write assembler code for ppc64? It should be easy since GMP
> prototypes look to be the same, and assembler code for ppc64 already exist
> in GMP.

Yeah, I'd really like to see that. the code from the current GMP is
basically useful but it needs to be converted to the configuration
scheme as used in libgcrypt.

> - Would it possible to use GMP in gcrypt?

No. For security reasons we don't wnat the whole GMP suff. Just the
modified and meanwhile hopefuly well security audited libgcrypt code.

> - Why using MPI instead of GMP?

At the time I wrote GnuPG (1997) GMP development had stalled for years
and was stuck at 2.something. There was no maintainer for years.
Only later GMP 3 started and changed a lot of the assembler stuff - I
have seen eports that GMP is far less portable than it used to be.

There are quite some heavy changes in the internal working and what we
actually only need are the low level fucntions - should be easy to
adjust to libgcrypt but it is more work than I can spend on it.

We also need better optimized code for modern ia32 CPUS as well as for
ia64 or AMD.

And while we are at it: An optimized SHA-1 implementaion might make an
difference too.

Shalom-Salam,

Werner

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel