[GHC] #10364: Feature request: Add support for FMA
GHC
ghc-devs at haskell.org
Wed Apr 29 01:31:17 UTC 2015
#10364: Feature request: Add support for FMA
-------------------------------------+-------------------------------------
Reporter: lerkok | Owner: ekmett
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Core Libraries | Version: 7.11
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Description changed by lerkok:
Old description:
> FMA (fused-multiply-add) has been around for quite some-time, and is
> natively supported by many of the newer processors. It's an operation
> that is heavily used in HPC applications. I think it's time for Haskell
> to have native support for it as well.
>
> Ideally, it should be added to the `Num` class as a method. Assuming that
> is a possibility, we would have the following signature and default
> definition:
>
> {{{#!hs
> class Num a where
> ...
> fma :: a -> a -> a -> a
> fma x y z = x * y + z
> }}}
>
> Except of course the `Float` and `Double` instances would ensure that the
> rounding is done only once.
>
> If adding it to the `Num` class is not an option, then `RealFloat` class
> would be the next best place; and perhaps that's arguably also a better
> place because those types are the ones one usually has in mind when using
> FMA.
>
> I think either `Num` or `RealFloat` would be fine choices.
>
> Implementation:
>
> * If the underlying architecture supports it (which is very common),
> directly emit FMA instruction
> * Otherwise, FFI out to C and use `fma` and `fmaf` from the math
> library
>
> A direct software implementation might also be possible for platforms
> where neither choice above is an option, but that bridge can be crossed
> when we get there.
>
> As a final note; while supporting these functions might seem going-out-
> of-our-way; it is indeed a big selling point in HPC applications.
> Furthermore, hardware manufacturers are putting big resources to make
> these supported naively in the instruction sets. Supporting FMA right out
> of the box would be a very good step in wider adaptation of Haskell in
> the HPC community.
New description:
FMA (fused-multiply-add) has been around for quite some-time, and is
natively supported by many of the newer processors. It's an operation that
is heavily used in HPC applications. I think it's time for Haskell to have
native support for it as well.
Ideally, it should be added to the `Num` class as a method. Assuming that
is a possibility, we would have the following signature and default
definition:
{{{#!hs
class Num a where
...
fma :: a -> a -> a -> a
fma x y z = x * y + z
}}}
Except of course the `Float` and `Double` instances would ensure that the
rounding is done only once.
If adding it to the `Num` class is not an option, then `RealFloat` class
would be the next best place; and perhaps that's arguably also a better
place because those types are the ones one usually has in mind when using
FMA.
I think either `Num` or `RealFloat` would be fine choices.
Implementation:
* If the underlying architecture supports it (which is very common),
directly emit FMA instruction
* Otherwise, FFI out to C and use `fma` and `fmaf` from the math
library
A direct software implementation might also be possible for platforms
where neither choice above is an option, but that bridge can be crossed
when we get there.
As a final note; while supporting these functions might seem going-out-of-
our-way; it is indeed a big selling point in HPC applications.
Furthermore, hardware manufacturers are putting big resources to make
these supported natively in the instruction sets. Supporting FMA right out
of the box would be a very good step in wider adaptation of Haskell in the
HPC community.
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10364#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list