There is double-double arithmetic, using two doubles as an unevaluated sum.  inline C++ should be lowest overhead when using the 'libqd' library, which also has quad-double (four doubles).  They provide ~106 and ~212 bits of mantissa respectively.  I'd be interested in your timings with these types, as I'm currently trying to figure out how to implement triple-double (which would be ~159 bits) for speedup over quad-double.  The technique applies to single precision float just as well.  Sometimes this use case (for GPU) is called "emulated doubles".  For Haskell, the 'compensated' package has pure-Haskell implementations of the basic circuits, it misses the transcendental functions though.

Also worth trying Boost 'multiprecision' wrapper for MPFR, it has a stack-allocated compile-time-fixed-precision variant when you don't need fully arbitrary (runtime-chosen) precision which should be competitive with low-level MPFR functions called from C (though, I haven't benchmarked to be sure).

here's (untested!) GLSL code showing the huge difference a precise FMA makes to f*f→(f,f)
vec2 split(float a)
{
  float t = 4097.0 * a;
  float ahi = t - (t - a);
  float alo = a - ahi;
  return vec2(ahi, alo);
}

ff two_prod(float a, float b)
{
  float p = a * b;
#ifdef HAVE_FMA
  float e = fma(a, b, -p);
#else
  vec2 a_ = split(a);
  vec2 b_ = split(b);
  float e = ((a_.x * b.x - p) + a_.x * b_.y + a_.y * b_.x) + a_.y * b_.y;
#endif
  return ff(p, e);
}


I try the ligqd and boost, which sounds very promising (if I can figure out how to install those easily and safely).

bwahahaha good look with that ! boost is a tremendous pain to manage on windows 
(but easy with linux)

I'd be interested in your timings with these types, as I'm currently trying to figure out how to implement triple-double (which would be ~159 bits) for speedup over quad-double.

I just came across this site: https://mrob.com/pub/math/f161.html#source with source code for extended precision (double double, triple double and quad double), 107, 161 and 214 bit mantissa precision.

I just started using the f107 version - first images are computed much faster than GNU's quadmath __float128.

MPFR is about 2 times slower than float128 and my own custom-made fixed precision numerical type (32 bit to the left of the radix point, 96 bit to the right) is about 25% faster (un-optimized, still experimental).

The f107 is about 2.5x as fast as float128 for my computations, so that's a win (although I have an issue with the printing functions, they "forget" digits in my compiler settings, but the values are there (2^1 + 2^-60).

For f107 or float128: They have to test whether and in what direction rounding has to occur. Is this test computationally expensive?

Since I am working with dyadic fractions and use a datatype with enough precision so out of range will not occur during calculation: Would it be time-beneficial to delve into the code and theory in general to remove that test? Or is it only a minor gain in speed, if at all measurable?

Some timings for my test image (quartic Julia set, slow dynamics (w.r.t. cell-mapping/IA algorithm by Figueiredo)).

Looking at claude's list I think I should give the qd library a longer try since it is even faster for double double than the f107.

I still have to try more images and other iteration formulas, but for now I'm quite happy with Robert Munafo's implementation.

Abbreviations below: fpa = my 32.96 fixed-point implementation; optimized means calculation path for bounding box was optimized (passing of references, temporary variables, operator avoidance and the like.

  5 sec   optimized mrob accurate double double without fma
 15 sec   un-optimized mrob accurate double double without fma
 19 sec   optimized fpa
 41 sec   un-optimized quadmath __float128
 73 sec   un-optimized fpa
(I couldn't test the triple or quad double datatype as I need a floor function for the computation)

Thanks, but I'm working on a Windows 10 computer. f107 is "installed" by just including a cpp file into my source code which is very convenient and error-free (and can be un-installed with no trouble). I'll check if qd can be used that way too.