Built-in support for half-floats
Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set.
It would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double.
I'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
Activity
changed milestone to %8.6.3
added Tfeature request Trac import labels
I don’t think ghc can support half float any time soon as a built in. 1) for cpu native workloads there’s not a big win afik... because the value in gpu programming is from the bandwidth saving. Aka it’s more of a compact serialization than a representationfor computing. 2) while there is some new hardware with half float or even one bit float suport, those are all seemingly deep learning dedicated hardware.
- abi concerns - we barely even touch the surface area for handling simd computations with float or double. That stuff needs to be a lot more mature before touching half float. Cause scalar half float isn’t useful from a performance perspective.
All in all, the intent is good. But I’d be inclined to Mark this as a won’t fix until ghc simd becomes a lot more mature and commodity hardware has really wide spread support. Which will be years from now at the soonest
@carter I agree that the SIMD support isn't stellar. I still think native support for half-floats (even if it was all software) would be valuable for modeling purposes and for DSL's that can use the base algorithms to generate more interesting code. I think this "feature request" makes sense, but whether there's enough ROI or something more systematic needs to be done first is obviously a GHC-HQ decision.
added Pnormal label
