Re: [Classpathx-crypto] [patch] Inlined Serpent

[Raif S. Naffah]

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

hello Casey,

Casey Marshall wrote:
| Raif S. Naffah wrote:
| | hello Casey and Dag,
| |
| | Casey Marshall wrote:
| | | (I'm CC'ing this to the crypto list, too)
| | |
| | | Attached is a patch...
| |
| | this version:
| | a. is _not_ thread-safe,
|
| The attached version should be; it still declares the five register
| variables (x0..x4) as global for the class, but declares the encrypt
| and decrypt methods to be explicitly synchronized. This doesn't appear
| to affect speed, unless you're encrypting and decrypting in parallel.

agreed.


| | b. generates a 54K class file (compared to 14K for the current impl.)
| | --with Sun's javac compiler.
|
| ...this version does a bit better...

much better.  it is now at 25K (again with javac 1.3.1).


| | c. runs almost 20 times slower than the current one!
|
| Because of the JIT. Sun's HotSpot can handle this one better.
|
| I was aiming for the following with this version:
|
| 1) Keep constant array indices.
| 2) Keep methods short, so the JIT can handle them.
| 3) Don't repeat too much code (e.g. there is a one function per S-Box).
|
| The results are a good compromise:
|
| ~            Sun 1.4.0         GCJ (native)       Kaffe 1.0.6
| encrypt   4584.8003 KB/s     6262.5254 KB/s    4283.1689 KB/s
| decrypt   4861.5435 KB/s     6230.0640 KB/s    4662.7871 KB/s

on my athlon 1700+:

~     [java] Exercising serpent...
~     [java] Running 1000000 iterations:
~     [java] Encryption: time = 2.594, speed = 6023.5156 KB/s
~     [java] Decryption: time = 2.414, speed = 6472.659 KB/s

very nice job mate :-)


| ...By the way with this
| version GNU's Serpent will be faster than BouncyCastle's.

have you compared the performance of other algorithms?


| | i see some advantages in keeping the current implementation _and_ adding
| | the new in-lined one as an alternative; say SerpentInLined? (naming
| | suggestions are welcome)
| |
|
| I wonder if a naming scheme following "SerpentSBoxImpl" or something
| similar is more appropriate, since what we're talking about here is a
| particular implementation of "bit-sliced" S-Boxes.

with the figures of the new implementation, do we still want to keep both?


| | ...
| | pointers to finding out more about JIT nuts and bolts, anybody?
|
| There's this: <http://java.sun.com/docs/hotspot/VMOptions.html> which
| says that HotSpot JITs can take the option -Xmaxjitcodesize<size>.
| Generated code size is obviously not the problem, since trying the fully
| inlined version with outrageously huge compiled code sizes results in
| equivalent performance. I can't find anything relating to time spent in
| the compiler.
|
| Sun has published some books on their JITs, none of which I've seen,
| though.

thanks + cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.90 (MingW32)
Comment: Que du magnifique

iD8DBQE9eY5Y+e1AKnsTRiERA0g1AJoDCXIZ23HBUZop0pHHkBonvQNqvgCgx6r3
h9a3MYCDb/WYPW8tcAzveZw=
=6B19
-----END PGP SIGNATURE-----