[kaffe] Freenet slowness dominated by Sun's slow implementation of modPow()?

[Matthew Toseland]

It looks like the dominating factor in the crypto in authorizeTime is
BigInteger.modPow() (a JVM-provided method, which really ought to be
fast...). I'm seeing an average time for modPow() of 1412ms (it seems to
be increasing...). With Sun 1.4.

Now, with Kaffe, which uses libgmp, averages are closer to 59ms-75ms.

I will run it on Kaffe overnight to see what happens.

Possibilities:

A) Fix remaining Kaffe problems (kaffe has monolithic GC, causing
longish delays from time to time which lock the whole VM, but there is a
kaffe derivative that uses Boehm incremental GC which could be merged;
kaffe seems to get longer lock times suggesting maybe its locking is very
heavy...), bundle Kaffe with Freenet (even on the Win32 version - this
should be possible, I believe there is a port). Grumble if running a Sun
JVM, but still run.

B) Call out to an external, platform specific helper app if available
(grumble loudly if it isn't there). With times of a second or more, this
is probably still faster than using Sun's slow code.

C) Any other suggestions?

We really should do something about this is 0.5.2 - shaving 900ms off
average authorizeTime's/connectingTime's is not something to be ignored.

BTW, the theory: Kaffe uses libgmp, which is very very fast. Sun uses
some apparently badly written in-house BigInteger code.
-- 
Matthew Toseland
toad at amphibian.dyndns.org/amphibian at users.sourceforge.net
Full time freenet hacker.
http://freenetproject.org/
Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/J3Q~LkZ7ezk/
ICTHUS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kaffe.org/pipermail/kaffe/attachments/20030314/3d541928/attachment-0003.pgp