- the definition of
inthas been changed to strict 32-bit signed integer - introduce
Promiseclass in conformance to the ECMAScript 6 draft
The second change should be obvious. Let me explain the reasoning behind the first one.
Background:
Until now, definition of
int in JSX has been: a number that is at least possible to represent integers between -231 to 231-1, or may or may not become NaN or +-Infinity.This was based on our understanding that enforcing integer arithmetic in JavaScript (i.e. using
| 0) would lead to slower execution speed. We wanted the int type of JSX to represent some kind of integral numbers without sacrificing execution speed. And the type had been defined as such.But the advent of asm.js has changed the game. Such enforced integer arithmetic is one of the most common patterns found in JavaScript generated by Emscripten (since it compiles C/C++ code), and it would be natural to expect that existing JavaScript runtimes would optimize against such patterns.
The Benchmark:
So I decided to take time to run a tiny benchmark that compares the execution speed of ordinary arithmetic vs. enforced integer arithmetic on fib-using-int - jsPerf, and the results are interesting.
The benchmark compares three functions calculating Fibonacci numbers using loops.
// original
function fib(n) {
var value = 1, prev = 1;
for (var i = 1; i < n; ++i) {
var t = prev;
prev = value;
value += t;
}
return value;
}
// core operation is enforced integer arith.
function fib(n) {
var value = 1, prev = 1;
for (var i = 1; i < n; ++i) {
var t = prev;
prev = value;
value = (value + t) | 0; <--- HERE
}
return value;
}
// core operation and loop are integer arith.
function fib(n) {
n = n | 0; <--- HERE
var value = 1, prev = 1;
for (var i = 1; i < n; i = (i + 1) | 0) { <--- HERE
var t = prev;
prev = value;
value = (value + t) | 0; <--- HERE
}
return value;
}
Looking at the results below (please refer to the benchmark page for the latest numbers) the fact is that code runs about 10% faster on Chrome and Firefox when explicitly specifying an extra operation (i.e.
| 0).
This is not a surprise for people with the understanding of how the JIT (just-in-time-compile) engines of the runtimes work. The engines compile arithmetic operations in the original function of the benchmark into integer arithmetics with guards, so that the calculation can be changed to use floating-point operations once the numbers goes out of the 32-bit integer range. But if
| 0 is added to the statement it becomes clear that the result of the arithmetic should be a module of 232 and thus that the guards become no longer necessary.The Problem and the Solution:
The problem being left is how to write code that takes benefit from such optimizations. It is hard to add
| 0 all over the source code, and there would be a negative performance impact unless you succeed in marking all of them correctly. It is once again clear that some kind of automated code generator is desirable for JavaScript, and this is the reason why we are happily applying the described change to JSX :-)To summarize, JSX as of version 0.9.77 supports strict 32-bit integer arithmetic; and it is easy for the users to benefit from the described optimizations within the JavaScript runtimes. It's just a matter of marking some variables as
: int. And the results of assignment to the variable as well as additions, subtractions, and multiplication between such variables would be int.PS. I have also written the Fibonacci calculator in asm.js, but have excluded the numbers from the benchmark since it was too slow. It seems that there exists a non-marginal overhead when calling asm.js code from JavaScript.
