[Numpy-discussion] adding fused multiply and add to numpy

[Frédéric Bastien]

Hi,

It happen frequently that NumPy isn't compiled with all instruction
that is available where it run. For example in distro. So if the
decision is made to use the fast version when we don't use the newer
instruction, the user need a way to know that. So the library need a
function/attribute to tell that.

How hard would it be to provide the choise to the user? We could
provide 2 functions like: fma_fast() fma_prec() (for precision)? Or
this could be a parameter or a user configuration option like for the
overflow/underflow error.

Fred

On Thu, Jan 9, 2014 at 9:43 AM, Freddie Witherden <freddie at witherden.org> wrote:
> On 08/01/14 21:39, Julian Taylor wrote:
>> An issue is software emulation of real fma. This can be enabled in the
>> test ufunc with npfma.set_type("libc").
>> This is unfortunately incredibly slow about a factor 300 on my machine
>> without hardware fma.
>> This means we either have a function that is fast on some platforms and
>> slow on others but always gives the same result or we have a fast
>> function that gives better results on some platforms.
>> Given that we are not worth that what numpy currently provides I favor
>> the latter.
>>
>> Any opinions on whether this should go into numpy or maybe stay a third
>> party ufunc?
>
> My preference would be to initially add an "madd" intrinsic.  This can
> be supported on all platforms and can be documented to permit the use of
> FMA where available.
>
> A 'true' FMA intrinsic function should only be provided when hardware
> FMA support is available.  Many of the more interesting applications of
> FMA depend on there only being a single rounding step and as such "FMA"
> should probably mean "a*b + c with only a single rounding".
>
> Regards, Freddie.
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>