Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla can produce near-native performance on the Web

arstechnica.com

Post reply on HN
Print view View original

81–90 of 202 posts

Re: Mozilla can produce near-native performance on the Web

#81

Post by fhd2 »

danbruc wrote: post #20

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.

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.

Re: Mozilla can produce near-native performance on the Web

#82

Post by tracker1 »

axaxs wrote: post #30
callahad wrote: post #21

Earlier quoted context omitted.

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.

But that's like converting C into python. Why not begin a new/existing language that can be compiled and ran at native speeds?

Google already has NaCl

Re: Mozilla can produce near-native performance on the Web

#83

Post by fhd2 »

callahad wrote: post #21
danbruc wrote: post #20

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.

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.

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

Re: Mozilla can produce near-native performance on the Web

#84

Post by just2n »

roel_v wrote: post #80
just2n wrote: post #65

Earlier quoted context omitted.

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, an…

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 c…

The parent's comment was that it is essentially infeasible to have a single div follow the cursor due to performance issues with the DOM. The fiddle includes 160 divs and opacity to demonstrate that that claim is false.

There's an awful lot of red herring going on in your post. It sounds like you have some problems with the web, but they most certainly aren't relevant to this discussion.

Re: Mozilla can produce near-native performance on the Web

#85

Post by ux-app »

just2n wrote: post #65
ux-app wrote: post #5

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 pre…

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, an…

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.

Re: Mozilla can produce near-native performance on the Web

#87

Post by VoxPelli »

npalli wrote: post #22

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

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.

Re: Mozilla can produce near-native performance on the Web

#88

Post by fhd2 »

ilaksh wrote: post #46

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 dri…

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

Re: Mozilla can produce near-native performance on the Web

#89

Post by prodigal_erik »

ilaksh wrote: post #56
omaranto wrote: post #52

Earlier quoted context omitted.

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

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.

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.

Re: Mozilla can produce near-native performance on the Web

#90

Post by bad_user »

npalli wrote: post #49
azakai wrote: post #29

Earlier quoted context omitted.

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

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?

> why would anyone write in a crippled C-like subset of javascript

Because asm.js is not meant for people, but for compilers.

For example the Unreal Engine has been recently compiled from C/C++ to asm.js and is running in the browser: http://www.unrealengine.com/html5/

Post reply on HN