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

71–80 of 202 posts

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

#71

Post by azakai »

haberman wrote: post #66
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…

Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure.

What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function calls in C/C++.

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

#72

Post by timothya »

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.

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

#73

Post by haberman »

azakai wrote: post #71
haberman wrote: post #66

Earlier quoted context omitted.

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

Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure. What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function cal…

I must have misinterpreted this remark:

> In general, I took the highest-ranked pure C++ routines for each test. Versions that used, for example, SSE functions were excluded, as were those with explicit multithreading.

For "functions" I interpreted "functionality," but I think now it must mean SSE intrinsics?

Sorry for the confusion.

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

#74

Post by krebby »

ChuckMcM wrote: post #69
just2n wrote: post #65

Earlier quoted context omitted.

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

It should be, it's hardware-accelerated (take a look at the translate3d hack)

Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-trans...

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

#75

Post by _greim_ »

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

> In that case it seems that we need something new to replace CSS for layout

There's so much that CSS (and browsers in general) do that we take for granted, which is good in one sense but bad since you can't dip below those abstractions and grapple with the layout engine (or garbage collector, or HTML parser, or selector engine) at a low level. You get the whole ball of wax and all that stuff runs all the time, even if you don't actually need it. In my view this is essentially what separates HTML apps from native ones.

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

#76

Post by Gravityloss »

haberman wrote: post #73
azakai wrote: post #71

Earlier quoted context omitted.

Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure. What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function cal…

I must have misinterpreted this remark: > In general, I took the highest-ranked pure C++ routines for each test. Versions that used, for example, SSE functions were excluded, as were those with explicit multithreading. For "functions" I interpreted "functionality," but I think now it must mean SSE intrinsics? Sorry for the confusion.

I'm glad you made the comment, others might read it the same way as you did originally. This clears the potential misunderstanding.

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

#77

Post by fhd2 »

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…

Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/

I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.

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

#78

Post by DrPizza »

haberman wrote: post #73
azakai wrote: post #71

Earlier quoted context omitted.

Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure. What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function cal…

I must have misinterpreted this remark: > In general, I took the highest-ranked pure C++ routines for each test. Versions that used, for example, SSE functions were excluded, as were those with explicit multithreading. For "functions" I interpreted "functionality," but I think now it must mean SSE intrinsics? Sorry for the confusion.

Yes, sorry, I meant SSE intrinsics. As I think I note later in the article, the compiler I used emitted scalar SSE2 for floating point.

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

#80

Post by roel_v »

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…

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 claim that moving 160 rectangles in 16 ms / frame is 'scary fast'...
Post reply on HN