# MPF vs MPFR performance

Patrick Pelissier patrick.pelissier at gmail.com
Sun Sep 4 19:05:05 CEST 2005

```Hi,

This should be fixed in the next minor release of MPFR (Future 2.2.0).
By the way, which version of the softwares do you use?

--
Patrick Pelissier

On 9/4/05, Jim White <mathimagics at yahoo.co.uk> wrote:
> 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
>
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss at swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss
>
>
>
```