Has anyone compared performance of GMP with MPFR when computing the M-Set?

[jwm-art]

Dear Lazyweb,

When I created MDZ I went for MPFR - it had correct rounding after all, and I didn't want incorrect rounding. From scouring the forums for various topics, I see some mentions of GMP use. I'm now wondering if MPFR's correct rounding might impact upon it's performance.

Although it might be possible to compare MDZ (using MPFR) with a GMP implementation of the M-set, I suspect there might be code differences which could cause this idea to provide inaccurate results.

So I am wondering if anyone here has per chance happened to have done some benchmarking of their own using GMP and then substituting MPFR?

If not, then I guess I should pull my finger out and do it myself!

Cheers,
James.

[jwm-art]

Ok, I've made some initial tests and it seems GMP is indeed faster than MPFR.

Using the following coordinates as a test subject*:

Code:

cx -1.7495931476527795538581440
cy 5.7906916425848251448578411e-8
size 2.2942681469770775590233391e-20

and using 80 bits of precision for calculations, the GMP rendering takes roughly 17.6 seconds, and the MPFR rendering takes around 20.3 seconds.

Attached are three images, test_gmp.png shows the render using GMP, the MPFR render is called test_mpfr.png, and the third image is the difference (in the GIMP) between the two.

To perform the GMP render, I have only converted the code which performs the render of each line in the image. The coordinates are still calculated using MPFR, but they, the MPFR (mpfr_t) coordinates, are converted to GMP (mpf_t) just once at the start of each render.

I've uploaded the code to github here:
https://github.com/jwm-art-net/MDZ/commit/554c574fb40c5c9ab133c2822f0374431e0e2a52

At this stage I am considering keeping both MPFR and GMP rendering available within MDZ. GMP is quicker, but as the two images show, there are differences between them, but that said, I'm not yet sure how much this matters, more investigations needed.

Incidentally, if you look at the commit you'll notice a lot of changes in fractal.c which are not explained by the addition of a GMP based line render. Before I made these tests I came to the conclusion that there would be very little speed decrease by adding other fractal types other than the M-Set. I have broken the main iteration loop for each pixel into a separate function - as the bulk of the processing time is within the iteration loop, the extra function calls should be (and are) negligible on performance. Other fractal types may slowly creep into MDZ (simple Mandelbrot variants at first). All that remains is  whether to use a function pointer or a switch statement. If the latter, then another possibility is to turn the main iteration loop functions for each fractal into preprocessor macros (inline guaranteed) rather than functions.

*test subject is taken from the file gallery/test.mdz in the source code package of MDZ. see http://jwm-art.net/mdz/saved_settings/test.mdz

[ker2x]

thank you very much for the benchmarks

[jwm-art]

thank you very much for the benchmarks

They're only rough figures from a couple of runs each. There are some differences between MPFR and GMP* such as the precision setting for GMP is a minimum number of bits of precision to use, whereas for MPFR, the precision setting is the exact number of bits to use (for the mantissa).

Which means the following location at a setting of 80 bits will render fine under GMP, but using MPFR, the precision needs to be upped to around 96 bits:

Code:

cx -7.58221019294777327223008430374e-1
cy 7.64662642064493872120830327578e-2
size 4.45803728737525638055234646552e-23

I'm not quite sure then why I should bother with setting a precision value under GMP at all?

*http://www.mpfr.org/faq.html#mpfr_vs_mpf

[hobold]

The exact precision (as a number of bits) in GMP has some granularity. On most machines, the effective precision of GMP will be rounded up to a multiple of 32 or 64 bits. That means if you ask GMP for 80 bits of precision, you might get 96 or even 128.

MPFR, while being based on GMP, adds "proper" rounding to all computation. That means if you ask MPFR for 80 bits of precision, all computation will be properly rounded to 80 bits. On the other hand, if you ask both GMP and MPFR for exactly 128 bits of precision, then MPFR can be more precise (at least for higher math functions like trigonometry, logarithms, etc.). That's because MPFR will recognize and handle cases when it has to compute with more than the specified precision in order to deliver the correct rounded result, while GMP computes everything in the specified precision, and might lose a few low order bits.

Both software packages have slightly different goals. GMP aims to be an efficient enabler for arbitrary precision arithmetic, while MPFR puts more emphasis on numerical accuracy than on raw speed (but MPFR certainly enjoys the performance of GMP).

(Where "numerical accuracy" can and does include the case that it may be less accurate then GMP, but in a very controlled way. Floating point arithmetic can be strange, and doesn't always behave like mathematical numbers do. MPFR tries to be very consistent and predictable with respect to the unavoidable errors.)

[jwm-art]

Thankyou Hobold that is very helpful.