gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNU Crypto] building GNU Crypto. was: Native BC build (long)


From: Raif S. Naffah
Subject: [GNU Crypto] building GNU Crypto. was: Native BC build (long)
Date: Tue, 26 Nov 2002 23:31:25 +1100
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

earlier i said

On Thursday 21 November 2002 20:58, Raif S. Naffah wrote:
> On Thursday 21 November 2002 06:00, Casey Marshall wrote:
> > ...
> > Good. The `gcj/INSTALL' file should also have a blurb about how to
> > build the JCE stuff if desired, similar to the part about building
> > the JUnit tests.
>
> ok.  i'll work on that this weekend.
>
> > ...
> > Yes, releases should build in the expected way (./configure; make;
> > make install); CVS (and pre-releases in general) is usually the
> > "we're still working on this" part.
>
> i'll look into that this weekend too.
>
> i'll also start seeing how we can implement the build ideas...

this is now done.  see both INSTALL files (under the toplevel and gcj/) 
for how to build GNU Crypto.

few things worth noting:

1. we now have 2 source trees: the normal one (under toplevel/source) 
best suited for bytecode interpreter such as sun's java (or in the 
future kissme), and another (under toplevel/gcj/source) which contain 
GCJ-friendly implementations.

not all the algorithms under toplevel/source have their counter-parts in 
toplevel/gcj/source; currently only Serpent and Sha160 are there.  the 
GCJ-friendly Serpent is effectively the "old" SerpentBitSlice!  i 
changed the code everywhere to remove this distinction.  today, when 
the user asks for "serpent" they'll get the only one that was built in 
their binary.

the Sha160 under gcj/source is my attempt to improve the performance of 
SHA when built for a native library.  implementations for more 
algorithms will follow.

2. because we now have to cater for the case when a JCE framework 
implementation may, or may not, be installed/configured on the user's 
platform, some test classes would not compile because they refer to 
classes which in turn import javax.crypto stuff.  the offending class 
was test.jce.AllTests.java.  the work-around i used to solve this 
problem was to have a test.jce.AllTests.java.in file which has the 
lines containing the invocations to the classes that either should be 
included or not depending on whether there is a JCE framework 
implementation present, prefixed with a token.  that token gets 
replaced by a blank or the string // subject to the existence of a 
jce.jar.

in ant do:

   ant -Dwith.jce.jar=/location/to/jce/jar test

in make do:

   ./configure --with-jce-jar=/location/to/jce/jar
   make

3. the fact that we can now build from the same codebase, tailored 
binaries, with implementations optimised for GCJ, is IMO an advantage 
to the GNU Crypto library users.  the speed tests of the library with 
(a) JDK 1.3.1_06, (b) native gnu-crypto.so, with default configure, and 
(c) native gnu-crypto.so with customised GCJFLAGS value are incl.  note 
how Serpent and Sha160 result in a much improved performance!


comments and suggestions are welcome.

a. JDK 1.3.1_06:
- ----------------
Running 1000000 iterations:
twofish  Encryption  2450.9805 KB/s, Decryption   2479.7651 KB/s
null     Encryption 61515.746 KB/s,  Decryption, 62251.0 KB/s
anubis   Encryption 13423.539 KB/s,  Decryption  13504.754 KB/s
rijndael Encryption 15960.164 KB/s,  Decryption  15378.937 KB/s
square   Encryption 15067.503 KB/s,  Decryption  15096.619 KB/s
serpent  Encryption  5979.717 KB/s,  Decryption   6548.617 KB/s <--
blowfish Encryption 15879.064 KB/s,  Decryption  15348.723 KB/s
khazad   Encryption 11144.794 KB/s,  Decryption  10820.637 KB/s

Hashing 100000 blocks of 500 bytes each
whirlpool  4441.343 KB/s
ripemd128 21146.871 KB/s
sha-160   25130.275 KB/s <---
md5       32770.555 KB/s
md4       49875.51 KB/s
ripemd160 16434.912 KB/s
md2        1342.5754 KB/s

b.  default configure
- ----------------------
Running 1000000 iterations
square   Encryption  8378.016 KB/s,  Decryption  8378.016 KB/s
rijndael Encryption 11380.189 KB/s,  Decryption 11446.887 KB/s
null     Encryption 77736.32 KB/s,   Decryption 77736.32 KB/s
anubis   Encryption 10934.22 KB/s,   Decryption 10972.612 KB/s
twofish  Encryption  5111.22 KB/s,   Decryption  5220.5146 KB/s
serpent  Encryption 11050.212 KB/s,  Decryption 10805.671 KB/s <--
khazad   Encryption  6377.551 KB/s,  Decryption  6346.467 KB/s
blowfish Encryption  7843.8755 KB/s, Decryption  7963.8125 KB/s

Hashing 100000 blocks of 500 bytes each
ripemd128  19570.393 KB/s
sha-160    43287.344 KB/s <--
whirlpool   4843.099 KB/s
md5        32487.11 KB/s
md4        85363.85 KB/s
ripemd160  14623.577 KB/s
md2         1697.779 KB/s

## configure with GCJFLAGS="-march=athlon-xp -O2 
- -momit-leaf-frame-pointer -funroll-all-loops"
- -------------------------------------------------
Running 1000000 iterations
square   Encryption  9148.127 KB/s,  Decryption  9132.087 KB/s <--
rijndael Encryption 11660.447 KB/s,  Decryption 11677.877 KB/s
null     Encryption 80128.21 KB/s,   Decryption 80541.234 KB/s
anubis   Encryption 10805.671 KB/s,  Decryption 10926.574 KB/s
twofish  Encryption  5799.926 KB/s,  Decryption  5789.1816 KB/s
serpent  Encryption 11265.321 KB/s,  Decryption 10761.02 KB/s
khazad   Encryption  6660.273 KB/s,  Decryption  6660.273 KB/s
blowfish Encryption  8163.5317 KB/s, Decryption  8129.5522 KB/s <--

Hashing 100000 blocks of 500 bytes each
ripemd128 19712.605 KB/s
sha-160   45127.656 KB/s <--
whirlpool  4901.9297 KB/s
md5       37273.38 KB/s
md4       87662.7 KB/s
ripemd160 15827.593 KB/s
md2        1059.1785 KB/s


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE942ml+e1AKnsTRiERA0fUAJ9AxpAgkIiEo/CxWiRsEuXQ7m5TaACeK8ug
LWuQtjamUuSaC6HRR2wjGHI=
=9Jnw
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]