On Monday 06 April 2009 16:18:28 Daniel Cheng wrote: > On Mon, Apr 6, 2009 at 11:04 PM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Friday 03 April 2009 08:39:52 Ximin Luo wrote: > >> Daniel Cheng wrote: > >> > On Fri, Apr 3, 2009 at 6:30 AM, ?<nextgens at freenetproject.org> wrote: > >> >> Author: nextgens > >> >> Date: 2009-04-02 22:30:59 +0000 (Thu, 02 Apr 2009) > >> >> New Revision: 26391 > >> >> > >> >> Modified: > >> >> ? trunk/freenet/test/freenet/client/CodeTest.java > >> >> Log: > >> >> Add a benchmark to the junit test; launch it with -Dbenchmark=true > >> >> At the moment it produces weird results: > >> >> ? ?[junit] Getting ready for benchmarking > >> >> ? ?[junit] Native8Code[k=192,n=256] > >> >> ? ?[junit] PureCode[k=192,n=256] > >> >> ? ?[junit] Native code took 239ms whereas java's code took 76ms. > >> > > >> > under my profiling: > >> > > >> > 1) The assertEquals is take more then 25% of time. > >> > 2) Randomize the array is taking around 7% of time > >> > 3) lots of time are spend on ?new byte[] ?/ new Buffer. > >> > > >> > after removing assertEquals and some byte array allocations: > >> > : Native code took 40ms whereas java's code took 2ms. > >> > : Native code took 3ms whereas java's code took 35ms. > >> > : Native code took 4ms whereas java's code took 2ms. > >> > : Native code took 29ms whereas java's code took 3ms. > >> > : Native code took 3ms whereas java's code took 2ms. > >> > > >> > These are more just random noises to me. > >> > > >> > FYP, I am using the freenet-ext.jar from freenetproject.org. > >> > > >> > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04) > >> > Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode, sharing) > >> > > >> > Using the new libfec8.so give more or less the same result. > >> > If you can reproduce this using other java version / cpu / arch, > >> > maybe we should just drop the native library. > >> > _______________________________________________ > >> > Devl mailing list > >> > Devl at freenetproject.org > >> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >> > >> I get similar results; this is with svn-compiled freenet.jar *and* > > freenet-ext.jar > >> > >> ? ? [junit] ------------- Standard Output --------------- > >> ? ? [junit] Getting ready for benchmarking > >> ? ? [junit] Native8Code[k=192,n=256] > >> ? ? [junit] PureCode[k=192,n=256] > >> ? ? [junit] Native code took 200ms whereas java's code took 43ms. > >> ? ? [junit] ------------- ---------------- --------------- > >> > >> infinity0 at xl269:~/data0/projects/freenet/trunk/freenet$ uname -a > >> Linux xl269 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64 > > GNU/Linux > >> > >> infinity0 at xl269:~/data0/projects/freenet/trunk/freenet$ java -version > >> java version "1.6.0_0" > >> OpenJDK Runtime Environment (IcedTea6 1.5pre) (6b14-1.5~pre1-5) > >> OpenJDK 64-Bit Server VM (build 14.0-b10, mixed mode) > >> > >> but for more accurate results we should write some longer tests, ie. ones > > which > >> take minutes, not milliseconds... > > > > Unfortunately we do not have enough memory to play with to send large amounts > > of data to the codec at once... > > > > Also, is this a regression? Has anyone tested the 32-bit codecs? > > on 32-bit machines? > The number I have posted is on x86 (32-bit machine), before infinity0 > and my patches. > That is, the benefit is statistically insignificant.
Nextgens has fixed a bug, we now get around 3:1 in favour of native code on 32-bit machines. When I have tried to build the binaries on my 64-bit system using gcc 4.3.2, it always segfaults unless -g is enabled. Nextgens suggests that -funroll-loops may be the problem, in which case removing it and reinstating the macro might fix the problem? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090415/85e3eda6/attachment.pgp>
