search

tc39 / proposal-float16array

a proposal to add float16 TypedArrays to JavaScript
http://tc39.es/proposal-float16array/
58 stars 2 forks source link

Should Float16Array be normative-optional? #3

Closed bakkot closed 1 year ago

bakkot commented 1 year ago

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

ljharb commented 1 year ago

Requiring them everywhere is better for interoperability, though.

bakkot commented 1 year ago

If the only use cases for Float16Array require hardware or other APIs which aren't available on a particular runtime, there's already no interoperability to be had.

phoddie commented 1 year ago

@bakkot, thanks for asking. In fact, we do occasionally run with a GPU, but not one that would benefit from having Float16 support in JavaScript.

FWIW – there may be a use for Float16 in the embedded JavaScript universe. It is common to maintain a history of readings from a sensor and those values are often floating point. A native approach is to use Array, but the memory overhead can be a problem. The usual alternative is a TypedArray. Single-precision floats are generally enough. What I can't answer yet is whether there are scenarios where half-precision floats would be acceptable (e.g. is the resolution so low that it becomes meaningless for most sensor data).

Another question we need to answer for XS is whether the C compilers for embedded systems handle conversion to/from half-precision (probably?) and do so in a way that is compatible with the language spec (maybe?).

Assuming the compilers are cooperative, the overhead for XS here is minimal. Further, Float16 could mostly be automatically stripped from the engine if unused by a project, so any cost would only be carried by projects that actually use it.

bakkot commented 1 year ago

Great, thanks for the background. In that case I'll propose it as required everywhere (pending concerns about implementability).

Re: compilers and compatibility with the language spec, I know ARM has their own float16 variant, but I believe at least GCC and Clang support IEEE semantics for __fp16 everywhere. Looks like at least the Arm compiler does as well. When using IEEE semantics for __fp16, I am pretty sure that coercion between __fp16 and double should precisely match the read/write operations in this proposal.

fabiospampinato commented 1 year ago

FWIW I run a little program for language identification on the CPU (https://github.com/fabiospampinato/lande), no GPU, no Canvas, and I'd use a Float16Array if it were available because it would half the memory usage needed for the weights, and possibly speed up inference also once it gets optimized.

bakkot commented 1 year ago

Closing this as settled - it will not be optional.