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

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

#61

Post by chii » Thu, May 23, 2013, 4:53 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 see porting over existing codebases and rendering not via DOM but webgl as the path this takes on.

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

#62

Post by mratzloff » Thu, May 23, 2013, 4:58 AM 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…

Intel is getting their lunch handed to them by ARM. People value power consumption over performance these days, so why would they continue pumping out faster chips?

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

#63

Post by mortehu » Thu, May 23, 2013, 5:04 AM UTC

axaxs wrote: post #30

callahad wrote: post #21

Earlier quoted context omitted.

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?

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.

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

#64

Post by mratzloff » Thu, May 23, 2013, 5:04 AM UTC

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.

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

#65

Post by just2n » Thu, May 23, 2013, 5:05 AM UTC

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, and smarter compositing/painting algorithms in browsers (along with hardware acceleration) have made it possible to do some pretty ridiculous stuff.

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

#66

Post by haberman » Thu, May 23, 2013, 5:08 AM UTC

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…

> multithreading and SIMD capability disabled

[EDIT: it looks like I may have misinterpreted the article; see replies]

To clarify, I believe they ran the benchmarks with SSE disabled. SSE is more than just SIMD; these days SSE is used for most (all?) floating-point calculations, even non-SIMD. If you disable SSE, you force floating-point ops to use the old x87 FPU, which has been discouraged by the CPU manufacturers for over 10 years.

In other words, disabling SSE is significantly crippling all floating-point performance.

http://www.realworldtech.com/physx87/4/

http://stackoverflow.com/questions/3206101/extended-80-bit-d...

(nothing against asm.js, which I think is very cool)

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

#67

Post by eblade » Thu, May 23, 2013, 5:18 AM UTC

It seemed that the general idea of web being slow is so polarizing that each and everyone of us can't even pinpoint where the problem is. I suspect the problem is a multidimensional one.

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

#68

Post by wyck » Thu, May 23, 2013, 5:18 AM UTC

MatthewPhillips wrote: post #27

pcwalton wrote: post #19

Earlier quoted context omitted.

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

Then what is it?

To add to ricardobeat, it's all repaints and recalculations. Web devs have become overzealous with smashing JS into every nook and cranny to manipulate the dom, it seems to be a battle Google is trying to educate people about, and good on them.

Open dev tools in chrome, the click network/frames, hit record and refresh the page. Do this on a sluggish site that uses tons of js and you will see the problem.

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

#69

Post by ChuckMcM » Thu, May 23, 2013, 5:19 AM 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…

Man, that is just scary fast :-)

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

#70

Post by danmaz74 » Thu, May 23, 2013, 5:34 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.

Our hashtagify.me uses them :)