On 10/01/16 16:31, Florent Daigniere wrote: > 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.
Good point, although we can safely add the new jars to the auto-update before dealing with the rest (if they're the same or compatible versions). >> 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. Xor needs db4o, but arguably he can bundle it with his plugins... > >> 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. You are probably right. Arguably this allows for an asymmetric CPU DoS just by sending lots of SSK inserts? Load management may throttle this to the point where it isn't viable already, but it'd be worth checking. >> 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 Needs to be considered quantitatively IMHO. E.g. is it noticeably slowing down fproxy fetching cached sites after restarting?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
