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

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

#141

Post by bad_user » Thu, May 23, 2013, 2:30 PM UTC

timothya wrote: post #72

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…

At Google I/O this year, Google indicated some interest in asm.js, and noted that since asm.js was released V8 has already gotten significantly faster in running asm.js code. With regards to Dart, Google has said that they plan to get the language formally standardized after reaching the stable 1.0 release. It doesn't make sense to try to standardize something that's still in beta.

I hope Dart's beta won't last for 10 years, like their other betas.

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

#142

Post by azakai » Thu, May 23, 2013, 2:51 PM UTC

mratzloff wrote: post #64

I think it's becoming clear that there is room for two classes of web language: one for general use (JavaScript) and one for high performance applications or games. Let's get a real language alternative, free of half measures or compromises.

All languages and VMs are compromises: JavaScript, JVM, CLR, LLVM, Flash, etc. Question is which compromise you prefer.

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

#143

Post by berkut » Thu, May 23, 2013, 2:51 PM UTC

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…

> BTW, have you heard that the next Haswell processors can get only 5% performance improvement?

Bollocks - using the new gather AVX instructions, I've seen close to a 40% increase over IB on some floating-point code I've hand-written with intrinsics.

Existing C++ code is around 13-16% faster thanks to better cache bandwidth and a huge L4 cache. Turn on FMA (fused multiply–add) optimisation and that goes to ~20% faster.

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

#144

Post by azakai » Thu, May 23, 2013, 2:53 PM UTC

acdha wrote: post #128

capisce wrote: post #58

Earlier quoted context omitted.

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

Furthermore, explicit SIMD code (for example, using SSE functions) is not portable. The comparison here was portable C/C++ to portable asm.js.

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

#145

Post by timothya » Thu, May 23, 2013, 3:06 PM UTC

bad_user wrote: post #141

timothya wrote: post #72

Earlier quoted context omitted.

At Google I/O this year, Google indicated some interest in asm.js, and noted that since asm.js was released V8 has already gotten significantly faster in running asm.js code. With regards to Dart, Google has said that they plan to get the language formally standardized after reaching the stable 1.0 release. It doesn't make sense to try to standardize something that's still in beta.

I hope Dart's beta won't last for 10 years, like their other betas.

The team said at I/O that they're trying to hit 1.0 sometime this summer.

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

#146

Post by w0utert » Thu, May 23, 2013, 3:12 PM UTC

fulafel wrote: post #135

w0utert wrote: post #134

Earlier quoted context omitted.

I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the…

Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases. I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do…

The challenge is to design your code in a way that either makes it impossible to end up with race conditions or non-deterministic behavior, or if at least limit the number of possible points-of-failure. This requires a good understanding in what coding styles and data structures to avoid or pay extra attention to, but if you're aware of the pitfalls, it's actually not all that difficult. Just make sure your workers don't share any state, collect their outputs in a single thread-safe queue, use off the shelf components to represent threads, thread pools and locking mechanisms, be aware of things like multiple-read-single-write locks, and if you really can't avoid writes to shared state, only then start thinking about mutexes or semaphores. If you're smart about how you set up the code, more often than not you can get away with just some thread-safe queues. Take a look at Objective-C's block syntax and GCD for example, it makes maybe 90% of tasks suitable for multithreading dead easy.

Your estimate only 0.05% of programmers could write reliable multithreaded code is extremely pessimistic, cynical even. I almost feel flattered, having written a fair amount of multithreaded code that works perfectly myself, but I most definitely would dare count me with the 0.05% top programmers or whatever. My estimate is that with proper preparation, at least 50% of all programmers could learn to write reliable multithreaded code, and the remaining 50% probably wouldn't have a use for it anyway.

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

#147

Post by roel_v » Thu, May 23, 2013, 3:13 PM UTC

roel_v wrote: post #138

griffordson wrote: post #136

Earlier quoted context omitted.

If an app that had no sustainable future as a native app becomes possible as a web app, don't users also benefit? The fact is that many people are willing to pay for a service they continue to get value from month after month. And the recurring revenue also usually comes with recurring support because companies have to keep winning customer loyalty in a way they never have to with a one time sale. I think it is a net…

"If an app that had no sustainable future as a native app becomes possible as a web app, don't users also benefit?" Of course they do, therefore charging for software (desktop & web alike) = good. Make no mistake on which side in that debate I'm on. But let's call it like that. "And developers win because there are more viable businesses which need their skills over the long term." Sure, and it's no more than fair, a…

I should add that another reason can be "because I can", which is a perfectly fine reason too, but then label it as such so that naive greenhorns don't start pushing production systems in this direction, requiring others to then deal with the fallout.

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

#148

Post by cpleppert » Thu, May 23, 2013, 3:14 PM UTC

just2n wrote: post #65

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…

Like this? http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, an…

The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios.

If you think about how native applications perform and then imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction you get a sense of what the problem is. There is simply no way to get the DOM to do something it wasn't designed to do, which is to be a document display interface and not a general graphical user interface. You have to clobber together a lot of interactions to get the desired behavior and not only does this increase the overhead for both your program and the DOM you are going to hit cases where the DOM isn't optimized.

This doesn't mean that the DOM is inherently slow. If you tried to offload the UI work onto javascript you wouldn't get the performance benefit of doing that on Asm.js or NACL. You really need unsafe code to solve this problem. Asm.js and NACL are only useful if you are going to do this; targeting the Canvas and WebGL gives you the ability to do that.

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

#149

Post by i_s » Thu, May 23, 2013, 3:54 PM 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…

It is still not good. I've started working on an asteroids game [0], and I tried moving my physics calculations to a background thread, but it ended up being slower.

0 http://www.isaksky.com/asteroids/

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

#150

Post by vilya » Thu, May 23, 2013, 4:17 PM UTC

Yoric wrote: post #111

vilya wrote: post #109

Earlier quoted context omitted.

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

So the reason you can't make it faster than JavaScript by multi-threading it is... because of JavaScript? :-)

I had a look at your profile and it looks like you're doing some very valuable work. I was rather hoping for some examples which didn't involve JavaScript, though.