[MPFR] GMP+MPFR to GPU?

[Vincent Lefevre]

On 2010-12-01 02:13:57 -0600, Rick C. Hodgin wrote:
> How well suited to parallel / vector processing are GMP's and MPFR's
> algorithms?  If, for example, we setup N identical operations for
> parallel computing (adds, multiplies, cosines, whatever), how would the
> existing design handle the vectorization?

Even for floating-point addition, I doubt this is possible, except
if you restrict the arguments to numbers of the same size and with
the same order of magnitude. If the precision is large, special
numbers should not be a problem: you'll only have a small overhead.

The executed code for elementary functions will also be different
if the arguments do not have the same size or do not have the same
order of magnitude. Moreover correct rounding might be a problem:
you'll have something like:

[from README.dev]
  MPFR_ZIV_INIT (loop, prec);            /* Initialize the ZivLoop controler */
  for (;;)                               /* Infinite loop */
    {
      [Compute an estimation of the function and]
      [an estimate of the error.]
      if (MPFR_CAN_ROUND (...))          /* If we can round, quit the loop */
        break;
      MPFR_ZIV_NEXT (loop, prec);        /* Increase used precision */
      [Use `mpfr_set_prec` to resize all needed intermediate variables]
    }
  MPFR_ZIV_FREE (loop);                  /* Free the ZivLoop Controler */

The "Table Maker's Dilemma" (cases where MPFR_CAN_ROUND(...) is false)
should be very rare, but if it occurs, this will slow down all the
cores that share the same SIMD instructions.

More importantly, the optimized source code for a CPU and for a GPU
would be much different. So, this would be a project different from
MPFR.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)