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

21–30 of 202 posts

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

#21

Post by callahad »

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.

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

#22

Post by npalli »

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

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

#23

Post by carbocation »

ihsw wrote: post #10
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…

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

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.

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

#24

Post by azakai »

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

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.

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

#25

Post by ux-app »

notatoad wrote: post #15
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…

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.

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.

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

#26

Post by untog »

ux-app wrote: post #17
untog wrote: post #12

Earlier quoted context omitted.

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.

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…

An example from my experience- auto-complete filtering. Loading a list of the user's Facebook friends (which can number into the thousands) and filter as they type.

When that's on the main UI thread it's hideous- the page stops responding to typing, so people hit the key twice, the whole page feels like it's hanging. It's not constant CPU usage, but it's CPU usage at the exact moment the user expects the site to react immediately. Same goes for calculations when a user is swiping, or something like that.

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

#27

Post by MatthewPhillips »

pcwalton wrote: post #19
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…

The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.

Then what is it?

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

#28

Post by azakai »

kibibu wrote: post #13
Arelius wrote: post #7

Earlier quoted context omitted.

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

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.

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

#29

Post by azakai »

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…

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.

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

#30

Post by axaxs »

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.

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