[Top][All Lists]
[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-----