Surprise! Mozilla can produce near-native performance on the Web

We put Mozilla's JavaScript subset—asm.js—to the test.

Read the whole story

 

[paleozogt]

I know everyone hates Flash, but fyi Adobe's FlasCC (formerly Alchemy) has been doing this (LLVM->AS3) since 2008. It even has support for proper threading.

 

[heinousjay]

Kitzbuehl[/url]":ykq27jga]The main objective of Java, and so Javascript, stand in the fact to have only one language for any software or hardware platform.

What does that even mean? Aside from the fact that Java and JavaScript are unrelated, there are a number of languages that target the JVM.

 

[kripkenstein]

kruzes[/url]":34rk0otz]

Other browsers don't have special asm.js support at all. Google expressed some interest in adding asm.js optimizations to Chrome, but it hasn't done so yet. Worse, our testing showed that the use of asm.js actually hurt performance in non-asm.js browsers.

This isn't exactly right. Google expressed an interest in figuring out why asm.js ran slow in V8. They found out that some of things in the asm.js spec were handled particularly badly by the V8 JIT, and proceeded to a) promptly fix the low hanging fruit and b) understand how the overall design can better accommodate something like asm.js.

As far as I can tell, there has been no effort underway to support looking for a "use asm" string placed in the first line of a top-level function

There is no need to explicitly detect the "use asm" hint. It can help do AOT compilation, but v8 might be able to reach similar stable-state performance without it. It's getting closer: http://www.arewefastyet.com/#machine=11 ... asmjs-apps

and if one is found use this other compiler that works in a totally different way instead.

It is not another compiler, and doesn't work in a totally different way. All OdinMonkey (SpiderMonkey's special asm.js optimization module) does is see "use asm", type check the code, and pass that info into the existing optimizing JIT in SpiderMonkey. So practically all the work is done by the existing JIT, and that's why this was such a quick project to get going: It builds on years of building fast JITs in JS engines, that all browsers have been doing.

 

[Sobels]

CobraA2[/url]":2oibnzmt]

These engines brought something new to the world of JavaScript: high performance achieved through just-in-time (JIT) compilation.

I'd like a fact check on this. I could've sworn I remember JIT compilation in the '90s. V8 was a major performance boost, but I don't think it was the first to use JIT. I think it changed how JIT worked, not whether or not it was JIT.

The oldest example of JIT in action was used to run LISP in the 60's. However, V8 and Tracemonkey were the first JIT compilers for Javascript. Before then, Javascript was run in an interpreter. The switch to a JIT compiler from an interpreter brought massive, massive speed boosts with it.

 

[Xavin]

I'm for anything that lets us use a good language for web apps instead of javascript, but asm.js seems like a terrible hack. I think Google and MS just need to get together and force through some kind of web VM and bytecode. Put it in IE and Chrome and everyone else will pretty much be forced to follow along, bypassing all the irrational javascript fanatics on the standards committees.

 

[DrPizza]

computers_are_bad[/url]":xbqntkg8]This is a mostly useless comparison because the native code explicitly had SIMD instructions disabled. It's easy to make native code look slow when you deliberately cripple it.

It did no such thing.

 

[microbrew]

atu30004[/url]":1v0rszxf]I haven't read any of the comments, so please forgive me if this has been pointed out by someone else.

It seems to me that it is just now being realised that all the "advances" in programming of the last many years--starting with 'object-oriented' programming--comes at a price: complexity at the "out-of-sight-out-of-mind (machine; memory-consumption) level. Certainly, program creation is apparently easier than it used to be, but people are rightly starting to investigate and ask, "Just exactly why is "C" and "assembly language" so much faster than anything else we do?"
The proper place to start, to solve a problem such as this, is at the beginning.

Because the industry wants commodity programmers and fast development. Then throw in the JIT and virtual machine/interpreter requirements...

I'm an embedded guy, write mostly in C - even C++ is flawed (https://en.wikipedia.org/wiki/Embedded_C%2B%2B). Performance sensitive code gets special attention so that the right assembly is generate. We have to manually manage memory and cache- we structure data flows to avoid cache misses. This is slow, expensive and bug-ridden.

 

[drfisheye]

Impressive as it is, asm.js still needs all browsers to co-operate. In that sense, it's just like NaCl or Dart. The big question for any HTML solution is, will everyone play along or not?

I sometimes wonder if MS and Apple play a delicate power game. If HTML apps become too powerful, their closed ecosystems get hurt. If they co-operate too little, Google will go its own way, possibly creating a competitive edge.

Where will it end? Very interesting times.

 

[Travis Griggs]

I saw one graph where it the performance was "near". Why was this article titled "near" when "near" was the exception rather than the norm?

 

[Stargrazer]

TheFerenc[/url]":26zscy15]

smoofles[/url]":26zscy15]Their rendering engine still sucks balls. Fast computing only helps so much if you can't even get image scaling right or you engine starts acting up with complicated (HTML-based) scenes.

But, hey, good that they can run a 3D engine in the browser and offer a Social API. Who needs HTML/CSS rendering quality, amirite?

Just try using the digikey search box. In IE, there is a clearly delineated search box. In firefox on my RHEL6 install, the word "Search" is in one white box, while the actual text entry field is another, identical, offset and weirdly placed white box. Makes it a real PITA to search for things, since the first thought of most people (IME), is to click on the thing that looks like a text box with the word Search in it.

Where do you find this misbehaving search box? When I look at www.digikey.com, the search boxes appear fine (and the same) in both IE and FF. Moreover, none of the search boxes I've seen there contain the word "Search". Depending on where on their page you look (front page or "inside") the appearance varies a bit, but the word "Search" is above or to the left of the box, and the search box contains the words "Part number/keyword". For both IE and FF, these words appear nicely inside the search box.

 

[agrouf]

This is very good piece of technology and it has some applications. The problem I see is that people will misuse and abuse it. The web is semantic for a good reason. The content is structured. It is accessible both by impaired people and by computers like search engines and stuff. One of the main problem of the web is the cargo cult design. Many web designers think they must use technology that is not suited for web development, like using flash to display menus or rotating tag clouds. High performance javascript has its niche, like web games but I fear people will use it to display flying text and annoying effects that discard the semantic of their site. Maybe there should be some proper education on when and how to use this kind of technology.

 

[binji]

I would like to look at NaCl too, but making it work is a little more involved than asm.js. If there's enough interest, it's certainly something I could take a look at.

Hi Peter, I work on the Native Client team. Can you mention a few things that make it more involved? We'd love to be able to make this easier.

 

[jimjimjimjimjim]

Faramir[/url]":3hc6ucjs]I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which seems a) unwarranted and b) overkill for the problem of untrusted code.

The alternative to having everything run in a browser seems to be platform specific apps (iOS, Android, Windows, etc).

That said, it seems that it's not so much about having everything run in a browser, it's about demonstrating that the technology really is good enough for a lot of things. Even if you don't run everything in a bowser, it's another tool in the box. It's nice to have the option.

 

[name99]

szpet[/url]":2uvipi0b]

thegeneral[/url]":2uvipi0b]The wonders of a post Flash world.

Flash has this kind of thing since long time:
http://gaming.adobe.com/technologies/flascc/
The wonders of reinventing.

And yet no-one gives a damn about it.

Perhaps this tells us something of the consequences of sitting on your ass for ten years, shipping a product that is slow and riddled with security bugs? Turns out that by the time you claim to have changed your ways, NO-ONE is willing to give you the benefit of the doubt...

 

[jimjimjimjimjim]

paleozogt[/url]":30km2fre]I know everyone hates Flash, but fyi Adobe's FlasCC (formerly Alchemy) has been doing this (LLVM->AS3) since 2008. It even has support for proper threading.

Flash is dead or dieing on a lot of platforms that matter.

 

[CobraA2]

Sobels[/url]":2steore8]

CobraA2[/url]":2steore8]

These engines brought something new to the world of JavaScript: high performance achieved through just-in-time (JIT) compilation.

I'd like a fact check on this. I could've sworn I remember JIT compilation in the '90s. V8 was a major performance boost, but I don't think it was the first to use JIT. I think it changed how JIT worked, not whether or not it was JIT.

The oldest example of JIT in action was used to run LISP in the 60's. However, V8 and Tracemonkey were the first JIT compilers for Javascript. Before then, Javascript was run in an interpreter. The switch to a JIT compiler from an interpreter brought massive, massive speed boosts with it.

Humm, maybe I was thinking Java. My research indicates it had JIT long before JavaScript.

Can't even trust my memory anymore, sigh .

 

[gbjbaanb]

name99[/url]":2a2chgqy]

szpet[/url]":2a2chgqy]

thegeneral[/url]":2a2chgqy]The wonders of a post Flash world.

Flash has this kind of thing since long time:
http://gaming.adobe.com/technologies/flascc/
The wonders of reinventing.

And yet no-one gives a damn about it.

Perhaps this tells us something of the consequences of sitting on your ass for ten years, shipping a product that is slow and riddled with security bugs?

I don't think its due to Adobe being useless, not this time. The lack of uptake in this is exactly the same reason NaCl, Dart and even Silverlight havn't taken off - they're not bundled with every browser. Its the same reason loads of websites used to (and still do, grr) work with IE6 only - it was the dominant browser so everyone coded to that spec. Thank goodness Firefox came along and dragged them into the light, but the point remains - until someone or something happens to make a feature available on all browsers, it will not get much uptake.

I think the only way for this to happen is for the W3C or other standards body to come up with the specification of a new programming model for client-side browsers. Then, after a few years, we'd start to get it implemented everywhere. This is why asm.js is being written ontop on js, its an attempt to short-circuit this and get it out there for everyone sooner.

 

[DrPizza]

binji[/url]":1599firt]

I would like to look at NaCl too, but making it work is a little more involved than asm.js. If there's enough interest, it's certainly something I could take a look at.

Hi Peter, I work on the Native Client team. Can you mention a few things that make it more involved? We'd love to be able to make this easier.

Hi.

With Emscripten, I could take a standard C or C++ program, identical to the one that I use for the native performance testing, and simply recompile it. When set to produce HTML output, Emscripten includes the extra bits and pieces needed to bootstrap the code and call main() for me. NaCl seems to be more complicated: I'd have to write some kind of stub to bridge from the Pepper module API and main, as well as generate all the relevant manifests and HTML.

 

[Faramir]

jimjimjimjimjim[/url]":f5jnaze3]

Faramir[/url]":f5jnaze3]I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which seems a) unwarranted and b) overkill for the problem of untrusted code.

The alternative to having everything run in a browser seems to be platform specific apps (iOS, Android, Windows, etc).

Even if the javascript runs identically across platforms you still have to do a lot of customization to deal with radically different display and input hardware. And even after you've done all that what you are left with is strictly inferior to something actually designed for each platform. It is for that reason, among others, you don't see many java swing GUIs, which is the last technology that promised write once, run anywhere.

 

[WaltC]

IMO, people's physical Internet connections will continue to be the biggest bottleneck of performance (as opposed to code running in the local environment.) Unless you've already downloaded all the code you need to run...

 

[Tundro Walker]

What I think would be interesting is if maybe someone like the W3C came up with a "standardized" javascript usage library. A lot of sites that use javascript do the same things with it... buttons, banners, etc. If there was a standardized library, a page could say something like "look for this standardized, compiled component on user machine first, and if it's not found then snag the component from us, compile it, and keep it in cache for future use (from us and other sites that may use it)." I guess that would be sort of like javascript versions of dll's. Instead of each site dumping their own version into your web cache, they can trim down the javascript to a standardized library for most of the functions. Maybe I'm talking out of my ass here.

 

[salvarinho]

This is why I'm a paying 'subscriptor'. Fantastic article, Peter! Keep'em coming

 

[drfisheye]

Tundro Walker[/url]":3g8b88bb]What I think would be interesting is if maybe someone like the W3C came up with a "standardized" javascript usage library. A lot of sites that use javascript do the same things with it... buttons, banners, etc. If there was a standardized library, a page could say something like "look for this standardized, compiled component on user machine first, and if it's not found then snag the component from us, compile it, and keep it in cache for future use (from us and other sites that may use it)." I guess that would be sort of like javascript versions of dll's. Instead of each site dumping their own version into your web cache, they can trim down the javascript to a standardized library for most of the functions. Maybe I'm talking out of my ass here.

That scheme doesn't sound very secure. Your site can't be a trusted source for reusable components, since you could modify the component.

But clever use of caching libraries is possible. Some libraries for example are hosted on sites like Google Code. If you point your page to a library hosted there, then the browser can reuse the library for other sites pointing to the same library with the same url. Of course this means you need to trust Google Code and the makers of the library, if not then you'd better host your own copy.

 

[Faramir]

Tundro Walker[/url]":qda1wk9f]What I think would be interesting is if maybe someone like the W3C came up with a "standardized" javascript usage library. A lot of sites that use javascript do the same things with it... buttons, banners, etc. If there was a standardized library, a page could say something like "look for this standardized, compiled component on user machine first, and if it's not found then snag the component from us, compile it, and keep it in cache for future use (from us and other sites that may use it)." I guess that would be sort of like javascript versions of dll's. Instead of each site dumping their own version into your web cache, they can trim down the javascript to a standardized library for most of the functions. Maybe I'm talking out of my ass here.

HTML have something like this in that more widgets, for lack of a better word, are getting tags that are then left up to the browser implementer to build. So for example, instead of choosing one of the hundred date pickers out there, in a compliant browser you can include: <input type="date"> and the browser chooses a widget that works for its environment. No need to download or parse any javascript for that widget, it's all built into the browser.

 

[Haravikk]

Brutha[/url]":3ep8zgu1]Why can't someone apply the same solutions Apple does with obj-c? v-table lookups, etc?

They do. However, the problem with Javascript isn't just dynamic typing, it's portability and usability; Javascript isn't precompiled, and is instead sent as source code so that any browser that supports Javascript can run it, with no worries about the hardware that a browser is running on.

However, this means that Javascript is completely uncompiled when it enters a user's browser, and as a result compilers can't just compile code to be as optimal as possible, because they also need to be able to compile it quickly (otherwise a site would seem slow and unresponsive).

There are ways to compile Javascript into a runnable binary like C or C++, and these can be pretty fast. Even so, Javascript's free-form dynamic variables and handling of objects can be a bit of a hurdle, as they're even less restrictive than Objective-C's capabilities.

 

[simpleWho]

styron[/url]":rlwuglk6]

Faramir[/url]":rlwuglk6]I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which a) seems unwarranted and b) seems like overkill for the problem of untrusted code.

10 yrs ago I would wonder why people would want to stream music or video instead of downloading it and playing it locally.

That way they could play it again and again without wasting network traffic/bandwidth and they wouldn't have to put up with excessive compression, buffering headaches, broken connections etc.

Now I hardly care, and streaming has some advantages around multiple devices and not having to maintain media libraries etc.

Apps moving to browsers is the same kind of progression. Yes it kind of sucks at the moment (especially for complex apps), but year by year it sucks less, and the advantages around not having to maintain software start becoming more compelling.

It isn't about right now - it's about 5-10yrs time.

Local playback is still better than streaming. All youtube videos play better when downloaded locally. It lets me use the awesome feature of vlc to speed up the playback to reduce my viewing time by one half.

Network is still an issue; most of all its reliability and that will always be inferior to local playback.

The problem is not in the concept of local playback. The problem is in lack of maturity in software that should treat all playbacks as local and when it is not locally available, have enough information to fetch it from a resource online.

 

[Faramir]

Haravikk[/url]":7lshhll9]

Brutha[/url]":7lshhll9]Why can't someone apply the same solutions Apple does with obj-c? v-table lookups, etc?

They do. However, the problem with Javascript isn't just dynamic typing, it's portability and usability; Javascript isn't precompiled, and is instead sent as source code so that any browser that supports Javascript can run it, with no worries about the hardware that a browser is running on.

However, this means that Javascript is completely uncompiled when it enters a user's browser, and as a result compilers can't just compile code to be as optimal as possible, because they also need to be able to compile it quickly (otherwise a site would seem slow and unresponsive).

There are ways to compile Javascript into a runnable binary like C or C++, and these can be pretty fast. Even so, Javascript's free-form dynamic variables and handling of objects can be a bit of a hurdle, as they're even less restrictive than Objective-C's capabilities.

One of the interesting thing about dynamic typing is how rarely the extreme flexibility it offers is actually used.

E.g. you'll almost never see code like this:

var i = 0;
...
i = "Hello World!"

Modern javascript engines exploit this fact, and optimize the heck out of the the i-will-always-be-numeric-path, but they can't get rid of the guards that check to insure that always remains true. The big advantage to static analysis (i.e. compiling) is that you can sometimes get rid of those guards altogether.

 

[Blakflag]

asm.js reminds me of an evolutionary shortest path, such as our eyes evolving upside down vision which we correct for in our nervous system, because it was the shortest route to sight. It's not optimal, but the need is great so we make do with what we have.

I was not initially a fan of the whole compiling to javascript thing. It's really dumb in fact. But if it's the way to escape WRITING and, more importantly, MAINTAINING, large codebases code in javascript.. then sign me the hell up! Maybe once we have tons of other languages being used for web app source, then the browsers will have more incentive to come up with more efficient bytecode targets (to achieve competative advantage).

I think Googles Dart is actually pretty genius. It WILL compile to Javascript, at a small performance/space penalty. So it will run everywhere but BEST on Chrome. If people start using it, it wont be long before everyone else is busting down the door to implement Dart engines of their own to nullify Chrome's perceived performance advantage.

 

[Blakflag]

One of the interesting thing about dynamic typing is how rarely the extreme flexibility it offers is actually used.

E.g. you'll almost never see code like this:

var i = 0;
...
i = "Hello World!"

Modern javascript engines exploit this fact, and optimize the heck out of the the i-will-always-be-numeric-path, but they can't get rid of the guards that check to insure that always remains true. The big advantage to static analysis (i.e. compiling) is that you can sometimes get rid of those guards altogether.

So true. In fact, I have seen it bite people back hard. Such as, dev A is using this thing as a string. Dev B passes in integers. They both work fine because of the squish factor of type conversion. But oh look, six months down the line they start to pass it to the server in Json, and all of the sudden OMG we haz issuez. By then there's so much crap on the client assuming A or B, it's a mess.

The lack of typing merely caused confusion, it did not provide either developer with any flexibility other than the ability to screw themselves. I wish this was more widely acknowledged, other than by replying "more unit tests". Well sure, if you want to spend 8 hours unit testing "what type am I now".. go crazy. I'll write in another language, thanks.

 

[jimjimjimjimjim]

Faramir[/url]":316zmasw]

jimjimjimjimjim[/url]":316zmasw]

Faramir[/url]":316zmasw]I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which seems a) unwarranted and b) overkill for the problem of untrusted code.

The alternative to having everything run in a browser seems to be platform specific apps (iOS, Android, Windows, etc).

Even if the javascript runs identically across platforms you still have to do a lot of customization to deal with radically different display and input hardware. And even after you've done all that what you are left with is strictly inferior to something actually designed for each platform. It is for that reason, among others, you don't see many java swing GUIs, which is the last technology that promised write once, run anywhere.

It doesn't have to be unequivocally superior. It has to be good enough. For example Flash is absolutely horrible for playing video by most standards but it's apparently good enough to be used everywhere.

Not that I think that asm.js will ever suck like Flash but clearly measures of "absolute best" aren't everything.

 

[Hopper262]

I'd like to see the last graph (hand-rolled comparison) include IE as well. In IE 10, Emscripten-written asm.js lost to Emscripten-written JS, but how does it do against hand coding? That's outside this article's scope, but perhaps you can consider it for a future topic... this is Ars at its best, going beyond the press releases and doing what readers lack the time/skills/connections to do themselves.

 

[Matt Raymond]

This doesn't mean that Chakra is necessarily slower in "real life"; the code produced by Emscripten is substantially unlike any normal code that browsers would run. It may not be altogether surprising that they don't handle it well.

Stop making excuses for Chakra. Emscripten outputs JavaScript that uses typed arrays to increase performance, and Internet Explorer 10 is supposed to support Typed Arrays. If not for things like Emscripten, why did they add support for Typed Arrays in the first place, because it certainly wasn't for WebGL.

 

[quaint]

simpleWho[/url]":2xsenw16]Local playback is still better than streaming. All youtube videos play better when downloaded locally. It lets me use the awesome feature of vlc to speed up the playback to reduce my viewing time by one half.

Interesting that you chose that line of reasoning, considering that when you watch videos in Youtube (with HTML5 mode enabled), you get to choose the playback speed (including the option of doubling it).

In any case, I see little difference between HTML5 video and a dedicated video player for videos that both support. For those, you could build a perfectly capable HTML app.

 

[drfisheye]

Matt Raymond[/url]":2748in6j]

This doesn't mean that Chakra is necessarily slower in "real life"; the code produced by Emscripten is substantially unlike any normal code that browsers would run. It may not be altogether surprising that they don't handle it well.

Stop making excuses for Chakra. Emscripten outputs JavaScript that uses typed arrays to increase performance, and Internet Explorer 10 is supposed to support Typed Arrays. If not for things like Emscripten, why did they add support for Typed Arrays in the first place, because it certainly wasn't for WebGL.

IE11 will have WebGL. So "it certainly wasn't for WebGL" is not that certain.

 

[Metasyntactic]

Faramir[/url]":1br2ldps]I don't understand why people seem to think that every sort of program should run in a browser.

The browser is an ideal distribution platform since pretty much *everyone* has one on pretty much *every* device they have.

 

[quaint]

Faramir[/url]":1e3bfsds]
Even if the javascript runs identically across platforms you still have to do a lot of customization to deal with radically different display and input hardware. And even after you've done all that what you are left with is strictly inferior to something actually designed for each platform. It is for that reason, among others, you don't see many java swing GUIs, which is the last technology that promised write once, run anywhere.

Creating something with HTML doesn't mean you have to make sure it's usable and optimized for every HTML supporting platform. Even HTML apps can target just desktop systems, for example.

Games rarely follow UI design patterns for any given platform, so even if you used the same for all platforms, it wouldn't stand out too much. If your application can take a 30% slowdown (but not, say, 90%), asm.js might provide you with the tools to make users' lives easier, as instead of downloading and installer and running it, they can simply point their browser to somewhere and start clicking away (even with OSX, or even rarer species of OS).

Nice article (the kind you want to read in Ars). Glad you didn't stop at the hype phase, comparing the tool only against handicapped native code. There's little doubt, however, that Chakra is slower with all kinds of Javascript, and it's just not measurable with light loads (such as web pages) because there's not much to measure.

 

[minifig404]

Just a random side-note: C is the fastest language tested by The Computer Language Benchmarks Game. The second fastest langauge is C++, at < 3x slower than C. Fortran is extremely comparable. Python, PHP, and Ruby are all around 10-100 times slower than C, depending on details and varying widely. The two features I notice as slowing languages down (without a lot of insight into the languages being tested) are (1) Dynamic typing, and (2) Object-oriented Programming.

Food for thought.

 

[LexaGrey]

If space is not at too much of a premium I would seperate some of those graphs a bit more for clarity.

I would be interested in Chrome JIT compiled JavaScript and Safari Nitro JavaScript benchmarks to be included as well as NaCl and Dart benchmarks to be included in the graphs just to see an overview of the current browser landscape for a more complete overview of different optimization technologies.

 

[stormbeta]

Matty[/url]":18kfmtol]The web has come to so much success because it is open.

Sure you can obfuscate Javascript to some extent, but it is rare.

I'm sure many on this site have had a peek at other sites JS/CSS/HTML.

I'd be worried about a web where asm.js became the norm. Closed applications would be the norm.

It's about open standards more than open code bases. Closed code bases for websites is already the norm - the code executing in the browser is just client-side logic, it's not the whole application.

That's not to say that open source doesn't have a role, because it absolutely does, but the point of the web wasn't open source, it was open standards and interconnectivity.

 

[toyotabedzrock]

Opera's javascript engine turns script into sse2. Which is why it crushes other browsers in select tests.