tc39 / proposal-float16array

a proposal to add float16 TypedArrays to JavaScript

Float16Array

A proposal to add float16 (aka half-precision or binary16) TypedArrays to JavaScript.

Status

Authors: Kevin Gibbons

Champions: Leo Balter, Kevin Gibbons

This proposal is at Stage 3 of The TC39 Process as of the May 2023 meeting. It awaits implementations.

Spec text is available here.

Implementations

This proposal is ready for engines to implement and ship. See this issue for current status of implementations.

Motivation

• Explicit request from the Color on the Web CG, for their use case with float-backed canvases.
• Useful for GPU operations, where full precision often isn't necessary and memory constraints are serious.
  • WebGPU supports float16. It exposes/consumes raw ArrayBuffers. When those contain 32-bit floats, the pattern is to wrap the buffer in new Float32Array(...); that doesn't work when they contain 16-bit floats.
  • Increasingly relevant with new tools like Stable Diffusion, where full-precision representations don't fit in VRAM on many machines.
• WebGL/WebGL2 support float16.
  • WebGL's OES_texture_half_float extension and WebGL2 support float16 texture, and also both EXT_color_buffer_half_float extensions support float16 render target. They expose/consume Uint16Arrays; that is not easy to handle.
• ARM and IA-32 and Intel® 64 architectures support float16 intrinsics.
  • In the C++23 specification, std::float16_t will be supported to call the CPU instructions.
• Faking it in userland has serious performance costs.

Proposal

This would add a new kind of TypedArray, Float16Array, to complement the existing Float32Array and Float64Array. It would also add two new methods on DataView for reading and setting float16 values, as getFloat16 and setFloat16, to complement the existing similar methods for working with full and double precision floats, as well as Math.f16round, to complement the existing Math.fround.

Userland

@petramoriken has a package implementing Float16Array which gets 100k+ downloads/week on npm. See that repository for examples of some of the limitations and downsides of trying to do this purely in userland - notably the impossibility of integrating correctly with other web platform features like WebGL's HALF_FLOAT buffers and structuredClone.

proposal-float16array's Issues

Stage 4 tracking

This proposal achieved stage 3 at the May 2023 meeting. This is a tracking issue for getting stage 4.

• committee consensus
• open PR to the spec
  • editors have approved the PR
• write test262 tests - issue
  • merge test262 tests
• at least two implementations
  • JavaScriptCore - issue
  • V8 - issue
  • SpiderMonkey - issue
• significant in-the-field experience

BF16 vs FP16

It seems there are two competing standards for 16-bit floating point. IEEE has one standard, FP16, and Google Brain has another, BF16. They are very similar except they have different number of bits for the exponent versus mantissa.

FP16 seems to have native support for conversion to f32 on x86, and for limited computation in aarch64. BF16 has native support for computation on TPU chips, which are found in Pixel phones, and it seems that BF16 support is coming to AMD and Intel chips as well (based on public forums and bugs).

In other words, is it premature to add support for a Float16Array, if it is soon to be supplanted by a newer standard? Or should we add the other type as BFloat16Array?

Platform integration work

This needs integration with a couple of bits of the web platform:

• Web IDL's ArrayBufferView, BufferRelatedType, etc need to be updated to list Float16Array
• WebGL's texImage2D needs to be updated so Float16Array is accepted as a source for HALF_FLOAT

As far as I am aware these are the only places which need updating currently (updating Web IDL will flow to a number of places, including WebGPU). WebNN and float-backed canvases are in progress features, and I've informed people working on both about Float16Array.

Stage 3 review

Spec draft editorially and normatively lgtm.

Should Float16Array be normative-optional?

All of the major use cases I'm aware of require either web canvases or GPUs. Obviously not all JS runtimes will be running in environments with access to those things (notably Moddable's XS engine, as well stuff like quickJS or Duktape). I don't see much reason to want Float16Arrays in such environments. Given that, should Float16Array be normative-optional for non-web runtimes?

cc @phoddie