We tested very conservative. By this we mean that we limit our tests to what java.math.BigDecimal can handle or handles best. Remember that e.g. a 2-digit number like 1.2E1454 is really a 2-digit number in be.arci.math and com.ibm.math, but internally is a 1456-digit number in java.math, because that package can handle no exponents; java.math.BigDecimal will transform all 1454 trailing zeroes into a long string of on-and off bits that have to be operated on. Our benchmark did not use such numbers, as we do not need them to show ArciMath BigDecimal is best.
The unframed 'raw' version is produced directly by the benchmark program, without any correction or window dressing. Notes relating to the different operations are on their respective chart pages. (The icon).
This is a naugthier benchmark, using an explicit "E+1000" exponent appended to the same numbers as the first run. Of course java.math and com.tce.math did not like this, so we offered them a "0000000....." tail of 1000 zeroes instead. Look at the charts and you'll realize why we ran it overnight.
The standard java.math.BigDecimal delegates all construction and arithmetic to the java.math.BigInteger class. In the new JDK 1.3, the java.math.BigInteger implementation is completely rewritten and is now 100% java. Also the new JVM (with the HotSpot Client) is said to be more performant. Our benchmark shows that this might be especially so for object construction, because for the large numbers the benefit of HotSpot is less clear.
The Evaluation Version is a fully functional, unrestricted equivalent of the Production Version. The only drawback is performance, which is on average 10-50% slower than that of the Production Version for moderately long numbers. This still makes the Evaluation Version faster than the competition, by the way.
Benchmark.java, the code we used to produce the above benchmark tables.
** WARNING: RUNNING THIS PROGRAM CAN RAISE YOUR CPU'S TEMPERATURE CONSIDERABLY **