Mozilla can produce near-native performance on the Web

http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/

by BruceM • 13 years ago

335 197 13 years ago

arstechnica.com

cliffbean2• 13 years 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.

ndesaulniers3• 13 years 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."

azakai10• 13 years 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.

cliffbean2• 13 years 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-n...

leoc• 13 years 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

BrendanEich15• 13 years 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:value_object...

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

solomatov8• 13 years ago

What about PNaCl? What's the reason you don't support it in Mozilla? It's based on open source tools, and can be easily integrated into any browser.

P.P.S. IMO, the biggest problem about JavaScript isn't its performance. Performance is ok, and enough for the games, thanks to WebGL. The language, like many other dynamic languages, is just not very suitable for large scale development. People who write such applications, have to resort to using tools like GWT, which add substantial overhead (both in compilation time and performance). Does Mozilla has any plans to improve the situation here?

mraleph• 13 years ago

You can't simply asm.js'fy LuaJIT2 because it has an interpreter hand written in assembly and it generates native code to achieve peak performance. You can only asm.js'fy a normal Lua interpreter which is up to 64x slower than LuaJIT on benchmarks, when compared natively. So asm.js'fied Lua will be up to 128x slower. Does not sound that impressive...

backspaces• 13 years ago

It is SOOO odd to see folks not "get" the JavaScript Everywhere revolution. Node, JS/CoffeeScript, JSON: Server, Client, Network Data. Complete stack, period.

C++?? Gack, so yesterday. Python, Ruby, etc .. so without dynamic windows everywhere.

Google?? So confused. What's their next project jerked out of our workflow? When is Google coming out of beta?

Keep up the good work /be

   -- Owen

melling• 13 years 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).

fhd25• 13 years 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/

(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.

ux-app6• 13 years 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• 13 years 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• 13 years 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.

derleth• 13 years 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.

pyre• 13 years ago

  | DOM manipulation may be absurdly slow however
  | it cannot hold a candle to latency hold-ups.

Just an anecdote, but jQueryUI + IE8 took 8 seconds to style all of the buttons[1] we had on a page during one call. Granted, we had a ton of buttons (most were hidden), but that's a lot of time. The same call on Firefox and Chrome were fractions of a second (can't remember the exact numbers, but Chrome was faster at the time), and this was a couple of years ago. DOM manipulation can be a real drag.

[1] http://jqueryui.com/button/

untog3• 13 years ago

What makes web apps feel like swimming through molasses is the DOM.

In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

ux-app6• 13 years ago

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps.

My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise.

notatoad• 13 years ago

For most applications, the Dom is the weak point because manipulating the Dom is as ambitious as the apps get. The exciting part of asm.js is not that it can speed up existing apps, it's all the cool new things you can do on the client side now that were simply to slow to be possible before.

ux-app6• 13 years ago

Yeah that's a fair point. What kinds of new apps do you think this will enable (besides games)?

It seems that the DOM will continue to be the major bottleneck since presumably the GUI for these new apps will still be DOM based.

just2n5• 13 years ago

Like this? http://jsfiddle.net/eymAS/2/

The DOM is faster than almost everyone believes. It's not 2001 anymore, guys.

Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, and smarter compositing/painting algorithms in browsers (along with hardware acceleration) have made it possible to do some pretty ridiculous stuff.

ChuckMcM• 13 years ago

Man, that is just scary fast :-)

fhd25• 13 years ago

Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/

I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.

roel_v4• 13 years ago

So now we're going to say that in 2013 it is impressive that 160 rectangles can follow a mouse cursor? I see the advantages of client/server applications (as they used to be called), and presumably js/css apps will continue to get faster and asymptotically approach their client-only functional equivalents, but there is a thing about a hammer and all problems looking like nails that springs to mind when I see people claim that moving 160 rectangles in 16 ms / frame is 'scary fast'...

ux-app6• 13 years ago

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance.

Would be great if Chrome had this option off by default.

spyder2• 13 years ago

For me the movement is smooth but it still lags behind the mouse with 10-20 px. The Firefox version of the demo has a little less lag but still looks disconnected from the mouse when moved.

cpleppert• 13 years ago

The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios.

If you think about how native applications perform and then imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction you get a sense of what the problem is. There is simply no way to get the DOM to do something it wasn't designed to do, which is to be a document display interface and not a general graphical user interface. You have to clobber together a lot of interactions to get the desired behavior and not only does this increase the overhead for both your program and the DOM you are going to hit cases where the DOM isn't optimized.

This doesn't mean that the DOM is inherently slow. If you tried to offload the UI work onto javascript you wouldn't get the performance benefit of doing that on Asm.js or NACL. You really need unsafe code to solve this problem. Asm.js and NACL are only useful if you are going to do this; targeting the Canvas and WebGL gives you the ability to do that.

zobzu• 13 years 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• 13 years ago

> its slightly slower (a few %) than regular JS on browsers without asm.js support

You sure you meant what you said here?

kibibu2• 13 years 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.

capisce3• 13 years ago

"within 2x the speed of native"

Of crippled native, with things like SIMD instructions disabled.

acdha• 13 years ago

With some optimizations unrealized: it's not like everything can use SIMD or that all problems which could theoretically use SIMD actually benefit. Comparing scalar code is still useful for the vast majority of programs executed.

mosqutip• 13 years 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.

callahad2• 13 years 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• 13 years 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• 13 years ago

There a bug for V8 about implementing asm.js: http://code.google.com/p/v8/issues/detail?id=2599

timothya2• 13 years ago

At Google I/O this year, Google indicated some interest in asm.js, and noted that since asm.js was released V8 has already gotten significantly faster in running asm.js code.

With regards to Dart, Google has said that they plan to get the language formally standardized after reaching the stable 1.0 release. It doesn't make sense to try to standardize something that's still in beta.

bad_user3• 13 years ago

I hope Dart's beta won't last for 10 years, like their other betas.

solomatov8• 13 years ago

I think this is actually is a very good thing. Before the next big thing can be standardized, it should be created. Google tried to create a next big thing, by moving in several directions, among them are both Dart and PNaCl (which IMO, is the way to go, it provides good browser integration and 95% of the native code with both multithreading and other stuff). Mozilla, IMO, is more interest in keeping the status quo and resisting any significant innovation.

takluyver• 13 years ago

There's two kinds of innovation around technology platforms: you can innovate with the platform itself, by designing new operating systems, programming languages, browsers, libraries etc. Or you can innovate on top of the platform, by doing new things a level up. We benefit most from a balance of the two.

Mozilla aren't resisting innovation. They've chosen to keep Javascript (the platform) and innovate on top of it, e.g. with pdf.js. Google is aiming to develop alternative platforms. They're both valuable activities.

danbruc2• 13 years 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.

callahad2• 13 years 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• 13 years 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?

danbruc2• 13 years ago

That's correct, you can compile many things to JavaScript. But I think this is a suboptimal solution - besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack it makes development harder, for example debugging generated code in the browser is unnecessarily hard.

fhd25• 13 years ago

I'm not entirely sure myself, but it seems to be a bit more involved than that. I recently came across a thread [1] discussing how to add support for Objective-C and it seems the approach is to compile the Obj-C to C++... I think only C and C++ are supported at this point. But I'd bet they eventually get there.

The bigger problem however, is that most of the commonly used languages don't just compile to native executables. They include a runtime handling stuff like garbage collection and just-in-time compilation. Since these runtimes are usually written in C or C++, we'll get there if C compiled to asm.js gets fast enough. That's one of the goals of Emscripten :)

There's a demo [2] showing off various language runtimes compiled to asm.js. I'm not sure how they perform in comparison with JS, but the REPLs work pretty well.

[1] https://groups.google.com/forum/?fromgroups#!topic/emscripte...

[2] http://repl.it/languages

fhd25• 13 years ago

I see two big issues here:

1. "Sane" is highly subjective. There is no single optimal language for all problems and audiences.

2. Pushing a new language to all major browsers is hard, like you said. Maybe even impossible, several huge corporations with complex politics are involved.

Google is trying this approach with Dart, and I personally don't think it's the panacea, nor do I expect all major browsers to support it.

So the only alternative I see is to have a very flexible VM that can run pretty much any language. asm.js proves that JS is actually quite good at that. I'd still prefer something like native client, but asm.js is highly promising: It's downwards compatible and has some potential for optimisation at the same time.

bad_user3• 13 years ago

That's what asm.js is for, meant as bytecode for compilers.

Take asm.js (e.g. an efficient subset of Javascript), in combination with source maps meant for debugging, and presto, you have everything needed to compile source-code from whatever language you want, including C/C++.

discreteevent• 13 years ago

"from whatever language you want" - in practice, not really. If you have a language that relies on gc or some kind of vm then you are also going to have to deliver all the asm.js code for the vm. That's potentially a lot of code to deliver to the browser, could you use threads efficiently in your implementation etc. There's no story yet for anything beyond a statically compiled language and even if there is a story you would probably have to wait a long time to see whether it would deliver anything in practice.

IanChiles• 13 years ago

I'd vote for LuaJIT as a new, sane, replacement for JavaScript.

npalli2• 13 years 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/classi...

azakai10• 13 years 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.

npalli2• 13 years 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?

anon13852• 13 years ago

>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.

Single threaded Javascript was already 'fast enough' for the CRUD interfaces that makes up most web apps. Web apps are horrible to use because the network is unreliable for many people, latency is terrible for just about everybody, browsers provide a very poor and limited set of APIs for many of the tasks people actually want to do (interacting with hardware, file systems, audio, inter-app interoperability etc) and apps are forced to run inside a sandbox that can't be escaped. Cloud services nearly always mean that users lose control of their data. Web apps are rarely open source (and if they are you still can't change the version of the app that you actually use because it runs on a server you don't control). A faster Facebook with 3D effects is still a terrible platform.

Homer Simpson: Kids: there's three ways to do things; the right way, the wrong way and the Max Power way!

Bart: Isn't that the wrong way?

Homer Simpson: Yeah, but faster!

I think a lot of this obsession over Javascript speed is a distraction (support for more languages is nice for developers of course). Making slightly faster VMs is just an engineering problem: throw more resources at it and things will improve. The hard problems are political and also related to the basic network infrastructure (constrained by the laws of physics). Trying to recreate the entire operating system inside the browser, for all possible uses (even performance sensitive things), is a huge overreach when we don't seem to have a clue how to make the basic web app experience good. Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. If the world had moved to Gopher based OSs in the early 90s the web as we know it would not have come into existence. What future possible technologies are we destroying by locking ourselves into the web sandbox?

crabasa• 13 years ago

Is it fair to describe JS as single-threaded when all modern browsers support web workers?

Related: Why does it seem like web workers don't exist? I can hardly think of any popular libraries or web apps that make use of them, despite the seemingly obvious utility.

tachyonbeam• 13 years ago

Web workers are more like multiple processes than multiple threads, but yes, there are ways to use more than one CPU core in JS too.

danmaz74• 13 years ago

Our hashtagify.me uses them :)

kybernetikos• 13 years ago

After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread.

Of course this was in the early days, and it'd be good to retest it to see if it's better now.

I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.

Yoric6• 13 years ago

Let me detail tachyonbeam's answer.

All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment.

Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency.

Note: I'm a Firefox dev.

cwmma• 13 years ago

1. It's hard to use them in libraries due to restrictions on how to load them, Opera, Ie 10 and safari 5 require a same origin file, makes it hard to drop a worker into a slow part of jQuery. 2. Message passing can be slow and transferring only works for typed arrays which take time to convert to. Unless your calculations are much bigger then your data or converting to typed arrays isn't a bottleneck it may slow you down. 3. OO based inheritance patterns make it very hard to put pieces of your code into the worker, if your slow thing involved a call to jQuery. Ajax you can't call jQuery from the worker because it references the DOM but you can't pull out the Ajax method because it relies on $. extend and others meaning you have to rewrite $. Ajax from scratch (mot too bad in this case) or do major surgery on the library.

sillysaurus• 13 years ago

anyone writing performance sensitive apps will use multithreading

That assumes the performance sensitive app is amenable to multithreading. Many aren't.

vilya2• 13 years ago

Your comment has made me curious. I tried to think of some examples of performance sensitive apps that aren't amenable to multi-threading and I couldn't, but it seems like they could offer interesting areas for R&D. Can you share some examples?

gcr• 13 years ago

If you have a multicore machine -- the only kind of machine that brings a benefit to multithreading -- and if your problem is embarassingly parallel, you can usually get away with multiprocesses (MapReduce etc). That way, your single-threaded process can run on many cores.

haberman2• 13 years ago

> multithreading and SIMD capability disabled

[EDIT: it looks like I may have misinterpreted the article; see replies]

To clarify, I believe they ran the benchmarks with SSE disabled. SSE is more than just SIMD; these days SSE is used for most (all?) floating-point calculations, even non-SIMD. If you disable SSE, you force floating-point ops to use the old x87 FPU, which has been discouraged by the CPU manufacturers for over 10 years.

In other words, disabling SSE is significantly crippling all floating-point performance.

http://www.realworldtech.com/physx87/4/

http://stackoverflow.com/questions/3206101/extended-80-bit-d...

(nothing against asm.js, which I think is very cool)

azakai10• 13 years ago

Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure.

What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function calls in C/C++.

VoxPelli• 13 years ago

There is work going on in enabling Javascript to get better at doing things in parallel - both on CPU and GPU.

Eg. check out the ParallelArray() from the River Trail project by Intel: http://wiki.ecmascript.org/doku.php?id=strawman:data_paralle... & http://en.m.wikipedia.org/wiki/River_Trail_(JavaScript_engin... At least Firefox has an initial implementation: https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

The benefit if asm.js being based on ordinary javascript is that they can use these improvements to javascript itself right away more or less.

Spearchucker• 13 years ago

It's good progress all the same, but doesn't do much for the end user that still relies on an often shitty Internet connection.

fulafel4• 13 years ago

> anyone writing performance sensitive apps will use MT right?

No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right.

You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation.

If you're running on something else than modern consoles, you don't know how many cores your users will have, the average might be 2 so your average returns on the effort will suck (vs spending equivalent effort elsewhere).

Witness modern Web browsers, for example, where Google, Mozilla, Apple and Microsoft employ some of the best C++ programmers in the world, routinely of pulling off heroic feats, and they haven't seen it worth the effort yet despite Core 2 and Athlon X2 hitting mainstream desktop at about 2005-2006, 8 years ago.

nnnnnnnninnnnnn• 13 years ago

You're making writing multi-threaded code sound like a herculean task. Sure, doing MT with mutexes is a pain, but programming with actors (message passing) is simpler. You can easily scale this for variable number of cores.

w0utert2• 13 years ago

I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the top 0.5% programmers can handle. It's not that bad you know... If you're a half-way decent programmer and don't litter your single-threaded code with globals, shared memory and functions with side-effects, like you shouldn't anyway, parallelizing it after the fact to at least is usually pretty straightforward even. Maybe not optimal, but safe, and faster than single-core on multi-core hardware.

Marat_Dukhan• 13 years ago

It really should be a 100x slowdown! Their "optimized" Linpack numbers (41 GFLOPs) are too low for this system. The CPU they use can deliver 108 GFLOPs at base frequency and 120 GFLOPs at max turbo frequency, and good LU implementations (e.g. MKL) can achieve >90% of these peak numbers.

namuol• 13 years ago

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

iso8859-12• 13 years 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".

jackmaney8• 13 years 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.

ricardobeat2• 13 years ago

Is your FF up to date? Since around v20 it feels way snappier than Chrome, at least on OSX.

jackmaney8• 13 years 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• 13 years 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• 13 years 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-fi...

pcwalton2• 13 years ago

Your Firefox crashes with more than 4-6 tabs? That's definitely not normal. Check for misbehaving addons and malware and file a bug if it's reproducible.

jackmaney8• 13 years ago

I didn't use a single addon.

Ygg22• 13 years ago

That might be true in your case, but I'm running Firefox 21 smoothly with over 11 tabs open as I type this. And I have a truckload of addons changing my addon bar approximately 12(of 24 installed).

What you are experiencing is definitely abnormal. The only days I have that kind of performance issue is on my old laptop. In which case try switching to Aurora/Nightly, it might help.

Yoric6• 13 years ago

I have about 300 tabs open on my Firefox, and the Gecko Profiler is active. Things are running very smoothly, thank you very much.

So, my best guess is that you have an add-on killing your performance and stability.

jackmaney8• 13 years ago

Nope, I ran no addons.

ilaksh2• 13 years 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• 13 years 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.)

ilaksh2• 13 years 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.

fhd25• 13 years 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• 13 years 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• 13 years 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.

mratzloff2• 13 years 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• 13 years 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.

mratzloff2• 13 years 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.

azakai10• 13 years ago

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

eblade• 13 years 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• 13 years 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• 13 years 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• 13 years 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• 13 years 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• 13 years 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• 13 years 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-12• 13 years 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.

solomatov8• 13 years 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.

BrendanEich15• 13 years 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

solomatov8• 13 years 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).

Mozilla can produce near-native performance on the Web

Related Stories