asm.js

asm.js performance improvements in the latest version of Firefox make games fly!

The latest version of Firefox which launched last week includes a major update to the user interface as well as to features like Sync. Another area in which this release brings significant improvements is in asm.js performance, which as we will see below is very important for things like games. To put that aspect of Firefox’s performance in context, we’ll take a look at benchmark results comparing Firefox to other browsers, which show that Firefox is faster at executing asm.js code.

asm.js speedups

asm.js is a subset of JavaScript that is very easy to optimize and is particularly useful for porting code in C or C++ to the Web. We’ve blogged about how Firefox can optimize asm.js code using 32-bit floating point operations, which, together with all the other work on optimizing asm.js, allows it to run at around 1.5x slower than the speed of the same C/C++ when compiled natively. So, while not quite native speed yet, things are getting very close. At the time of that blog post those optimizations were only on nightly builds, but they are now reaching hundreds of millions of Firefox users in Firefox 29, which is now the release version of Firefox.

Another important set of asm.js optimizations concern startup speed. As blogged about by Luke a few months ago, Firefox performs ahead of time (AOT) compilation and can cache the results, for significant speedups in startup times. Those optimizations also shipped to users in Firefox 29.

Web browser comparisons

Now that all those optimizations have shipped, it’s interesting to look at up-to-date browser comparisons on asm.js code. The above graph shows the Emscripten benchmark suite running the latest stable versions of Google Chrome, Internet Explorer and Firefox on Windows 8.1. Lower numbers are better in all the results here, which are real-world codebases compiled to asm.js (see notes in the graph).

Unity, Emscripten and asm.js

asm.js is a subset of JavaScript, so it is just one of many styles of JavaScript out there. But it represents an important use case. As we announced at GDC, Unity, one of the most popular game creation tools on the market, will support the Web by using Emscripten to compile their engine to asm.js.

But videos are no substitute for the real thing! You can try the games shown there in your browser right now, for instance with Unity’s recently released Angry Bots demo. If you run those in the latest version of Firefox, you’ll see many of the asm.js optimizations mentioned earlier in action. For example, if you visit one of those links more than once then asm.js caching will allow it to avoid recompiling the game (so it starts up faster), and also gameplay will be smoother due to faster asm.js execution.

Being able to execute asm.js-style code efficiently makes it possible for games like this to run well on the Web, without proprietary, nonstandard plugins. That’s why it’s exciting to see more asm.js optimizations reach Firefox users in Firefox 29. And while benchmark results can sometimes seem like nothing more than abstract numbers, speedups on asm.js benchmarks directly improve things like games, where performance is extremely important and very noticeable.

(Thanks to Marc Schifer for helping with the benchmark measurements.)

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Gap between asm.js and native performance gets even narrower with float32 optimizations

asm.js is a simple subset of JavaScript that is very easy to optimize, suitable for use as a compiler target from languages like C and C++. Earlier this year Firefox could run asm.js code at about half of native speed – that is, C++ code compiled by emscripten could run at about half the speed that the same C++ code could run when compiled natively – and we thought that through improvements in both emscripten (which generates asm.js code from C++) and JS engines (that run that asm.js code), it would be possible to get much closer to native speed.

Since then many speedups have arrived, lots of them small and specific, but there were also a few large features as well. For example, Firefox has recently gained the ability to optimize some floating-point operations so that they are performed using 32-bit floats instead of 64-bit doubles, which provides substantial speedups in some cases as shown in that link. That optimization work was generic and applied to any JavaScript code that happens to be optimizable in that way. Following that work and the speedups it achieved, there was no reason not to add float32 to the asm.js type system so that asm.js code can benefit from it specifically.

The work to implement that in both emscripten and SpiderMonkey has recently completed, and here are the performance numbers:

asm1.5b

Run times are normalized to clang, so lower is better. The red bars (firefox-f32) represent Firefox running on emscripten-generated code using float32. As the graph shows, Firefox with float32 optimizations can run all those benchmarks at around 1.5x slower than native, or better. That’s a big improvement from earlier this year, when as mentioned before things were closer to 2x slower than native. You can also see the specific improvement thanks to float32 optimizations by comparing to the orange bar (firefox) next to it – in floating-point heavy benchmarks like skinning, linpack and box2d, the speedup is very noticeable.

Another thing to note about those numbers is that not just one native compiler is shown, but two, both clang and gcc. In a few benchmarks, the difference between clang and gcc is significant, showing that while we often talk about “times slower than native speed”, “native speed” is a somewhat loose term, since there are differences between native compilers.

In fact, on some benchmarks, like box2d, fasta and copy, asm.js is as close or closer to clang than clang is to gcc. There is even one case where asm.js beats clang by a slight amount, on box2d (gcc also beats clang on that benchmark, by a larger amount, so probably clang’s backend codegen just happens to be a little unlucky there).

Overall, what this shows is that “native speed” is not a single number, but a range. It looks like asm.js on Firefox is very close to that range – that is, while it’s on average slower than clang and gcc, the amount it is slower by is not far off from how much native compilers differ amongst themselves.

Note that float32 code generation is off by default in emscripten. This is intentional, as while it can both improve performance as well as ensure the proper C++ float semantics, it also increases code size – due to adding Math.fround calls – which can be detrimental in some cases, especially in JavaScript engines not yet supporting Math.fround.

There are some ways to work around that issue, such as the outlining option which reduces maximum function size. We have some other ideas on ways to improve code generation in emscripten as well, so we’ll be experimenting with those for a while as well as following when Math.fround gets supported in browsers (so far Firefox and Safari do). Hopefully in the not so far future we can enable float32 optimizations by default in emscripten.

Summary

In summary, the graph above shows asm.js performance getting yet closer to native speed. While for the reasons just mentioned I don’t recommend that people build with float32 optimizations quite yet – hopefully soon though! – it’s an exciting increase in performance. And even the current performance numbers – 1.5x slower than native, or better – are not the limit of what can be achieved, as there are still big improvements either under way or in planning, both in emscripten and in JavaScript engines.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HiDPI support, HTML5 notifications, Parallel JS, asm.js and more – Firefox Development Highlights

Time for another look at the latest developments with Firefox. This is part of our Bleeding Edge and Firefox Development Highlights series, and most examples only work in Firefox Nightly (and could be subject to change).

HiDPI support

We’re happy to say that ico/icns with multiple images are now supported: the highest resolution icon is now used on HiDPI/Retina displays.

Favicon implementation is described in bug 828508 and ico/icns is described in bug 419588.

Performance improvements/Snappy:

Numerous performance improvements have been made, such as faster startup, better scrolling on touchpads and smoother animations.

The most important improvement, however, is probably multithreaded image decoder. The result should be faster page loads and tab switching. All the nitty-gritty detalis are described in bug 716140.

HTML5

When it comes to the world of HTML5 & friends, we have some good additional support:

<input type=”range”>

We now support the <input type="range"> element in forms. To style it, you can use the ::-moz-range-progress:

::-moz-range-progress {
    background: #f00;
}
 
<input type="range">

You can see this <input type=”range”> demo in action on jsFiddle.

HTML5 notifications

HTML5 notifications have now been implemented. Basically, you ask for permission and then you can create a notification:

function authorizeNotification() {
    Notification.requestPermission(function(perm) {
        alert(perm);
    });
}
 
function showNotification() {
    var notification = new Notification("This is a title", {
        dir: "auto",
        lang: "",
        body: "This is a notification body",
        tag: "sometag",
    });
}

See the HTML5 notification demo in action on jsFiddle.

WebAudio API activated by default

WebAudio API has been activated by default in Firefox Nightly. Testers welcome, though there are still work to be done before it can be released.

JavaScript

Parallel JS

The first version of Parallel JS has landed for Firefox. A lot more details in the Parallel JS Lands article.

asm.js

We’re happy to say that asm.js is now in Firefox, scheduled to be released in Firefox 22! Luke Wagner has written more about it in asm.js in Firefox Nightly.

ES6 Arrow function syntax

We now support the ES6 Arrow function syntax

let square = x => x*x;
console.log(square(3));

CSS

@supports activated by default

We plan on releasing this with Firefox 22. More about @supports on MDN.

min-width and min-height ‘auto’ keyword

min-width and min-height 'auto' keyword is no more supported. It has been removed from CSS3 Flexbox. More about that in bug 848539.

CSS Flexbox has been re-enabled

Happy to let you know that CSS Flexbox has been re-enabled by default in Firefox 22, which is currently in Firefox Aurora!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)