MPF vs MPFR performance

[Patrick Pelissier]

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
> 
> 
>