15 ms·

Mozilla can produce near-native performance on the Web

335 points by BruceM 13y ago

melling 13y ago
What do developers want for a development environment these days? Is C/C++ the next wave of web development? Tooling is a lot better than when I did it 15 years ago. Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js).
- fhd2 13y ago
  > Is C/C++ the next wave of web development? asm.js is certainly not targeted at writing web applications in C or C++. It's more about supporting arbitrary languages and getting existing native code bases (e.g. libraries and game engines) on the web. There's some more background in this presentation: http://kripken.github.io/mloc_emscripten_talk/ http://kripken.github.io/mloc_emscripten_talk/ (That said, based on anecdotal evidence, C++ seems to work pretty well on large projects where predictability and reliability matter. So for really large, complex web apps, C++ might become a popular choice. Not really seeing this happen though, as web applications generally handle the hard stuff in the backend.) > Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js). It probably doesn't have to most of the time. Hardly anything in the web applications I've worked on was ever CPU-bound, the network is usually the big bottleneck. We're just scripting the browser after all, most of the hard stuff (rendering, storage engines etc.), is already taken care of by native code.
cliffbean 13y ago
The fascinating thing about this is that they didn't write a new JIT for asm.js. It's just their existing JIT with more information and a few new tricks. Among other things, this means that it doesn't yet have a lot of the fancy optimizations that C/C++ compilers typically have in their backends, like clever instruction selection or register allocation. It's already impressively fast, and it has the potential to get even faster.
- ndesaulniers 13y ago
  > It's just their existing JIT with more information and a few new tricks. Spidermonkey is composed of the Baseline Compiler (JIT) and Ion Monkey (JIT), but a new AOT compiler was written, called "Odin Monkey."
  - azakai 13y ago
    Not really a new compiler. OdinMonkey parses the asm.js type system, but then just passes the information it learned into IonMonkey, the existing SSA-optimizing JIT.
    - ndesaulniers 13y ago
      Had to read up on that one! http://en.wikipedia.org/wiki/Static_single_assignment_form http://en.wikipedia.org/wiki/Static_single_assignment_form
  - cliffbean 13y ago
    OdinMonkey uses the existing IonMonkey compiler to do the actual optimization and code generation work. This blog post has more information [0]; see especially the comments section where the author responds to some questions and discusses the relationship between OdinMonkey and regular JS compilation. [0] https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/ https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n...
    - ndesaulniers 13y ago
      oh, interesting! Good eye, thanks for pointing this out!
leoc 13y ago
> It's a limited, stripped down subset of JavaScript that It's a limited, stripped down subset of JavaScript that the company claims will offer performance that's within a factor of two of native—good enough to use the browser for almost any application. Except for running webpages scripted with Dart. It's not fast enough for that application apparently. https://news.ycombinator.com/item?id=3095519 https://news.ycombinator.com/item?id=3095519
- BrendanEich 13y ago
  Who knows how fast Emscripten+asm.js-compiled DartVM would be compared to Dart2JS in 2013? I don't know yet, and apparently neither do you. JITs can be tricky, but @azakai is having good results with Emscripten+asm.js'ed LuaJIT2. What I wrote 593+ days ago was about the Dash memo's Microsoft-like strategy. My point then was not that it couldn't ever be defeated by something like our work on asm.js and Emscripten. Never say never. My point rather was that the Dash strategy intentionally used Google's big resources to push a gratuitously non-standards-based agenda at the expense of its Web-standards-based efforts. Indeed, since then it has become clear that Google miscalculated. Dart even gave up bignums (the int type) to support Dart2JS/DartVM equivalence, which I think is a mistake. Bignums are actually on the JS standards-based agenda: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:value_objects http://wiki.ecmascript.org/doku.php?id=strawman:value_object... See also https://bugzilla.mozilla.org/show_bug.cgi?id=749786 https://bugzilla.mozilla.org/show_bug.cgi?id=749786 Given all the time that has passed since 2010, Google champions in Ecma TC39 could easily have worked bignums into ES7 if not ES6. At a higher level, by over-investing in Dart and under-investing in JS (the V8 team was moved from Aarhus to Munich and with the no-remoties rule had to be rebuilt), Google has missed opportunities such as game-industry work we announced at GDC with Epic. This is "ok", it's their choice, but I still say that it is inherently much more fragmenting than any optimization of the asm.js kind, and that it under-serves the standards-based Web. Maybe in a few years we can evolve JS to incorporate whatever helps DartVM beat Dart2JS, if there's any gap left. However, the idea that mutable global objects in JS necessarily mean VM-snapshotting is impossible is simply false. On the other hand, do we really need VM snapshots to speed up gmail startup? LOL! /be
ux-app 13y ago
For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which presumably exist in isolation from other components thereby reducing the penalties of dynamic CSS.
- ihsw 13y ago
  > What makes web apps feel like swimming through molasses is the DOM. I would contend that network latency and the plethora of domains queried to be a greater impediment to a speedy web. DOM manipulation may be absurdly slow however it cannot hold a candle to latency hold-ups. Most readers on HN live in a quiet and peaceful bubble of high-quality network connections, but the majority of the world is beginning to wake up to the web and they'll have to endure latency issues that we haven't experienced since "broadband" was a new concept.
  - carbocation 13y ago
    Quite a few HNers have probably experienced lossy connections such as Amtrak or busy coffee shops. I would think that those high-loss situations would feel somewhat like a high latency experience.
    - wslh 13y ago
      Lossy mobile connections are very common in the world.
  - derleth 13y ago
    But we do know how to handle bad latency, don't we? Speculative loading, which got a bad name because it makes wallhacks on FPSes work but really has almost no downside once the client can't do anything malicious with a little information the human isn't using yet. If the real problem isn't latency but bandwidth or bandwidth caps, that will require other solutions.
zobzu 13y ago
tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native. Also its slightly slower (a few %) than regular JS on browsers without asm.js support.
- Arelius 13y ago
  > its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?
  - deleted 13y ago
    [deleted]
    - btilly 13y ago
      Grandparent may be saying that, but that's not true. The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those. Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed the browser. Human written code would not have those problems.
      - hollerith 13y ago
        Thanks for pointing out my error. (Hope you don't mind that I deleted my comment.)
        btilly 13y ago
        Usually in a case like that I'd edit it to add an update admitting the correction. The rest of what you said was quite useful for people who didn't want to read a long article.
  - kibibu 13y ago
    Check this out (from the asm.js spec) function add1(x) { x = x|0; // x : int return (x+1)|0; } This declares x to be an int in asm.js, which allows a bunch of optimizations. In a non-asm.js engine, it is an extra 2 operations. It's not difficult to believe that a non-asm.js engine would be slower with the type annotations than without, although I don't have any performance numbers to check.
mosqutip 13y ago
It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain. Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this effort, since Google clearly hasn't with Dart.
- callahad 13y ago
  As far as I know, asm.js is a strict subset of JavaScript -- I don't believe it's "browser-specific" in a meaningful way. Rather, it shows that it's possible to take a subset of JavaScript and make it run at near-native speeds, which means that there's still a lot of room left for the VMs to improve. From glancing at the benchmarks in the Ars article, it looks like asm.js generally runs around twice to four times as fast as the same code without asm.js-specific optimizations. This is a huge improvement, but it's not the difference between something being blazing fast in one browser and unusably slow in another.
  - ajuc 13y ago
    In some applications it doesn't matter, in some it's crucial. If your game runs at 60 fps in firefox and 15 fps in other browsers, it's effectively firefox-only game. Additionaly browser games can't have main game loop (cause it would hang the browser infinitely), but often use "requestAnimationFrame" to trigger updates with the best sustained refresh rate available. Even if only one frame out of every 10 in your game is taking 20 ms instead of 16 ms - your game won't run with 60 fps anymore, but with 45 fps or 30 fps because browser is trying to choose refresh rate that will work. And that's a big difference in experience.
- Skalman 13y ago
  There a bug for V8 about implementing asm.js: http://code.google.com/p/v8/issues/detail?id=2599 http://code.google.com/p/v8/issues/detail?id=2599
- timothya 13y ago
danbruc 13y ago
I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant. Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.
- callahad 13y ago
  I don't understand this stuff well enough, but doesn't Emscripten effectively give you that? It converts LLVM bitcode into JavaScript, so if you can compile it with LLVM, you can use it on the web.
  - axaxs 13y ago
    But that's like converting C into python. Why not begin a new/existing language that can be compiled and ran at native speeds?
    - mortehu 13y ago
      Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.
      - Yoric 13y ago
        They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
        ihnorton 13y ago
        > - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
npalli 13y ago
BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstechnica.net/wp-content/uploads/2013/05/classic-native-v-optimized-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
- azakai 13y ago
  Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone. Is the job done? No, as you say, SIMD and threads are important. But we had to first get single-threaded performance to the right area. Next, browser vendors need to work together to standardize stuff that will allow SIMD and more threading. This is definitely possible if everyone is interested in making the web faster, which I certainly believe is the case.
  - npalli 13y ago
    Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
    - azakai 13y ago
      No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example, http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 asm.js code makes it easier to get within reach of native performance.
namuol 13y ago
Finally, I can write all my web apps in C/C++. Dream come true!
- iso8859-1 13y ago
  Well, there still is no interface to the DOM. So it really depends on your definition of "web app". It is quite comparable to applets IMHO. Except applets are less of a hack. I wish Sun had invested more time in their "sandbox".
jackmaney 13y ago
Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.
- ricardobeat 13y ago
  Is your FF up to date? Since around v20 it feels way snappier than Chrome, at least on OSX.
  - jackmaney 13y ago
    I switched to Chrome right around Firefox v3.6. I've tried it a few times since, but I don't remember which version Firefox was at at the time.
- zw 13y ago
  Exactly. I don't know how I'm supposed to trust them "making the web faster" when I can't scroll up and down a page.
  - gkanai 13y ago
    You may have an addon that is leaking memory or your profile may be corrupted. Consider restarting without any Addons or try the Reset feature to start with a new profile but with your key user data migrated. https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...
    - pekk 13y ago
      My profile is apparently constantly being corrupted. If I have to wipe Firefox's data on me every other day because of profile corruption then what is the point? If addons are guaranteed to mess things up then why does Firefox have that feature? Let's be honest, this isn't meant to be helpful, it's just meant to shift blame back to the user.
ilaksh 13y ago
I really disagree with the idea of ASM.js. I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript. That is not true. JavaScript code is usually compiled to native code now and is very fast -- generally much faster than Ruby and Python. I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines -- for example Safari especially stands out with their deliberately crippled performance, and Microsoft with their deliberately crippled featureset. The great thing about the web is convenient APIs like WebGL and nice languages like CoffeeScript. ASM.js negates that for no good reason. There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet, and within a couple of years ordinary hardware will go much faster anyway.
- omaranto 13y ago
  What do you dislike about the idea of asm.js? (You mention that some people think asm.js is evidence that you can't make things fast enough in regular JavaScript, but that is something you dislike about people's reactions to asm.js, not an issue with the idea of asm.js.)
  - ilaksh 13y ago
    It promotes that idea. Also, asm.js negates the advantages of the nice web APIs and type-free programming languages etc. Read what I wrote.
    - prodigal_erik 13y ago
      Being able to use any language is better than having to use one language littered with WTF pitfalls because one guy had to hack it together in a week. And the debate about type checking and static analysis is far from settled.
- fhd2 13y ago
  > I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript I don't think you can blame asm.js for this. It's not targeted at web developers and regular JS is by all means fast enough for web applications in general. But some high performance applications like games and language runtimes are running into performance bottlenecks with plain JS, and there are large legacy code bases that are too expensive to port. It's not meant to hurt JavaScript at all, quite the contrary. It's an alternative to actually running native code on the browser, like NaCL. asm.js applications can in fact gradually migrate to JS. > I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines I don't see how this is related, asm.js applications benefit from better WebGL support all the same. It's still JS running in the browser, it doesn't have direct access to any low level APIs. > There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet I think you can build pretty neat web-based games even with plain JS, thanks to WebGL. Probably not with really high-end graphics or physics, but good enough. However, are you expecting game companies to rewrite their engines in JS just to get into the browser, not even knowing if it'll pay off for them? With asm.js, it's just another platform supporting C++ they can port to (C++ is ubiquitous in the industry). Mozilla and Epic are already working on porting Unreal Engine (Mass Effect and tons of others) to the web. If browser games turn out to be the future, I'm sure we'll get engines focusing just on browser games, gradually rewriting large parts of their engines in JS. At the same time, we'll see better support for web-based games in consoles and on mobile devices.
NinjaWarrior 13y ago
> Emscripten builds taking between 10 and 50 times longer to compile than the native code ones. Hey, this is fatal. With this massively long iteration time, you can't run actual big projects. Only executing 1,000,000 lines of C++ code is not enough. We care the build time as well as the perforamnce. BTW, have you heard that the next Haswell processors can get only 5% performance improvement? We should assume that we have no free lunch anymore. One of the UNIX philosophies is already broken.
- boyter 13y ago
  I thought the Haswell CPU was more about reducing power usage then adding performance? I'd be curious to know how much effort was spent on the power consumption vs performance.
- mratzloff 13y ago
  Intel is getting their lunch handed to them by ARM. People value power consumption over performance these days, so why would they continue pumping out faster chips?
- berkut 13y ago
  > BTW, have you heard that the next Haswell processors can get only 5% performance improvement? Bollocks - using the new gather AVX instructions, I've seen close to a 40% increase over IB on some floating-point code I've hand-written with intrinsics. Existing C++ code is around 13-16% faster thanks to better cache bandwidth and a huge L4 cache. Turn on FMA (fused multiply–add) optimisation and that goes to ~20% faster.
mratzloff 13y ago
I think it's becoming clear that there is room for two classes of web language: one for general use (JavaScript) and one for high performance applications or games. Let's get a real language alternative, free of half measures or compromises.
- azakai 13y ago
  All languages and VMs are compromises: JavaScript, JVM, CLR, LLVM, Flash, etc. Question is which compromise you prefer.
eblade 13y ago
It seemed that the general idea of web being slow is so polarizing that each and everyone of us can't even pinpoint where the problem is. I suspect the problem is a multidimensional one.
hrktb 13y ago
It feels the most interesting use of asm would be to bring existing C code into javascript and have it run at reasonable speeds. Things like small (or not) database engines, authentication or encryption libraries, data parsing utilities etc...
mekpro 13y ago
It would be interesting to see an implementation of this on ARM platform. Firefox OS powered mobile device would be really promising with this optimization.
- fzzzy 13y ago
  asm.js is already enabled on Firefox for Android nightly builds. We hope to have asm.js enabled in Firefox OS by the 1.2 timeframe (middle/end of 2013)
p0nce 13y ago
No it can't. C is not the speed limit. Top native performance is achieved by an ungodly combination of SIMD intrinsics, compiler-assisted optimization, cache-aware data-structures and assembly.
grn 13y ago
I wonder how the Internet would have looked like if it had developed the way that Alan Kay proposed (i.e. a browser as a mini-operating system). It's quite possible that we'd have much better performance (among other things) from the start.
ksk 13y ago
Why dont they just insert regular C/C++ source code inside HTML and be done with it? Eventually the browser is just going to be a download manager that downloads executable code and runs it locally :P
- iso8859-1 13y ago
  Emscripten can't compile LLVM yet, so you can't put the compiler in a web page. And considering that a PDF reader is couple of megabytes of JavaScript, LLVM would be probably be tens of megabytes.
solomatov 13y ago
Near native performance is a very good thing especially in the fields such as game development. However, it's a pity that Mozilla doesn't address the main problem with the web platform, the lack of good platform and the set of API, something like Java or .NET provides. There are a large number of good javascript applications (Google docs, GMail, etc), which are produced by heroic efforts of the teams who created them. The same effort could have been expended on hundreds more useful software, if JavaScript was replaced by something more adequate.
- BrendanEich 13y ago
  Look around you at the Web: all the top sites use JS heavily and without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). If the old big-OO-frameworks really conferred such huge fitness advantages over JS, you would not see them dead on the client. They would have been used, and their plugins would have been supported better by the plugin vendors. JS these days has a lot going for it, including IntelliJ-style IDEs (Cloud 9 offers one) and not-too-OO-or-huge frameworks. /be
  - solomatov 13y ago
    >Look around you at the Web: all the top sites use JS heavily and without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). Java isn't used in the browser because of awfully bad user experience, and bad security (personally, I disabled Java in the browser). JavaScript applications just look much better and behave much more smoothly, which is more important on the web than ease of development and performance. Web applications are much more readily used than desktop applications, and that's why we have to use them. It's just economic incentive. If we create a desktop application, user base which we sell too will be much smaller if the same application will be provided on the web. I'd love to use technologies, which make me more productive than JavaScript like JavaFX and Silverlight, or at least Flash. However, there's a large percentage of users whose browsers don't support them and if they support them they provide inferior user experience. I (and many other people) use JavaScript not because it's great but because it's the only platform which is universally supported by browsers not and provides superior user experience. It's the only reason to use it. > without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). Most of the top sites are quite trivial in code complexity. They are more complex design and ui-experience wise than codewise. There are, of course complex web applications, like google docs, cloud9, gmail, google reader, but they were created with definitely heroic efforts, and they don't reach the complexity of the top desktop applications. Where's web based Mathematica, 3DS Max, Autocad, IntelliJ? When web based office applications will have performance of MS Office? As an indicator of how complex these web applications are, you can take a look at how many web frameworks have non trivial collections, like HashSets, HashMaps, TreeMaps etc. Only the following frameworks support them: closure tools, GWT, Dart. Most of the popular JS frameworks which are used by top sites don't use them. >JS these days has a lot going for it, including IntelliJ-style IDEs (Cloud 9 offers one) and not-too-OO-or-huge frameworks. I actually work at JetBrains (the creator of IntelliJ), and I can say that Cloud9 provides IDE experience from 90s. The only meaningful feature that it supports is code completion and error highlighting. It has no refactorings, find usages, and many other smart features. I think, the JavaScript is to blame, and I feel that so complex code is near impossible to write in a language such as JavaScript (because of its lack of static type system).

335 points by BruceM 13y ago

What do developers want for a development environment these days? Is C/C++ the next wave of web development? Tooling is a lot better than when I did it 15 years ago. Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js).

fhd2 13y ago
> Is C/C++ the next wave of web development? asm.js is certainly not targeted at writing web applications in C or C++. It's more about supporting arbitrary languages and getting existing native code bases (e.g. libraries and game engines) on the web. There's some more background in this presentation: http://kripken.github.io/mloc_emscripten_talk/ http://kripken.github.io/mloc_emscripten_talk/ (That said, based on anecdotal evidence, C++ seems to work pretty well on large projects where predictability and reliability matter. So for really large, complex web apps, C++ might become a popular choice. Not really seeing this happen though, as web applications generally handle the hard stuff in the backend.) > Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js). It probably doesn't have to most of the time. Hardly anything in the web applications I've worked on was ever CPU-bound, the network is usually the big bottleneck. We're just scripting the browser after all, most of the hard stuff (rendering, storage engines etc.), is already taken care of by native code.

cliffbean 13y ago

The fascinating thing about this is that they didn't write a new JIT for asm.js. It's just their existing JIT with more information and a few new tricks. Among other things, this means that it doesn't yet have a lot of the fancy optimizations that C/C++ compilers typically have in their backends, like clever instruction selection or register allocation. It's already impressively fast, and it has the potential to get even faster.

ndesaulniers 13y ago
> It's just their existing JIT with more information and a few new tricks. Spidermonkey is composed of the Baseline Compiler (JIT) and Ion Monkey (JIT), but a new AOT compiler was written, called "Odin Monkey."
- azakai 13y ago
  Not really a new compiler. OdinMonkey parses the asm.js type system, but then just passes the information it learned into IonMonkey, the existing SSA-optimizing JIT.
  - ndesaulniers 13y ago
    Had to read up on that one! http://en.wikipedia.org/wiki/Static_single_assignment_form http://en.wikipedia.org/wiki/Static_single_assignment_form
- cliffbean 13y ago
  OdinMonkey uses the existing IonMonkey compiler to do the actual optimization and code generation work. This blog post has more information [0]; see especially the comments section where the author responds to some questions and discusses the relationship between OdinMonkey and regular JS compilation. [0] https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/ https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n...
  - ndesaulniers 13y ago
    oh, interesting! Good eye, thanks for pointing this out!

leoc 13y ago

> It's a limited, stripped down subset of JavaScript that It's a limited, stripped down subset of JavaScript that the company claims will offer performance that's within a factor of two of native—good enough to use the browser for almost any application. Except for running webpages scripted with Dart. It's not fast enough for that application apparently. https://news.ycombinator.com/item?id=3095519 https://news.ycombinator.com/item?id=3095519

BrendanEich 13y ago
Who knows how fast Emscripten+asm.js-compiled DartVM would be compared to Dart2JS in 2013? I don't know yet, and apparently neither do you. JITs can be tricky, but @azakai is having good results with Emscripten+asm.js'ed LuaJIT2. What I wrote 593+ days ago was about the Dash memo's Microsoft-like strategy. My point then was not that it couldn't ever be defeated by something like our work on asm.js and Emscripten. Never say never. My point rather was that the Dash strategy intentionally used Google's big resources to push a gratuitously non-standards-based agenda at the expense of its Web-standards-based efforts. Indeed, since then it has become clear that Google miscalculated. Dart even gave up bignums (the int type) to support Dart2JS/DartVM equivalence, which I think is a mistake. Bignums are actually on the JS standards-based agenda: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:value_objects http://wiki.ecmascript.org/doku.php?id=strawman:value_object... See also https://bugzilla.mozilla.org/show_bug.cgi?id=749786 https://bugzilla.mozilla.org/show_bug.cgi?id=749786 Given all the time that has passed since 2010, Google champions in Ecma TC39 could easily have worked bignums into ES7 if not ES6. At a higher level, by over-investing in Dart and under-investing in JS (the V8 team was moved from Aarhus to Munich and with the no-remoties rule had to be rebuilt), Google has missed opportunities such as game-industry work we announced at GDC with Epic. This is "ok", it's their choice, but I still say that it is inherently much more fragmenting than any optimization of the asm.js kind, and that it under-serves the standards-based Web. Maybe in a few years we can evolve JS to incorporate whatever helps DartVM beat Dart2JS, if there's any gap left. However, the idea that mutable global objects in JS necessarily mean VM-snapshotting is impossible is simply false. On the other hand, do we really need VM snapshots to speed up gmail startup? LOL! /be

ux-app 13y ago

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which presumably exist in isolation from other components thereby reducing the penalties of dynamic CSS.

ihsw 13y ago
> What makes web apps feel like swimming through molasses is the DOM. I would contend that network latency and the plethora of domains queried to be a greater impediment to a speedy web. DOM manipulation may be absurdly slow however it cannot hold a candle to latency hold-ups. Most readers on HN live in a quiet and peaceful bubble of high-quality network connections, but the majority of the world is beginning to wake up to the web and they'll have to endure latency issues that we haven't experienced since "broadband" was a new concept.
- carbocation 13y ago
  Quite a few HNers have probably experienced lossy connections such as Amtrak or busy coffee shops. I would think that those high-loss situations would feel somewhat like a high latency experience.
  - wslh 13y ago
    Lossy mobile connections are very common in the world.
- derleth 13y ago
  But we do know how to handle bad latency, don't we? Speculative loading, which got a bad name because it makes wallhacks on FPSes work but really has almost no downside once the client can't do anything malicious with a little information the human isn't using yet. If the real problem isn't latency but bandwidth or bandwidth caps, that will require other solutions.

zobzu 13y ago

tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native. Also its slightly slower (a few %) than regular JS on browsers without asm.js support.

Arelius 13y ago
> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?
- deleted 13y ago
  [deleted]
  - btilly 13y ago
    Grandparent may be saying that, but that's not true. The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those. Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed the browser. Human written code would not have those problems.
    - hollerith 13y ago
      Thanks for pointing out my error. (Hope you don't mind that I deleted my comment.)
      - btilly 13y ago
        Usually in a case like that I'd edit it to add an update admitting the correction. The rest of what you said was quite useful for people who didn't want to read a long article.
- kibibu 13y ago
  Check this out (from the asm.js spec) function add1(x) { x = x|0; // x : int return (x+1)|0; } This declares x to be an int in asm.js, which allows a bunch of optimizations. In a non-asm.js engine, it is an extra 2 operations. It's not difficult to believe that a non-asm.js engine would be slower with the type annotations than without, although I don't have any performance numbers to check.

mosqutip 13y ago

It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain. Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this effort, since Google clearly hasn't with Dart.

callahad 13y ago
As far as I know, asm.js is a strict subset of JavaScript -- I don't believe it's "browser-specific" in a meaningful way. Rather, it shows that it's possible to take a subset of JavaScript and make it run at near-native speeds, which means that there's still a lot of room left for the VMs to improve. From glancing at the benchmarks in the Ars article, it looks like asm.js generally runs around twice to four times as fast as the same code without asm.js-specific optimizations. This is a huge improvement, but it's not the difference between something being blazing fast in one browser and unusably slow in another.
- ajuc 13y ago
  In some applications it doesn't matter, in some it's crucial. If your game runs at 60 fps in firefox and 15 fps in other browsers, it's effectively firefox-only game. Additionaly browser games can't have main game loop (cause it would hang the browser infinitely), but often use "requestAnimationFrame" to trigger updates with the best sustained refresh rate available. Even if only one frame out of every 10 in your game is taking 20 ms instead of 16 ms - your game won't run with 60 fps anymore, but with 45 fps or 30 fps because browser is trying to choose refresh rate that will work. And that's a big difference in experience.
Skalman 13y ago
There a bug for V8 about implementing asm.js: http://code.google.com/p/v8/issues/detail?id=2599 http://code.google.com/p/v8/issues/detail?id=2599
timothya 13y ago

danbruc 13y ago

I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant. Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.

callahad 13y ago
I don't understand this stuff well enough, but doesn't Emscripten effectively give you that? It converts LLVM bitcode into JavaScript, so if you can compile it with LLVM, you can use it on the web.
- axaxs 13y ago
  But that's like converting C into python. Why not begin a new/existing language that can be compiled and ran at native speeds?
  - mortehu 13y ago
    Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.
    - Yoric 13y ago
      They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
      - ihnorton 13y ago
        > - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...

npalli 13y ago

BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstechnica.net/wp-content/uploads/2013/05/classic-native-v-optimized-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...

azakai 13y ago
Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone. Is the job done? No, as you say, SIMD and threads are important. But we had to first get single-threaded performance to the right area. Next, browser vendors need to work together to standardize stuff that will allow SIMD and more threading. This is definitely possible if everyone is interested in making the web faster, which I certainly believe is the case.
- npalli 13y ago
  Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
  - azakai 13y ago
    No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example, http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 asm.js code makes it easier to get within reach of native performance.

namuol 13y ago

Finally, I can write all my web apps in C/C++. Dream come true!

iso8859-1 13y ago
Well, there still is no interface to the DOM. So it really depends on your definition of "web app". It is quite comparable to applets IMHO. Except applets are less of a hack. I wish Sun had invested more time in their "sandbox".

jackmaney 13y ago

Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.

ricardobeat 13y ago
Is your FF up to date? Since around v20 it feels way snappier than Chrome, at least on OSX.
- jackmaney 13y ago
  I switched to Chrome right around Firefox v3.6. I've tried it a few times since, but I don't remember which version Firefox was at at the time.
zw 13y ago
Exactly. I don't know how I'm supposed to trust them "making the web faster" when I can't scroll up and down a page.
- gkanai 13y ago
  You may have an addon that is leaking memory or your profile may be corrupted. Consider restarting without any Addons or try the Reset feature to start with a new profile but with your key user data migrated. https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...
  - pekk 13y ago
    My profile is apparently constantly being corrupted. If I have to wipe Firefox's data on me every other day because of profile corruption then what is the point? If addons are guaranteed to mess things up then why does Firefox have that feature? Let's be honest, this isn't meant to be helpful, it's just meant to shift blame back to the user.

ilaksh 13y ago

I really disagree with the idea of ASM.js. I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript. That is not true. JavaScript code is usually compiled to native code now and is very fast -- generally much faster than Ruby and Python. I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines -- for example Safari especially stands out with their deliberately crippled performance, and Microsoft with their deliberately crippled featureset. The great thing about the web is convenient APIs like WebGL and nice languages like CoffeeScript. ASM.js negates that for no good reason. There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet, and within a couple of years ordinary hardware will go much faster anyway.

omaranto 13y ago
What do you dislike about the idea of asm.js? (You mention that some people think asm.js is evidence that you can't make things fast enough in regular JavaScript, but that is something you dislike about people's reactions to asm.js, not an issue with the idea of asm.js.)
- ilaksh 13y ago
  It promotes that idea. Also, asm.js negates the advantages of the nice web APIs and type-free programming languages etc. Read what I wrote.
  - prodigal_erik 13y ago
    Being able to use any language is better than having to use one language littered with WTF pitfalls because one guy had to hack it together in a week. And the debate about type checking and static analysis is far from settled.
fhd2 13y ago
> I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript I don't think you can blame asm.js for this. It's not targeted at web developers and regular JS is by all means fast enough for web applications in general. But some high performance applications like games and language runtimes are running into performance bottlenecks with plain JS, and there are large legacy code bases that are too expensive to port. It's not meant to hurt JavaScript at all, quite the contrary. It's an alternative to actually running native code on the browser, like NaCL. asm.js applications can in fact gradually migrate to JS. > I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines I don't see how this is related, asm.js applications benefit from better WebGL support all the same. It's still JS running in the browser, it doesn't have direct access to any low level APIs. > There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet I think you can build pretty neat web-based games even with plain JS, thanks to WebGL. Probably not with really high-end graphics or physics, but good enough. However, are you expecting game companies to rewrite their engines in JS just to get into the browser, not even knowing if it'll pay off for them? With asm.js, it's just another platform supporting C++ they can port to (C++ is ubiquitous in the industry). Mozilla and Epic are already working on porting Unreal Engine (Mass Effect and tons of others) to the web. If browser games turn out to be the future, I'm sure we'll get engines focusing just on browser games, gradually rewriting large parts of their engines in JS. At the same time, we'll see better support for web-based games in consoles and on mobile devices.

NinjaWarrior 13y ago

> Emscripten builds taking between 10 and 50 times longer to compile than the native code ones. Hey, this is fatal. With this massively long iteration time, you can't run actual big projects. Only executing 1,000,000 lines of C++ code is not enough. We care the build time as well as the perforamnce. BTW, have you heard that the next Haswell processors can get only 5% performance improvement? We should assume that we have no free lunch anymore. One of the UNIX philosophies is already broken.

boyter 13y ago
I thought the Haswell CPU was more about reducing power usage then adding performance? I'd be curious to know how much effort was spent on the power consumption vs performance.
mratzloff 13y ago
Intel is getting their lunch handed to them by ARM. People value power consumption over performance these days, so why would they continue pumping out faster chips?
berkut 13y ago
> BTW, have you heard that the next Haswell processors can get only 5% performance improvement? Bollocks - using the new gather AVX instructions, I've seen close to a 40% increase over IB on some floating-point code I've hand-written with intrinsics. Existing C++ code is around 13-16% faster thanks to better cache bandwidth and a huge L4 cache. Turn on FMA (fused multiply–add) optimisation and that goes to ~20% faster.

mratzloff 13y ago

I think it's becoming clear that there is room for two classes of web language: one for general use (JavaScript) and one for high performance applications or games. Let's get a real language alternative, free of half measures or compromises.

azakai 13y ago
All languages and VMs are compromises: JavaScript, JVM, CLR, LLVM, Flash, etc. Question is which compromise you prefer.

eblade 13y ago

It seemed that the general idea of web being slow is so polarizing that each and everyone of us can't even pinpoint where the problem is. I suspect the problem is a multidimensional one.

hrktb 13y ago

It feels the most interesting use of asm would be to bring existing C code into javascript and have it run at reasonable speeds. Things like small (or not) database engines, authentication or encryption libraries, data parsing utilities etc...

mekpro 13y ago

It would be interesting to see an implementation of this on ARM platform. Firefox OS powered mobile device would be really promising with this optimization.

fzzzy 13y ago
asm.js is already enabled on Firefox for Android nightly builds. We hope to have asm.js enabled in Firefox OS by the 1.2 timeframe (middle/end of 2013)

p0nce 13y ago

No it can't. C is not the speed limit. Top native performance is achieved by an ungodly combination of SIMD intrinsics, compiler-assisted optimization, cache-aware data-structures and assembly.

grn 13y ago

I wonder how the Internet would have looked like if it had developed the way that Alan Kay proposed (i.e. a browser as a mini-operating system). It's quite possible that we'd have much better performance (among other things) from the start.

ksk 13y ago

Why dont they just insert regular C/C++ source code inside HTML and be done with it? Eventually the browser is just going to be a download manager that downloads executable code and runs it locally :P

iso8859-1 13y ago
Emscripten can't compile LLVM yet, so you can't put the compiler in a web page. And considering that a PDF reader is couple of megabytes of JavaScript, LLVM would be probably be tens of megabytes.

solomatov 13y ago

Near native performance is a very good thing especially in the fields such as game development. However, it's a pity that Mozilla doesn't address the main problem with the web platform, the lack of good platform and the set of API, something like Java or .NET provides. There are a large number of good javascript applications (Google docs, GMail, etc), which are produced by heroic efforts of the teams who created them. The same effort could have been expended on hundreds more useful software, if JavaScript was replaced by something more adequate.

BrendanEich 13y ago
Look around you at the Web: all the top sites use JS heavily and without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). If the old big-OO-frameworks really conferred such huge fitness advantages over JS, you would not see them dead on the client. They would have been used, and their plugins would have been supported better by the plugin vendors. JS these days has a lot going for it, including IntelliJ-style IDEs (Cloud 9 offers one) and not-too-OO-or-huge frameworks. /be
- solomatov 13y ago
  >Look around you at the Web: all the top sites use JS heavily and without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). Java isn't used in the browser because of awfully bad user experience, and bad security (personally, I disabled Java in the browser). JavaScript applications just look much better and behave much more smoothly, which is more important on the web than ease of development and performance. Web applications are much more readily used than desktop applications, and that's why we have to use them. It's just economic incentive. If we create a desktop application, user base which we sell too will be much smaller if the same application will be provided on the web. I'd love to use technologies, which make me more productive than JavaScript like JavaFX and Silverlight, or at least Flash. However, there's a large percentage of users whose browsers don't support them and if they support them they provide inferior user experience. I (and many other people) use JavaScript not because it's great but because it's the only platform which is universally supported by browsers not and provides superior user experience. It's the only reason to use it. > without "heroic efforts" compared to Java (dead on the client) or .NET (WPF is dead too). Most of the top sites are quite trivial in code complexity. They are more complex design and ui-experience wise than codewise. There are, of course complex web applications, like google docs, cloud9, gmail, google reader, but they were created with definitely heroic efforts, and they don't reach the complexity of the top desktop applications. Where's web based Mathematica, 3DS Max, Autocad, IntelliJ? When web based office applications will have performance of MS Office? As an indicator of how complex these web applications are, you can take a look at how many web frameworks have non trivial collections, like HashSets, HashMaps, TreeMaps etc. Only the following frameworks support them: closure tools, GWT, Dart. Most of the popular JS frameworks which are used by top sites don't use them. >JS these days has a lot going for it, including IntelliJ-style IDEs (Cloud 9 offers one) and not-too-OO-or-huge frameworks. I actually work at JetBrains (the creator of IntelliJ), and I can say that Cloud9 provides IDE experience from 90s. The only meaningful feature that it supports is code completion and error highlighting. It has no refactorings, find usages, and many other smart features. I think, the JavaScript is to blame, and I feel that so complex code is near impossible to write in a language such as JavaScript (because of its lack of static type system).