There are several different ways to represent floating-point numbers in computers: most architectures now use the IEEE754 standards, representing double precision numbers with 64 bits (a.k.a double, or float64) and single precision numbers with 32 bits (a.k.a float32). As its name suggests, a float64 has more precision than a float32, so it’s generally advised to use it, unless you are in a performance-sensitive context. Using float32 has the following advantages:<\/p>\n
Float32Array<\/code> to store data, which is often true for JS code using WebGL, as well as Emscripten<\/a>-compiled code where a float<\/code> in C++ is stored as a float32 in memory but uses JavaScript float64 arithmetic.)<\/li>\n- Float32 numbers take half the space, which can decrease the total memory used by the application and increase the speed of memory-bound computations.<\/li>\n
- Float32 specializations of math functions in several standard C libraries we’ve tested are way faster than their float64 equivalents.<\/li>\n<\/ul>\n
In JavaScript, number values<\/a> are defined to be float64 and all number arithmetic is defined to use float64 arithmetic. Now, one useful property of float64 arithmetic that JavaScript engines have taken advantage of for a long time is that, when a float64 is a small-enough integer, the result of a float64 operation is the same as the corresponding integer operation when there is no integer overflow. JavaScript engines take advantage of this by representing integer-valued numbers as raw integers and using integer arithmetic (and checking for overflow). In fact, there are at least 3 different integer representations in use that I know of: 31-bit integers, int32_t<\/code> and uint32_t<\/code> (see this post about value representation<\/a> by Andy Wingo for more).<\/p>\nGiven all this, a good question is: can we do a similar optimization for float32? Turns out, the answer is “sometimes” and, using the new Math.fround<\/code><\/a> function in the upcoming ES6 spec, the programmer has a good way to control when.<\/p>\nWhen can we safely use float32 operations instead of float64 operations<\/h3>\n
\n There is an interesting commutative identity satisfied by some float64 and float32 operations, as stated by Samuel A. Figueroa in “When is double rounding innocuous?<\/a>” (SIGNUM Newsl. 30, 3, July 1995, 21-26): as long as the original inputs are float32, you can either use float32 operations or float64 operations and obtain the same float32 result. More precisely, for op<\/code> one of {+,-,*,\/}<\/code>, and op_f32<\/code> the float32 overload and op_f64<\/code> the float64 overload, and x<\/code>,y<\/code> float32 values, the following identity holds, expressed as C++ code:<\/p>\n\r\n assert(op_f32(x,y) == (float) op_f64( (double)x, (double)y ));\r\n<\/pre>\nThe analogous unary identity also holds for sqrt<\/code> and several other Math functions.\n<\/p>\nThis property relies crucially on the casts before and after every single operation. For instance, if x = 1024, y = 0.0001, and z = 1024, (x+y)+z<\/code> doesn’t have the same result when computed as two float32 additions as when computed as two float64 additions.\n<\/p>\nThis identity provides the preconditions that allow a compiler to soundly use float32 instructions instead of float64 instructions. Indeed, gcc will take advantage of this identity and, for expressions of the form on the right of the equation, will generate float32 code corresponding to the expression on the left.<\/p>\n
But when does JavaScript ever have a float32 value? In HTML5 (with WebGL and, thus, Typed Arrays), the answer is: when reading from or writing to a Float32Array<\/code>. For example, take this piece of code:<\/p>\n\r\n var f32 = new Float32Array(1000);\r\n for(var i = 0; i < 1000; ++i)\r\n f32[i] = f32[i] + 1;\r\n<\/pre>\nThe addition inside the loop exactly matches the identity above: we take a float32 value from f32<\/code>, convert it to a float64, do a float64 addition, and cast the result back to a float32 to store in f32<\/code>. (We can view the literal 1<\/code> as a float32 1<\/code> cast to a float64 1<\/code> since 1<\/code> is precisely representable by a float32.)\n<\/p>\n\nBut what if we want to build more complicated expressions? Well, we could<\/em> insert unnecessary Float32Array<\/code> loads and stores between each subexpression so that every operation's operands were a load and the result was always stored to a Float32Array<\/code>, but these additional loads and stores would make our code slower and the whole point is to be fast. Yes, a sufficiently smart compiler<\/a> might be able to eliminate most of these loads\/stores, but performance predictability is important so the less fragile we can make this optimization the better. Instead, we proposed a tiny builtin that was accepted into the upcoming ES6 language spec: Math.fround<\/code>.\n<\/p>\nMath.fround<\/h3>\n
Math.fround<\/code><\/a> is a new Math function proposed for the upcoming ES6 standard. This function rounds its input to the closest float32 value, returning this float32 value as a number. Thus, Math.fround<\/code> is semantically equivalent to the polyfill:
\n<\/p>\n\r\n if (!Math.fround) {\r\n Math.fround = (function() {\r\n var temp = new Float32Array(1);\r\n return function fround(x) {\r\n temp[0] = +x;\r\n return temp[0];\r\n }\r\n })();\r\n }\r\n<\/pre>\n<\/a><\/p>\n
Note that some browsers don't support Typed Arrays; for these, more complex polyfills are available<\/a>. The good news is that Math.fround is already implemented both in SpiderMonkey (the JavaScript engine behind Firefox) and JavaScriptCore (the JavaScript engine behind Safari). Moreover, v8's team plans to add it as well, as states this issue.<\/a><\/p>\nAs a result, the way to chain float32 operations is simply to wrap any temporary result in a call to Math.fround<\/code>:<\/p>\n\r\n var f32 = new Float32Array(1000);\r\n for(var i = 0; i < 999; ++i)\r\n f32[i] = Math.fround(f32[i] + f32[i+1]) + 1;\r\n<\/pre>\n<\/p>\nIn addition to allowing the programmer to write faster code, this also allows JS compilers, like Emscripten<\/a> to better compile float32 in the source language. For example, Emscripten currently compiles C++ float<\/code> operations to JavaScript number operations. Technically, Emscripten could use Float32Array<\/code> loads\/stores after every operation to throw away the extra float64 precision, but this would be a big slowdown, so fidelity is sacrificed for performance. Although it's quite rare for this difference to break anything (if it does, the program is likely depending on unspecified behavior), we have seen it cause real bugs in the field and these are not fun to track down. With Math.fround<\/code>, Emscripten would be able to be both more efficient and<\/em> higher fidelity!<\/p>\nFloat32 in IonMonkey<\/h3>\n
My internship project<\/a> was to bring these optimizations to Firefox. The first step was to add general support for float32 operations in the IonMonkey JIT backend. Next, I added Math.fround<\/code> as a general (unoptimized) builtin to the JavaScript engine. Finally, I added an optimization pass that recognizes Float32Array<\/code>\/Math.fround<\/code> and uses their commutative properties to emit float32 operations when possible. These optimizations are enabled in Firefox 27 (which is currently in the Aurora<\/a> release channel)<\/a><\/p>\nSo, how does it perform? Microbenchmarks (in both C++ and JavaScript) show large speedups, up to 50%. But micro-benchmarks are often misleading, so I wrote the following more-realistic benchmarks to see what sort of speedups on float32-heavy computations we can expect to see in practice:<\/p>\n
\n- \n
Matrix inversions<\/strong>: this benchmark creates a bunch of matrixes, inverts them and multiplies them back with the original, to be able to compare the precision loss when using float32 or float64. It uses an adapted version of gl-matrix<\/a>, which is a framework used for real-world applications using WebGL matrixes. For the float32 version, only calls to Math.fround<\/code> have been added.\n<\/li>\n- \n
Matrix graphics<\/strong>: this benchmarks also creates a bunch of matrixes and applies some operations that are frequently used in graphics: translation, rotation, scaling, etc. This one uses a lot of basic operations and more complex operations (like calls to Math.cos<\/code> and Math.sin<\/code> for the rotation). Thus, it shows great improvements when the float32 equivalent forms of these functions are faster. Once more, it uses the adapted version of gl-matrix<\/p>\n- \n
Exponential<\/strong>: this benchmark fills a big Float32Array<\/code> with predictable values and then computes the exponential of each element by using the first elements of the exponential's power series<\/a>. The main purpose of this benchmark is just to pound on addition and multiplication.<\/p>\n- Fast Fourier Transform<\/strong>: this benchmark creates a fake sample buffer and then applies several steps of Fast Fourier Transform. It also consists of basic operations and some calls to
Math.sqrt<\/code>. The FFT code is taken from an existing library, dsp.js<\/a>.<\/p>\n<\/ul>\nThe following table shows results on several different devices, when run on the latest Firefox Nightly. The number indicates the obtained speedup from using code that has been optimized to use Math.fround<\/code> to allow the float32 optimization described above (thus the higher, the better). The desktop machine used is a ThinkPad Lenovo W530 (Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 8 cores, 16 GB RAM). When a line indicates a phone or tablet device, the device runs the latest Firefox Nightly for Android version. Once you've read these results, you can try to run these benchmarks<\/a> by yourself! (Don't forget to use Firefox 27 or greater!) You can see the benchmark source on github<\/a> (on the gh-pages branch).<\/p>\n