Opened 10 months ago

Last modified 10 months ago

#15983 new feature request

Built-in support for half-floats

Reported by: lerkok Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.6.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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.

Change History (4)

comment:1 Changed 10 months ago by carter

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.

3) 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

comment:2 Changed 10 months ago by bgamari

In general we don't mark things as "won't fix" unless we actually intend never to fix them. In this case the right response is to just leave the ticket open without a milestone.

comment:3 Changed 10 months ago by lerkok

@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.

comment:4 Changed 10 months ago by bgamari

Milestone: 8.6.3

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.