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

121–130 of 202 posts

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

#121

Post by solomatov »

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.

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

#122

Post by solomatov »

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…

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.

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

#123

Post by jackmaney »

pcwalton wrote: post #57
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.

I didn't use a single addon.

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

#124

Post by jackmaney »

Yoric wrote: post #117
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.

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.

Nope, I ran no addons.

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

#125

Post by jackmaney »

ricardobeat wrote: post #44
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.

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

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.

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

#126

Post by ihnorton »

Yoric wrote: post #116
mortehu wrote: post #63

Earlier quoted context omitted.

Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.

They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).

> - will only run on the hardware platforms for which you have developed.

What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement.

https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...

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

#127

Post by fulafel »

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

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

#128

Post by acdha »

capisce wrote: post #58
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.

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.

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

#129

Post by discreteevent »

bad_user wrote: post #92
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.

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

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

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

#130

Post by roel_v »

just2n wrote: post #84
roel_v wrote: post #80

Earlier quoted context omitted.

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.

Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again.

Unreal engine in the browser? Seriously? Because of what - because it's easier to update people's clients when they download it again every time they visit your website? We had web launchers and auto-updating that solved everything the web brings as an advantage over desktop applications (in the use cases that require fast graphics, i.e. not CRUD line of business applications) years ago.

The elephant in the room here is that people want to push web applications because it's easier to make money from them, and you can make more of it, over a longer time. Look, I do it too, I know that the web beats the pants off client-only software from a business point of view. But let's call a spade a spade and not tip toe around it with bullshit pseudo-arguments like 'ease of deployability' and 'social sharing' and 'portability' and 'platform-agnosticity'.

Post reply on HN