MPF vs MPFR performance

Jim White mathimagics at yahoo.co.uk
Sun Sep 4 18:24:39 CEST 2005


I read with interest the August discussion regarding MPF vs MPFR performance.
 
I've returned to GMP and MPFR after a long absence, and just happen to be
doing a project for a Computational Science unit I'm studying at uni. My chosen
topic is to look at performance of elementary function evaluation algorithms
in some different arbitrary precision packages, and the systems I've chosen 
to compare are GMP/MPFR,  David Bailey's ARPREC (which uses floating
point limbs rather than integers) and Java's BigDecimal class.
 
As a first step, I created a simple benchmark program to thoroughly exercise
the multiply, divide and add operators, to provide an indicative raw performance
indicator for each system at various precisions (1000, 2000,  5000 and
10000 digits, ie. roughly 3K to 32K bits).
 
The benchmark test computes e^e, using a simple (unoptimised) power-series 
evaluation of the exponential function, i.e. exp(x) = 1 + x + x^2/2 + x^3/3! ......   
 
The point that was made in the August discussion regarding the relative speed of 
basic operations in MPFR vs MPF modes is confirmed by the results I'm getting.
 
Firstly, I have verified that the number of iterations and operations, and the result, 
is exactly the same in both modes). 
 
If I calculate X = exp(1) in 5000-digit precision, then the MPFR mode is 40 times
slower. But if I then take that result and calculate exp(X) then the MPFR mode is
only 3 times slower, or to be more precise, the MPF mode is itself proportionately
slower, as the X term in the series expansion starts off with a full load of limbs.
 
The very nature of this test, an iteratively converging series summation, 
is precisely the sort of calculation not suitable for MPFR - such algorithms clearly
are going to be better off with dynamic precision.  But it does demonstrate the
point that the basic operations in MPFR mode are probably just as efficient as MPF
mode, but only when the MPF operands are actually occupying the full precision.
 
Cheers
 
Jim White
Mathimagics Software Engineering
Canberra, Australia
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gmplib.org/list-archives/gmp-discuss/attachments/20050904/4e6878dd/attachment.html


More information about the gmp-discuss mailing list