1

Obviously numbers in JavaScript aren't explicitly typed, but are represented as types by the interpreter. I just saw a thing about Google's V8 JS engine that said it's greatly optimized for 32 bit numbers, but found it odd many JS programmers would have a need for doubles even with floating point. The only examples I could think of personally is if I'm dividing two integers, which I do often in order to normalize screen coordinates between 0 and 1, and the interpreter is truncating the result at 64 bits instead of 32. This also seems unlikely to me, but then again I don't know how else someone needing such precision would specify it. So now I'm wondering...is there a way to ensure the quotient of two (not gigantic) integers is under 32 bits in length?

Sophia Gold
  • 756
  • 1
  • 8
  • 18
  • 1
    No. All JavaScript numbers are double-precision floating-point values. Some computations *internally* may be carried out with integer math, but (other than values stored in typed arrays) numbers are doubles, and even with typed arrays, as soon as the values are extracted into an expression, they're doubles. – Pointy May 28 '16 at 14:35
  • It would be helpful if you could post a link to the reference (or "thing") you've seen about V8. – Pointy May 28 '16 at 14:35
  • I suppose it's fair to say that modern runtimes *do* (or at least *can*) perform some static code analysis to determine that a particular expression will involve only integers. Usually there's some set of signifiers that help, like `n|0` when a variable is referenced. That may be what your source was talking about. Usually that's done for fairly rare performance-critical code, because it's tricky to maintain. – Pointy May 28 '16 at 14:40
  • Chrome uses two js compilers and I imagine other browsers must at least be heading in that direction if not already. One is JIT, does not check types, and works for all code. The other uses dynamic type checking, reuses hidden classes, namespace allocation for arrays, etc...but does not work for all code. Which is used is determined based on how you write your code. As are all of the optimizations I've mentioned. In other words, you do NOT do anything to specify the type of a number. You use numbers in a way that they can adhere to certain types. [source](https://developers.google.com/v8/) – Sophia Gold May 28 '16 at 15:23
  • Right, and Firefox also has its asm.js support. – Pointy May 28 '16 at 15:26
  • This is not only for asm.js – Sophia Gold May 28 '16 at 15:31

1 Answers1

1

I just saw a thing about Google's V8 JS engine that said it's greatly optimized for 32 bit numbers

This only means that V8 does internally store those numbers as integers when it can deduce that they will stay in the respective range. This is common for counters or array indices, for example.

Is there a way to ensure the quotient of two (not gigantic) integers is under 32 bits in length?

No - all arithmetic operations are carried out as if they were 64 bit floating point numbers (like all numbers in JS). They only thing you can do is to truncate the result back to a 32 bit integer. You'll use the bitwise right shift operator for that which internally casts its operands to integers:

var q = (a / b) >>> 0;

See What is the JavaScript >>> operator and how do you use it? for details.

Community
  • 1
  • 1
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • So am I correct in thinking that regardless of whether I truncate it back to 32, the compiler will still treat it as a double? – Sophia Gold May 28 '16 at 18:53
  • @Sophia: That depends on how clever the compiler is. In terms of the language specification, yes - it's divided as doubles, then cast to integer and then back. That probably what most quick interpreters do as well. An optimising compiler, or an asm.js compiler, [might](http://stackoverflow.com/q/31767070/1048572) decide to do everything with integers (as long as the overall behaviour is the same). – Bergi May 28 '16 at 19:01
  • I could test it on the v8 command line to be sure, but my understanding is it uses inline caching: first running the code *then* going back and optimizing what it can. This is why it says that compiler only works for some code, i.e. there are edge cases it can screw up. So based on that I would assume it would be faster if I truncate a quotient to 32. – Sophia Gold May 28 '16 at 19:15
  • 1
    Yes, it will be faster *when* it is being optimised *because* the explicit truncation takes out those edge cases. – Bergi May 28 '16 at 19:28