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

51–60 of 202 posts

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

#51

Post by Skalman »

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…

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

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

#52

Post by omaranto »

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…

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

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

#53

Post by NinjaWarrior »

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

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

#54

Post by btilly »

hollerith wrote: post #16
btilly wrote: post #11

Earlier quoted context omitted.

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

Thanks for pointing out my error. (Hope you don't mind that I deleted my comment.)

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.

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

#55

Post by derleth »

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…

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.

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

#56

Post by ilaksh »

omaranto wrote: post #52
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…

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.

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

#57

Post by pcwalton »

jackmaney wrote: post #41

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.

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.

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

#58

Post by capisce »

zobzu wrote: post #6

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.

"within 2x the speed of native"

Of crippled native, with things like SIMD instructions disabled.

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

#59

Post by boyter »

NinjaWarrior wrote: post #53

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

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.

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

#60

Post by pyre »

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…

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

Post reply on HN