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

21–30 of 74 posts

Re: Massive: The asm.js Benchmark

#21

Post by TazeTSchnitzel »

CmonDev wrote: post #19
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…

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.

What the hell, why on earth would that be a good idea?

Re: Massive: The asm.js Benchmark

#22

Post by amelius »

TazeTSchnitzel wrote: post #18
amelius wrote: post #16

Earlier quoted context omitted.

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.

I guess the allocator would be able to manage blocks so you could view them as a single heap. At least, that's how I'd like to deal with memory as a "user". However, a "pointer" then has two parts: first, it should point to the block, and second it should have the index within that block. A stored pointer (a pointer stored within the heap) then would need 2 lookups for a dereference (first, determine the block-number, look up the block from a small array, and then lookup the index within that block). This sounds a little convoluted to me. Shouldn't there be a simpler and more efficient way to deal with growing memory?

Re: Massive: The asm.js Benchmark

#23

Post by blibble »

TazeTSchnitzel wrote: post #17
pjmlp wrote: post #14

Earlier quoted context omitted.

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

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

I don't really understand how asm.js is any different...

you've still got applications compiled into binary blob, the difference between NaCl and asm.js being that asm.js just happens to be binary encoded as executable JavaScript.

Re: Massive: The asm.js Benchmark

#24

Post by sunfish »

TazeTSchnitzel wrote: post #18
amelius wrote: post #16

Earlier quoted context omitted.

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.

asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1].

[0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

Re: Massive: The asm.js Benchmark

#25

Post by StevePerkins »

I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript.

All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely works to improve JavaScript without another agenda.

Re: Massive: The asm.js Benchmark

#26

Post by amelius »

sunfish wrote: post #24
TazeTSchnitzel wrote: post #18

Earlier quoted context omitted.

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.

asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1]. [0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

What I'm wondering is what a pointer-dereference would look like. Is every pointer dereference in asm.js implemented by TWO dereferences (one to find the heap, and then one to find the index within the heap)? And are there mutexes (or other synchronization directives) used per dereference in a typical implementation?

Re: Massive: The asm.js Benchmark

#27

Post by TazeTSchnitzel »

blibble wrote: post #23
TazeTSchnitzel wrote: post #17

Earlier quoted context omitted.

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

I don't really understand how asm.js is any different... you've still got applications compiled into binary blob, the difference between NaCl and asm.js being that asm.js just happens to be binary encoded as executable JavaScript.

asm.js isn't a binary blob, it's JavaScript. It's not a threat to a web of open standards.

Re: Massive: The asm.js Benchmark

#28

Post by leoc »

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…

> asm.js has several strengths over NaCl and even PNaCl

Why should we have to choose one or the other? Content negotiation is your friend.

Of that liast, I think only 1 and maybe 4 are real strengths.

Strength 1 means that old browsers or browsers from uncooperative vendors can still run applications at some level of performance (which might or might not be a usable level). Probably more important, tbh, is that it alters users' perceptions of who is to blame for poor support. It seems that when a site runs fast on browser A but slowly on browser B the user tends to blame browser B, but when a site runs fast on browser A but not at all on browser B the user tends to blame the site owner. When users correctly allocate blame to uncooperative browser vendors this provides the impetus for browser vendors to reform their ways and/or for users to switch browsers.

As to point 2, the fact that asm.js means that authors and tools don't have to target a new runtime language is a pretty mixed blessing, because perforce it means that they have to continue targeting the old one, which is JS. When did "here, compile to a subset of this old high-level scripting language and we'll try to get the performance back using the latest in JIT and specialisation" become a reasonable candidate for a portable assembler system? Like a dog walking on its hind legs, it's impressive that asm.js works as well as it does, but that doesn't actually make it a reasonable approach. It only makes technical sense as part of a heroic effort to provide backwards-compatibility with JS-only browsers (see strength 1).

A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl/PNaCl? It seems that there's simply been no external effort to standardise it or interest in standardising it. Since "Web standards" are, to a good first approximation, a sock-puppet for the browser-vendor oligopoly this basically means that the other browser vendors have no desire for NaCl to become standardised. So I don't see how browser vendors telling us that NaCL is bad because Mr. Socky won't approve use of it is anything other than a childish deception. Let the other vendors make a serious, good-faith effort to standardise NaCL/PNaCl then we'll talk about lack of standardisation.

EDIT: additionally, notice how "it's a black box" has quietly disappeared from the list of the other browser vendors' complaints against NaCl? C or C++ pushed through LLVM then Emscripten and ground up into asm.js is surely just as opaque to the site users as the same C or C++ pushed through LLVM and emitted as a PNaCl or NaCl binary. But it's their black box, so that's OK.

Re: Massive: The asm.js Benchmark

#29

Post by azakai »

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?

Growing heaps are in progress,

http://discourse.specifiction.org/t/request-for-comments-swi...

(It's unclear how that would work with heaps shared between threads, but so are most issues regarding threads - still just fairly early experimentation there, last I heard.)

Re: Massive: The asm.js Benchmark

#30

Post by azakai »

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.

Chrome is currently slower, but the v8 team is working on a new optimizing compiler called TurboFan. There are indications in the source code that it detects asm.js code as a compiler hint of some form, hopefully this means it will eventually get quite fast on that type of content.
Post reply on HN