[C++] vendor a half precision floating point library

[asfimport]

Clang and GCC provide _Float16 and there are numerous polyfills which can emulate a 16 bit float for other platforms. This would fill a hole in the kernels and other code which don't currently support HALF_FLOAT.

Reporter: Ben Kietzman / @bkietz
Watchers: Rok Mihevc / @rok

Related issues:

• [C++] Cast to/from halffloat not implemented (is depended upon by)

_{Note: This issue was originally created as ARROW-6436. Please see the migration documentation for further details.}

[asfimport]

Antoine Pitrou / @pitrou:
See also ARROW-3802. Numpy has dedicated float16 routines that we could reuse. Given that it's Numpy it's probably well-maintained.

There may be other projects around.

[asfimport]

Antoine Pitrou / @pitrou:
As for built-in float16 types it looks a bit more complicated, e.g. clang:

Clang supports two half-precision (16-bit) floating point types: __fp16 and _Float16. These types are supported in all language modes.

__fp16 is supported on every target, as it is purely a storage format; see below. _Float16 is currently only supported on the following targets, with further targets pending ABI standardization:

• 32-bit ARM
• 64-bit ARM (AArch64)
• SPIR

[asfimport]

Antoine Pitrou / @pitrou:
Also there are conversion intrinsic on recent x86 CPUs:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=half-precision

https://en.wikipedia.org/wiki/F16C

 

[rok]

I've looked at some libraries to see what is usually used:

• TensorFlow - uses FP16
• Numpy seems to implement it's own arithmetic.
• PyTorch - uses FP16
• FP16 - seems to be composed mostly of half and few functions taken from other places.

Half seems pretty complete so I think it or FP16 would make good candidates.

cc @pitrou @bkietz

[pitrou]

Half seems pretty complete so I think it or FP16 would make good candidates.

Both look rather unmaintained. We could decide to maintain a fork in the source tree, but this would need assessing their technical quality as well.

Something as simple as https://github.com/Maratyszcza/FP16/blob/0a92994d729ff76a58f692d3028ca1b64b145d91/include/fp16/bitcasts.h#L30-L34 is undefined behaviour:

It is undefined behavior to read from the member of the union that wasn't most recently written.

(from https://en.cppreference.com/w/cpp/language/union)

[bkietz]

I think if available software implementations are unsatisfactory, it'd be preferable to write a very minimal version of our own and handle any operations by first converting to 32 bit float. This should be sufficient since we'd be able to use a native type most of the time. In that case, we'd only need to maintain:

• The cmake logic/flags necessary to enable native IEEE 754-2008 half precision floats when available
• The conversions soft 16 bit float <=> 32 bit float
  • Including bitwise equivalence to native 16 bit floats when available

[pitrou]

I think if available software implementations are unsatisfactory, it'd be preferable to write a very minimal version of our own and handle any operations by first converting to 32 bit float.

If the HW-based conversions are available on all major CPUs (and compilers!), and they are fast enough, then I guess it's a sufficient approach.

[pitrou]

Some interesting details discussed here:
https://www.corsix.org/content/converting-fp32-to-fp16

[adamreeve]

#36073 added a new arrow::util::Float16 class, with a comment saying the routines are "partially adapted from Numpy's C implementation".

So it looks like this can be closed? And unblock related work like #20213

[pitrou]

Thanks for the heads up @adamreeve . Yes, you're right, this can be closed now!