On 10/01/16 15:33, Ben Green wrote: > Hello freenet-dev, > > In a recent comment on a pull request: > > https://github.com/freenet/fred/pull/29 > > Steve said: > > 1471 isn't going to split freenet-ext either. Hrm. > > I would like to help with this as I have recently had the dubious pleasure of > deciphering the build scripts from contrib/NativeBigInteger. I had initially > wondered if it is still worth it as it has been some time since the > repository was updated, I found that with the version of GMP that is > "supposed" to be used, 5.0.1 (by that I mean the one referenced in the build > scripts in contrib on github) the speed is: > > native run time: 66ms (0ms each) > java run time: 329ms (3ms each) > native = 20.060790273556233% of pure java time > native run time: 60ms (0ms each) > java run time: 310ms (3ms each) > native = 19.35483870967742% of pure java time > > Running the same thing with the most recent GMP, 6.1.0: > > native run time: 47ms (0ms each) > java run time: 315ms (3ms each) > native = 14.920634920634921% of pure java time > native run time: 49ms (0ms each) > java run time: 315ms (3ms each) > native = 15.555555555555555% of pure java time > > I can only guess what version is used in the official release but from the > dates on the i2p > repository and the dates in freenet-ext.jar (09-05-2011) and TommyD's Gentoo > ebuild I am guessing 4.1.4 - 4.2.2, in any case the runtime is: > > native run time: 101ms (1ms each) > java run time: 375ms (3ms each) > native = 26.933333333333334% of pure java time > native run time: 89ms (0ms each) > java run time: 316ms (3ms each) > native = 28.164556962025316% of pure java time > > These are the tests included in the i2p NativeBigInteger.class file and I > them several times, they seem quite consistent. These tests were performed on > my laptop, of 2012 vintage: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz. If you > happen to be running Gentoo, and let's face it why wouldn't you, TommyD's > ebuild will create a library that uses whichever gmp is installed on your > local machine so that is good :-). From the above, less than rigorous > results, it seems that it is still worth using NativeBigInteger, at least on > my machine. > > I also notice that we have two NativeBigInteger.class files, one in > freenet-ext.jar and one in freenet.jar, they are different and if you run > freenet on a Raspberry Pi 2 with freenet-ext.jar first in your classpath > libjbigi-linux-arm.so is not loaded even if it is present, I can only assume > that the source to that version does not support arm. > > I realise this is probably not news to many and so before I go off and begin > re-writing the build scripts I thought I would see if anyone else is > currently engaged in re-packaging freenet-ext.jar. I was thinking to use > Autotools, I know that Gradle is getting a lot of attention but as jbigi and > jcpuid are native components I thought it may be better to keep with > Autotools (naturally, I would create and test scripts that would work in > MinGW/Cygwin too but might need a little help from anyone running FreeBSD or > OS X). > > Kind regards, > > Benjamin.
My 4p: 1. Splitting jars out of freenet-ext.jar is a good idea, and reasonably easy to deploy (just add more jars to dependencies.properties). 2. It probably requires solving the problems with Maven/Gradle (for Contrib), since the current Contrib uses Maven for some components. However for many components we could ship the official pre-built jars, especially if they are signed. 3. NativeBigInteger is only relevant for DSA. At the moment we only use this for SSKs; in future hopefully we will have ECC-based SSKs, but we will need to support old SSKs for some time. So it may still be worth having native code for it. 4. The native FEC code is currently disabled (in fred), because it has exploitable weaknesses. This is pending review by somebody really good at C and JNI. Arguably it's not worth the risk and we should get rid of it. Having said that IIRC there was a ~ 4x improvement in CPU usage, although decoding is often disk-limited for bigger files... It would be worth re-running the benchmarks for FEC.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
