Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Massive: The asm.js Benchmark

hacks.mozilla.org

Post reply on HN
Print view View original

11–20 of 74 posts

Re: Massive: The asm.js Benchmark

#11

Post by TazeTSchnitzel »

masklinn wrote: post #10
TazeTSchnitzel wrote: post #9

Earlier quoted context omitted.

I agree. asm.js has several strengths over NaCl and even PNaCl: * It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today * It doesn't require a new runtime or API, merely using the existing web APIs * It is simple for other browser vendors to implement, and isn't reliant on a sin…

> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance Or JIT-compiled with phases specifically built for the kind of JS it produces e.g. Webkit's FTL tends to work very well on asm.js code, though it's not an asm.js AOT compiler. > It doesn't require a new runtime or API, merely using the existing web APIs That's not entirely true, AFAIK asm…

> Or JIT-compiled with phases specifically built for the kind of JS it produces e.g. Webkit's FTL tends to work very well on asm.js code, though it's not an asm.js AOT compiler.

This is true, too. While I think you'd get the best results from AOT compilation, it should also compile really well under JITs since it has all the type information you normally have to guess.

> That's not entirely true, AFAIK asm.js adds at least two functions to the Math namespace (imul and fround)

That's an addition to JavaScript which isn't specific to asm.js, however, and both can be polyfilled. Math.fround, in particular, is useful outside of asm.js.

The stuff asm.js needs is all part of standard JS now, while NaCl and PNaCl require their own special API (Pepper) which only has one implementation (Google's).

Re: Massive: The asm.js Benchmark

#12

Post by amelius »

TazeTSchnitzel wrote: post #9
higherpurpose wrote: post #8

I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl. It's unacceptable that a "browser-os" that should have no problem being architecture agnostic, still gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how crazy is that? I can understand ARM not having…

I agree. asm.js has several strengths over NaCl and even PNaCl: * It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today * It doesn't require a new runtime or API, merely using the existing web APIs * It is simple for other browser vendors to implement, and isn't reliant on a sin…

I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't consider them a multithreading solution, because they don't allow a shared address space for inter-thread communication (only message-passing). This can be detrimental for performance, because the "structural sharing" paradigm becomes useless.

I think that a base-language without support for garbage collection would be preferable. The main advantage is that multithreading is easier to implement. (Any language built on top of this language could implement its own garbage collection, in principle.)

Re: Massive: The asm.js Benchmark

#13

Post by TazeTSchnitzel »

amelius wrote: post #12
TazeTSchnitzel wrote: post #9

Earlier quoted context omitted.

I agree. asm.js has several strengths over NaCl and even PNaCl: * It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today * It doesn't require a new runtime or API, merely using the existing web APIs * It is simple for other browser vendors to implement, and isn't reliant on a sin…

I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't conside…

> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform

Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers.

I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web workers, it's the DOM that's the problem.

And if you can share a typed array, you have a shared address space, as asm.js uses typed arrays for its heap.

EDIT: Aha, yes, Mozilla are working on this! https://bugzilla.mozilla.org/show_bug.cgi?id=933001

Re: Massive: The asm.js Benchmark

#14

Post by pjmlp »

TazeTSchnitzel wrote: post #7
fridek wrote: post #5

Earlier quoted context omitted.

I have Intel i7 running on Linux. Got 2,984 running Chrome 38 and 8,778 on Firefox 33, but I think now it's just fair to wait for couple of iterations of Chrome to identify bottlenecks and fix them. It's not uncommon for benchmarks to focus on some particular strength/weakness that is easily fixable. The same happened with Firefox and Octane 2.0.

I'm not sure if Chrome is ever going to catch up to Firefox here. It's been slower than Firefox at asm.js ever since it was announced, because Chrome doesn't do AOT compilation for it. EDIT: Although I suppose JIT compilers would love asm.js as it has all the type info they want, but there's probably tons of overhead there thus explaining how Chrome has worse results.

I would say Google team has other priorities....

Re: Massive: The asm.js Benchmark

#15

Post by pjmlp »

higherpurpose wrote: post #8

I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl. It's unacceptable that a "browser-os" that should have no problem being architecture agnostic, still gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how crazy is that? I can understand ARM not having…

Agreed.

I am a bit vocal about native vs web, but in what concerns web I prefer asm.js, given that for me (P)NaCl feels a bit like ActiveX.

Re: Massive: The asm.js Benchmark

#16

Post by amelius »

TazeTSchnitzel wrote: post #13
amelius wrote: post #12

Earlier quoted context omitted.

I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't conside…

> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers. I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web worke…

Interesting! Yes, that would help a lot, but I'm not sure how growing heaps will be modeled then (are they allocated block by block?) And how is a growing heap communicated in practice between threads? Is every read-operation to be guarded by a check if the corresponding block is available in the current thread?

Re: Massive: The asm.js Benchmark

#17

Post by TazeTSchnitzel »

pjmlp wrote: post #14
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

I'm not sure if Chrome is ever going to catch up to Firefox here. It's been slower than Firefox at asm.js ever since it was announced, because Chrome doesn't do AOT compilation for it. EDIT: Although I suppose JIT compilers would love asm.js as it has all the type info they want, but there's probably tons of overhead there thus explaining how Chrome has worse results.

I would say Google team has other priorities....

Yes, like trying to destroy the open web with NaCl.

Re: Massive: The asm.js Benchmark

#18

Post by TazeTSchnitzel »

amelius wrote: post #16
TazeTSchnitzel wrote: post #13

Earlier quoted context omitted.

> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers. I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web worke…

Interesting! Yes, that would help a lot, but I'm not sure how growing heaps will be modeled then (are they allocated block by block?) And how is a growing heap communicated in practice between threads? Is every read-operation to be guarded by a check if the corresponding block is available in the current thread?

I don't know either. I'm aware that asm.js currently doesn't allow expanding the heap (it's always a fixed-size allocation), but that might change.

If you mean allocating from that heap, I imagine it'd work as it currently does: the program implements its own allocator.

Re: Massive: The asm.js Benchmark

#19

Post by CmonDev »

TazeTSchnitzel wrote: post #9
higherpurpose wrote: post #8

I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl. It's unacceptable that a "browser-os" that should have no problem being architecture agnostic, still gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how crazy is that? I can understand ARM not having…

I agree. asm.js has several strengths over NaCl and even PNaCl: * It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today * It doesn't require a new runtime or API, merely using the existing web APIs * It is simple for other browser vendors to implement, and isn't reliant on a sin…

Only one thing is remaining - forbidding manually-written JS running in browsers as "unsafe", so that industry can focus on creating the good tool-chains for modern languages compiling to asm.js.

Re: Massive: The asm.js Benchmark

#20

Post by TazeTSchnitzel »

acqq wrote: post #3
itsbits wrote: post #2

would love to know how is the performance in V8 chrome js engine??

Run it with your Chrome and post the results: http://kripken.github.io/Massive/

I got 2,996 in Firefox and 1,277 in Chrome (2013 MacBook Air 13").

Interestingly, Chrome had much worse performance for float32 than float64... yet Firefox had slightly better performance. I guess the Chrome team implemented Math.fround yet none of the optimisations which make it useful!

Post reply on HN