Package net.i2p.util

Class NativeBigInteger

All Implemented Interfaces:
Serializable, Comparable<BigInteger>

public class NativeBigInteger
extends BigInteger

BigInteger that takes advantage of the jbigi library for the modPow operation, which accounts for a massive segment of the processing cost of asymmetric crypto. The jbigi library itself is basically just a JNI wrapper around the GMP library - a collection of insanely efficient routines for dealing with big numbers.

There are three environmental properties for configuring this component:
  • jbigi.enable: whether to use the native library (defaults to "true")
  • jbigi.impl: select which resource to use as the native implementation
  • jbigi.ref: the file specified in this parameter may contain a resource name to override jbigi.impl (defaults to "jbigi.cfg")

If jbigi.enable is set to false, this class won't even attempt to use the native library, but if it is set to true (or is not specified), it will first check the platform specific library path for the "jbigi" library, as defined by Runtime.loadLibrary(java.lang.String) - e.g. C:\windows\jbigi.dll or /lib/libjbigi.so, as well as the CLASSPATH for a resource named 'jbigi'. If that fails, it reviews the jbigi.impl environment property - if that is set, it checks all of the components in the CLASSPATH for the file specified and attempts to load it as the native library. If jbigi.impl is not set, it uses the jcpuid library described below. If there is still no matching resource, or if that resource is not a valid OS/architecture specific library, the NativeBigInteger will revert to using the pure java implementation.

When attempting to load the native implementation as a resource from the CLASSPATH, the NativeBigInteger will make use of the jcpuid component which runs some assembly code to determine the current CPU implementation, such as "pentium4" or "k623". We then use that, combined with the OS, to build an optimized resource name - e.g. "net/i2p/util/libjbigi-freebsd-pentium4.so" or "net/i2p/util/jbigi-windows-k623.dll". If that resource exists, we use it. If it doesn't (or the jcpuid component fails), we try a generic native implementation using "none" for the CPU (ala "net/i2p/util/jbigi-windows-none.dll").

Running this class by itself does a basic unit test and benchmarks the NativeBigInteger.modPow vs. the BigInteger.modPow by running a 2Kbit op 100 times. At the end of each test, if the native implementation is loaded this will output something like:

  native run time:        6090ms (60ms each)
  java run time:          68067ms (673ms each)
  native = 8.947066860593239% of pure java time
 

If the native implementation is not loaded, it will start by saying:

  WARN: Native BigInteger library jbigi not loaded - using pure java
 

Then go on to run the test, finally outputting:

  java run time:  64653ms (640ms each)
  However, we couldn't load the native library, so this doesn't test much
 
See Also:
Serialized Form