

Chrome and Opera Optimize for Mozilla-Pioneered Asm.js - ndesaulniers
https://blog.mozilla.org/futurereleases/2013/11/26/chrome-and-opera-optimize-for-mozilla-pioneered-asm-js/

======
pvnick
Asm.js is intrinsically superior to native client (and yes, I do see them as
competing technologies) and will inevitably push NaCl out of the market for
one simple reason: even if the browser doesn't explicitly optimize for asm.js,
_the code will still run_. It may not be usably fast, but something will
happen. As opposed to native client, where if your user base doesn't support
it you're just dead in the water. And the trend so far is javascript getting
faster and closer to native running code. Google _must_ eventually build
asm.js optimizations into Chrome. What's their alternative strategy? Ignore
asm.js and let Mozilla tout Firefox's javascript engine as faster? NaCl's
writing is on the wall and Google knows it.

~~~
ajross
I'm not sure "intrinsically superior" is the right way to think about this. If
you were asked for a mechanism to get web clients to execute stuff "fast" that
was generated from a traditional C-like compiler front end, you _surely_
wouldn't have designed asm.js. You'd probably have ended up with something
more like the JVM or PNaCL.

It's true that asm.js wins for compatibility, for obvious reasons. And that's
a powerful advantage. And it works in the same runtime that existing web apps
do, which likewise a win; Java and especially NaCl have complicated
interoperability paradigms. They are not just "a faster web page", which is
what 90% of developers really wanted to begin with.

That said, the remaining 10% really do want something more. They want to write
targetted architecture-specific assembly, perhaps. They want access to
syscall-level abstractions like threads and true sockets (buffer sizes, Nagle
settings, timeouts, etc...). And asm.js has nothing for these people.

And despite its simlicity, asm.js is still mostly just a toy. It's got one
working compiler backend that isn't packaged sanely anywhere. I've three times
now decided to get serious and build emscripten from source, and three times
given up -- it lags LLVM releases, it has glitchy behavior. Compare to clang
and especially gcc which build robustly and cleanly everywhere and come with
elaborate test suites. This isn't a toolchain I'm about to start betting a
company on, for sure.

Give it time. I like asm.js too. But it's never going to be The Answer to
remotely deployable "native like" code any more than Java was.

~~~
josteink
_I 'm not sure "intrinsically superior" is the right way to think about this._

It's fast enough. It's compatible with the existing web. It's platform
independent. It runs in any standards-compliant web-browser. That's four wins
right there.

It's fundamentally superior. End of discussion.

 _That said, the remaining 10% really do want something more. They want to
write targetted architecture-specific assembly, perhaps._

If they do, they can go do it somewhere which isn't the open web.

When I use a web-browser, me and my devices aren't going to wait for you to
fix your webpage to support the architecture I happen to be running. We're
going to go somewhere else.

Imagine how _impossible_ it would have been for early Macs and ARM-devices to
enter the market if the web was already entrenched in platform-specific Intel
x86 code. How many of those websites out there do you think would have been
"fixed" in order to work on other platforms, years after the authors abandoned
them? I'm guessing a tiny fraction.

They didn't have to though, because the web is cross-platform. This is by
design.

We should thoroughly ignore Google's best efforts to reverse this with their
proprietary NaCl. Why on earth would we want to change the best quality of the
web now that it has already proven its value?

~~~
haberman
> Imagine how impossible it would have been for early Macs and ARM-devices to
> enter the market if the web was already entrenched in platform-specific
> Intel x86 code.

Are you aware that NaCl (the platform-specific version) is only enabled for
applications installed through the Chrome Web Store? Chrome will not load NaCl
modules from the web. All that is supported for the web is PNaCl, which is
platform-independent. See: [https://developers.google.com/native-
client/dev/nacl-and-pna...](https://developers.google.com/native-
client/dev/nacl-and-pnacl)

So your hypothetical is not in danger of happening.

~~~
josteink
Ok. Fair enough.

That said, that's not what the post I was replying to was suggesting. It was
suggesting writing _architecture-specific assembly_ code and putting it on the
web. And citing that as a legitimate need which should be addressed by
browser-vendors.

Needless to say, as someone who supports an open, cross-platform web, I
strongly oppose any such measure.

------
reissbaker
Is this accurate? My understanding was that the V8 team wasn't explicitly
optimizing for asm.js, and just optimized V8 in general (and that often asm.js
hit fast-paths even without explicit optimization).

It sounds from the article like Epic announced that Chrome/V8 is fast enough
to run the Unreal 3 engine, and Mozilla's trying to spin it as V8 explicitly
optimized for a "spec" invented by Mozilla when actually they just made V8
really, really fast.

That said, they do include an asm.js benchmark in Octane 2, so it's clearly on
their radar. But as far as I've heard they haven't actually implemented
special asm.js typecheckers / AOT compilers like Mozilla has.

~~~
azakai
Not sure where you see "spec" mentioned in there?

As you say, Google included asm.js code in Octane 2, and you can see progress
on asm.js benchmarks as Google optimizes in ways that help that style of code
on arewefastyet,

[http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...](http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-
ubench)

This is also not something new, Google has optimized for asm.js code since the
IO keynote much earlier this year where Google reported a 2.4x speedup on an
aggregate asm.js benchmark,

[http://culturemass.com/2013/05/17/google-io-2013-keynote-
par...](http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/)

There are many ways to optimize for different types of code. Firefox uses the
asm.js type system for asm.js, and does AOT compilation, while Chrome chose a
different approach. The two approaches have different benefits. But both
browsers certainly optimize for asm.js, they both announced doing so and the
numbers are proof that they are succeeding.

edit: add link to Octane 2.0 and the asm.js benchmark added there,
[http://blog.chromium.org/2013/11/announcing-
octane-20.html](http://blog.chromium.org/2013/11/announcing-octane-20.html)

~~~
rictic
Even before asm.js there was emscripten (the primary generator of asm.js and
inspiration for much of the spec), which has been used for a number of high
profile demos and likely got optimization attention for years before asm.js.

~~~
cpeterso
I'm sure azakai is familiar with emscripten. ;)

~~~
girvo
This doesn't happen anywhere except on HN. I check parents profile before I
ever reply for this reason ;)

------
haberman
It's frustrating to see incorrect information regarding NaCl in top comments.

NaCl is not going to make the web x86-dependent. Recognizing the danger of an
architecture-specific web, Google has disabled NaCl for everything except the
Chrome Web Store. So unless you believe that the Apple App Store has been
making the web ARM-specific for the last five years, Native Client is not the
x86 lock-in that you may fear.

And in fact, Google now recommends PNaCl over NaCl for this very reason. It
recommends NaCl only in certain limited situations:
[https://developers.google.com/native-client/dev/nacl-and-
pna...](https://developers.google.com/native-client/dev/nacl-and-pnacl)

And even PNaCl, which requires browser support to run "normally", has a JS
fallback called pepper.js. So applications targeting PNaCl do not have a hard
dependency on a PNaCl runtime:
[http://trypepperjs.appspot.com/](http://trypepperjs.appspot.com/)

~~~
pcwalton
> Recognizing the danger of an architecture-specific web, Google has disabled
> NaCl for everything except the Chrome Web Store.

And plus.google.com. :(

~~~
haberman
Really? I hadn't heard that -- do you have a reference with more info?

~~~
dragonwriter
[http://news.ycombinator.com/item?id=6723956](http://news.ycombinator.com/item?id=6723956)

Basically, there is a whitelist of domains in Chrome where NaCl is enabled for
non-web-store apps; the basic criteria, according to Google, is that (like the
web store) these are places where Google has a lever to move people using NaCl
from NaCl to PNaCl over time.

Obviously, this applies to Google's own properties.

------
fidotron
This isn't right - the Chrome team have explicitly said they're going after
general optimizations that just happen to help asm.js performance greatly, but
are applied regardless of if asm.js is being used or not.

~~~
azakai
What you say is true, Chrome is using a general approach to optimize asm.js
code, but that does not contradict what the post says. It says that both
Firefox and Chrome have optimized for asm.js, and that's correct. For example
as reissbaker's comment mentions, Google even added an asm.js benchmark to
Octane 2.0. That shows it is optimizing for that style of code, among many
other styles of course.

~~~
nolok
That's one tortured and oriented way of looking at it. By your logic, every
single dev who has ever made a js lib can make an article titled "Chrome and
Opera Optimize for Whoever-Pioneered whatever.js", since the changes improve
their lib.

That title is making it sound like the changes were aimed at making that one
case faster, when they weren't.

And them adding a library to their benchmark doesn't in any way mean that they
aim to optimize for it, only that they want to keep a reference on how their
code perform. Just because I regularly check how my website renders in IE 6
doesn't mean I'm optimizing for it or that I consider it a target.

~~~
pfraze
I think there's probably a subtle distinction that's hard to show. I'd imagine
the line is drawn at interpreting the

    
    
       "use asm"; 
    

which signals the asm.js optimizations should be used. Instead, I'd bet the
Chrome team are just watching for JS which matches the asm.js spec and
optimizing for those cases, like they do for other code paths & structures.
That would mean they are optimizing for it, but not supporting it directly.

~~~
mraleph
> Instead, I'd bet the Chrome team are just watching for JS which matches the
> asm.js spec

No. All optimizations that V8 are doing are following from the JavaScript
specification itself, not from asm.js specification. V8 does not use asm.js
specification in any way (including type rules that asm.js prescribes). If you
take asm.js code and slightly change typing so that it will no longer pass
asm.js type check but still be reasonable V8 will continue to optimize what it
can.

------
kayoone
Please put down these Asm.js vs PNaCl arguments. We are all going to win in
the end as both ASM.JS and PNaCl run on pure Javascript (PNaCl through a
pepper.js fallback and ive heared asm.js is already a PNaCl target)[1]

In the end, some hugely popular cross compiled games will drive adoption of
both technologies to the point where they are ubiquitous and supported by all
major vendors. Apple doesnt want people saying "Wah look at how poorly Safari
handles that game compared to Chrome/Firefox".

[1] [http://games.greggman.com/game/thoughts-on-asm-js-vs-
pnacl/#...](http://games.greggman.com/game/thoughts-on-asm-js-vs-
pnacl/#comment-1140569220)

~~~
CmonDev
But it's better to pick the one that could potentially lead to JS being phased
out.

~~~
liviu
You are naive. If you don't understand JS, you can try something else that
compiles to JS. There are some cool tools for people like you!

~~~
CmonDev
Transpilers are just a work-around, tooling is not mainstream yet. At the
moment debugging the script is easier despite being unpleasant. I work with JS
almost daily and understand it's strengths and weaknesses. I do not consider
it a silver bullet which seems to be a shared sentiment around HN. A language
designed to make documents more interactive should be just that. Especially if
it is evolving in 5-year cycles
([http://en.wikipedia.org/wiki/ECMAScript#Versions](http://en.wikipedia.org/wiki/ECMAScript#Versions)).

~~~
stelonix
I believe you're missing the point: with asm.js, JS isn't being used as a
"silver bullet", but merely as a kind of "assembly" of web browsers. It's not
that we love JS so much, it's that it's pretty much part of every browser, and
as such code compiled for asm.js will run in any browser, albeit without any
asm.js specific speedup if a given browser does not support it.

~~~
CmonDev
Can I run CLR/JVM/Mono in asm.js today? Are there any clear plans for it? Will
performance of this scenario equal to that of NaCl? I have my hopes about
asm.js but it's good to see that there is an alternative that is evolving in
parallel.

~~~
stelonix
You could try compiling Mono/Java to asm.js and see for yourself. Of course
performance will not be equal to that of NaCl, but portability will.

I don't see NaCl as a viable alternative, I see it as an attempt of locking
down the user to a specific browser, and also as a potential security worry.

~~~
CmonDev
The thing is that NaCl lets e.g. game developers use languages and tools
_they_ like _today_ to generate great products that run with reasonable
performance and are deployable to a decent app-store, here is a poster child:
[http://www.tested.com/tech/web/3263-how-bastion-can-run-
in-a...](http://www.tested.com/tech/web/3263-how-bastion-can-run-in-a-web-
browser-with-googles-native-client)

~~~
stelonix
You can do the same with Emscripten + asm.js. You don't code in Javascript,
you just compile to JS. The products will run with less performance than
native, I'm sure, but at least they're not dependent on Google's app store.

And, for me personally if I'm going to run a native app, I see no reason at
all to have it run inside a web browser.

------
ouggnay
Is there any concrete data to support "You still get the best performance in
Firefox"? I get around 26fps for 1920x1200 fullscreen on the latest Firefox
nightly, but 40fps on the latest Chromium. Ubuntu precise.

~~~
JohnTHaller
Comparing a pre-alpha quality nightly build is never a good way to compare
real products.

Comparing the current stable Chrome 31.0.1650.57 and Firefox 25.0.1 on my
Windows box running at 1920x1200 yields 57.8 fps for Chrome and 81.7 fps for
Firefox. Note that Firefox is pegged at a maximum of 60fps by default which
will affect benchmarks. You can disable that limit with the information in the
FAQ.

------
nashashmi
Does this officially open the possibility of running Mozilla Firefox on a
Chromebook (ChromeOS)?

~~~
JohnTHaller
Nope. That will likely never be permitted.

------
bla2
Mozilla seems pretty desperate for asjm.js press :-/

