float is an unknown identifier about lljs HOT 2 CLOSED

The reason it's not there yet is because we're trying to figure out if we should actually have floats. There are two typed arrays for floats, Float32 and Float64. We might just go with float64 only, since coercion to float32 is not that easy. (It requires that you store and read the value out of a Float32 array.) If we only support float64, we might as well just call it "num" since it's what JavaScript uses anyway. I think "num" works, but i didn't implement float64 typed arrays yet.

from lljs.

I think the distinction between integers and floats could be relevant for pointer/array arithmetic interference and optimizations. But other than that, it's pretty irrelevant because it's all doubles underneath.

The distinction between float and double is a bit trickier. On the surface it might seem like only supporting float64 on the stack would be sufficient for a numeric type. However, I strongly suspect that V8's JIT tries to figure out when you're using Float32Array typed arrays, and emits float and not double code, that would run a lot faster on legacy machines that don't have 64-bit wide registers (it would not make a difference on the FPU I think since that processes the whole 80-bit register width anyway). On any account, in OpenGL (WebGL) you store vertex attributes as floats (32) because the API does not accept doubles. If the stack is 64-bit and the main result of a computation is 32-bit, there would still be a conversion, but I'm not sure if it matters, or if it's gonna happen anyway. The optimal case would be that V8-s JIT notices you're copying from float32->float32 and just register/heap moves 4 bytes.

On the memory usage side, supporting only float64 in structures and as type has an implication that in-memory structures held in *JS idiomatic fashion would double in size. I think this wouldn't matter most of the time, but some border cases could be imagined.

from lljs.