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

31–40 of 202 posts

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

#31

Post by danbruc »

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.

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.

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

#32

Post by callahad »

mosqutip wrote: post #14

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

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.

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

#33

Post by cliffbean »

ndesaulniers wrote: post #9
cliffbean wrote: post #2

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…

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

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

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

#34

Post by ux-app »

daeken wrote: post #18
ux-app wrote: post #17

Earlier quoted context omitted.

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…

> 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. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.

> The reason they're slow is that they're also extremely complex and slow operations.

In that case it seems that we need something new to replace CSS for layout.

Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc).

This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.

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

#35

Post by crabasa »

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…

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.

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

#36

Post by kibibu »

azakai wrote: post #28
kibibu wrote: post #13

Earlier quoted context omitted.

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.

It's not an extra two operations. An optimizing JIT like CrankShaft or IonMonkey can remove the first |0 operation in code paths where it is not needed (that is, where you call it with an integer), and can remove the second |0 even more easily by simple inference - in fact, the second |0 allows the JIT to emit a 32-bit addition, with no overflow checks. So it can make code faster, with or without asm.js.

Count the number of times you wrote "can" vs how many times you typed "does". Similar stuff happens with C++ compilers all the time, where certain code "can" help the compiler but, in practice, doesn't always.

The linked benchmarks do show a slowdown with asm.js in IE10. Whether this is due to type annotations or something else I don't know.

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

#37

Post by tachyonbeam »

crabasa wrote: post #35
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…

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.

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.

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

#38

Post by sillysaurus »

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…

anyone writing performance sensitive apps will use multithreading

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

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

#40

Post by azakai »

kibibu wrote: post #36
azakai wrote: post #28

Earlier quoted context omitted.

It's not an extra two operations. An optimizing JIT like CrankShaft or IonMonkey can remove the first |0 operation in code paths where it is not needed (that is, where you call it with an integer), and can remove the second |0 even more easily by simple inference - in fact, the second |0 allows the JIT to emit a 32-bit addition, with no overflow checks. So it can make code faster, with or without asm.js.

Count the number of times you wrote "can" vs how many times you typed "does". Similar stuff happens with C++ compilers all the time, where certain code "can" help the compiler but, in practice, doesn't always. The linked benchmarks do show a slowdown with asm.js in IE10. Whether this is due to type annotations or something else I don't know.

Are you saying it's as unpredictable as C++ performance then? I'll take that ;)

I wrote "can" because there are no guarantees, but in practice, this is definitely done in Firefox and Chrome. See

http://www.arewefastyet.com/#machine=11&view=breakdown&#...

- they don't get that close to native speed without such optimizations.

Not sure what is going on in IE10, but I am more curious about IE11.

Post reply on HN