On Sun, 2016-01-10 at 16:13 +0000, Matthew Toseland wrote: > 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). >
It requires every single installer to be updated... as well as the run/update scripts for each platform. > 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. > Odds are we can get rid of db4o and Maven... I think that we want Gradle to be used as much as possible for everything. > 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. > I'm not convinced that it is; IMHO it'd just be easier to switch to whatever DSA implementation we have access to using JCA. > 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. > I agree; This is already disabled; we should decide whether it's worth fixing/re-enabling or should go away too Florent
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
