Mozilla can produce near-native performance on the Web • Hacker News Board

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

#111

Post by Yoric » Thu, May 23, 2013, 10:30 AM UTC

vilya wrote: post #109

sillysaurus wrote: post #38

Earlier quoted context omitted.

anyone writing performance sensitive apps will use multithreading That assumes the performance sensitive app is amenable to multithreading. Many aren't.

Your comment has made me curious. I tried to think of some examples of performance sensitive apps that aren't amenable to multi-threading and I couldn't, but it seems like they could offer interesting areas for R&D. Can you share some examples?

Consider a single tab of a web browser, for instance. By specification, much of the code must run in the same thread. Keeping the semantics while getting code out of the thread is extremely difficult, often impossible.

I should know, that's my dayjob :)

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

#112

Post by Yoric » Thu, May 23, 2013, 10:37 AM UTC

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.

Let me detail tachyonbeam's answer.

All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment.

Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency.

Note: I'm a Firefox dev.

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

#113

Post by Yoric » Thu, May 23, 2013, 10:38 AM UTC

kybernetikos wrote: post #99

crabasa wrote: post #35

Earlier quoted context omitted.

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.

After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread. Of course this was in the early days, and it'd be good to retest it to see i…

Working on it :)

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

#114

Post by Yoric » Thu, May 23, 2013, 10:47 AM UTC

ux-app wrote: post #25

notatoad wrote: post #15

Earlier quoted context omitted.

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.

I expect Virtual Machines for domain-specific languages. I also expect (de)compression, cryptography, number-crunching, graphics algorithms, etc.

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

#115

Post by grn » Thu, May 23, 2013, 10:49 AM UTC

I wonder how the Internet would have looked like if it had developed the way that Alan Kay proposed (i.e. a browser as a mini-operating system). It's quite possible that we'd have much better performance (among other things) from the start.

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

#116

Post by Yoric » Thu, May 23, 2013, 10:50 AM UTC

mortehu wrote: post #63

axaxs wrote: post #30

Earlier quoted context omitted.

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

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

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

#117

Post by Yoric » Thu, May 23, 2013, 10:55 AM UTC

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.

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

#118

Post by wwweston » Thu, May 23, 2013, 10:58 AM UTC

ux-app wrote: post #34

daeken wrote: post #18

Earlier quoted context omitted.

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

I totally think CSS layout could use some improvements, but isn't the separation you're talking about here already pretty strong?

I'm struggling to think of an example of a situation where text styles affect layout on containers where dimensions are anything other than 'auto'. And any situation at all where text styles affect positioning.

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

#119

Post by ksk » Thu, May 23, 2013, 10:59 AM UTC

Why dont they just insert regular C/C++ source code inside HTML and be done with it? Eventually the browser is just going to be a download manager that downloads executable code and runs it locally :P

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

#120

Post by cwmma » Thu, May 23, 2013, 11:09 AM UTC

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.

1. It's hard to use them in libraries due to restrictions on how to load them, Opera, Ie 10 and safari 5 require a same origin file, makes it hard to drop a worker into a slow part of jQuery. 2. Message passing can be slow and transferring only works for typed arrays which take time to convert to. Unless your calculations are much bigger then your data or converting to typed arrays isn't a bottleneck it may slow you down. 3. OO based inheritance patterns make it very hard to put pieces of your code into the worker, if your slow thing involved a call to jQuery. Ajax you can't call jQuery from the worker because it references the DOM but you can't pull out the Ajax method because it relies on $. extend and others meaning you have to rewrite $. Ajax from scratch (mot too bad in this case) or do major surgery on the library.