Requesting feedback on implications of adding Float16Array to JavaScript

[bakkot]

I'm on TC39, and I'm working on advancing a proposal for Float16Array in JavaScript, which would hold IEEE binary16 floats (also called float16, fp16, f16, half precision floats, etc). I'm interested in the thoughts of participants here in what implications that might have, if any, for WebAssembly.

The proposal only adds the ability to have an array backed by float16 values - they would still be converted to/from JS Number values (i.e. doubles) when performing any operations within JS. So this in principle doesn't require any hardware support or new types of values.

The primary motivation for the proposal is for use in the broader web platform - major use cases include float-backed canvases, float16 textures in WebGL (which already exist, but require passing a Uint16Array to use), and more general GPU computation in WebGPU. I'm not aware of any obvious use within WebAssembly as it is today.

I'm reaching out here to see if this proposal would have any implications for WebAssembly, and more broadly to make people here aware of the proposal for general interest. I don't really expect there to be any immediate implications, but I might be missing something. (One minor thing I can imagine - if WebAssembly adds support for working with float16 values, there are cases where it might make sense to write float16 values to the memory of a WebAssembly instance from JavaScript, which would be much easier with a native Float16Array).

[tlively]

On the surface, I don't think there are really any implications for WebAssembly. Wasm already supports f16 in the sense that a source program that uses f16 can be lowered to use f32 Wasm operations, just like engines would do to support f16 in JS. The difference is that the Wasm-targeting toolchain would do the lowering rather than the VM. Presumably all the motivations for having f16 in JS apply to Wasm as well, but if expanding the floats to use f32/f64 operations is good enough for JS, maybe it's good enough for Wasm and we don't need to do anything extra.

What does hardware support for f16 look like? If support for native f16 operations is widespread, then Wasm would probably want to add an f16 type and associated instructions to take advantage of that.

[penzn]

I don't think float16 can be used by Wasm transparently, as it not compatible with existing float types (unlike bfloat16, which half of single precision binary float representation). Using contents of Float16Array in Wasm as floating point numbers would require converting them to f32s, though loading and storing that data would be fine.

Hardware support on CPUs is "coming", while there is some GPU support I believe.

[bakkot]

What does hardware support for f16 look like?

My (limited) understanding is that outside of GPUs, it's rare for processors to directly support working with f16 values. There's decent hardware support for converting between f16 and f32 - every Intel processor since IvyBridge has supported _mm_cvtph_ps / _mm_cvtps_ph, e.g.

I am given to understand that bleeding edge Intel CPUs have native support for arithmetic on f16, as do some Arm processors since Armv8.2-A.

[tlively]

Then perhaps we should consider adding instructions for converting f16 (either loaded from memory in the same instruction or encoded in an i32) to f32. I checked and currently LLVM emits calls to library functions __extendhfsf2 and __truncsfhf2 to do these conversions. If the use cases and hardward support all involve SIMD, then instead we could consider adding new SIMD instructions.

[rossberg]

I think the addition of instructions for f16 is a completely separate question from the OP. Just adding a new typed array view to JS should not affect Wasm at all, as it merely sees the underlying bytes, and doesn't care what they are.

[bakkot]

Update: the proposal to add Float16Array to JavaScript today reached stage 3, meaning the design is finished, the committee is in favor, and engines can start implementing and shipping it.

Per discussion this has no immediate implications for Wasm, so I'm closing this. Thanks for the feedback, all.