On Sat, Mar 15, 2003 at 09:44:51AM +0000, Matthew Toseland wrote:
> Further testing shows that this is purely an artifact of our thread
> use/system load... when run outside Fred, Sun takes about 20ms to do
> a modPow(), and Kaffe takes about 2ms. Under light load, Sun can take
> 200ms or so; under relatively heavy load, Sun takes 900-1400ms. This
> would appear to be mainly caused by our excessive usage of threads and
> its interaction with the kernel scheduler...

Yeah, thats what I thought.  I had never run into any problems with the 
lib before.

        Scott

> 
> [CC'd to kaffe at kaffe.org because of borderline relevance, due to the
> figures on kaffe vs sun modPow()]
> 
> On Sat, Mar 15, 2003 at 03:07:27AM +0000, Matthew Toseland wrote:
> > 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.
> 
> 
> 
> -- 
> 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/nDBm5SExzKo/
> ICTHUS.



-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20030315/b377be31/attachment.pgp>

Reply via email to