6 ms·

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 citiz

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 a serious chance on Windows laptops because of all the legacy x86 programs, but at worst it should be equal with x86 running an OS such as Chrome OS.

TazeTSchnitzel 12y ago
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 single implementation * It can interface with existing JavaScript code, so it can use JS libraries and, similarly, JS code can use asm.js libraries * It is a completely open standard * It is architecture-independent (so's PNaCl, though)
- masklinn 12y ago
  > 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.js adds at least two functions to the Math namespace (imul and fround)
  - TazeTSchnitzel 12y ago
    > 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).
- amelius 12y ago
  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.)
  - TazeTSchnitzel 12y ago
    > 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 https://bugzilla.mozilla.org/show_bug.cgi?id=933001
    - amelius 12y ago
      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?
      - TazeTSchnitzel 12y ago
        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.
- CmonDev 12y ago
  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.
  - TazeTSchnitzel 12y ago
    What the hell, why on earth would that be a good idea?
- leoc 12y ago
  > 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.
  - TazeTSchnitzel 12y ago
- saosebastiao 12y ago
  > 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 I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');? Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.
  - TazeTSchnitzel 12y ago
    > I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to anything else, except NaCl I suppose (though that requires more porting effort). I don't get what you mean by "going through the trouble of compiling their application to asm.js" versus ""normal" javascript wasn't good enough for them.". Why would they compile to normal JS? There's no reason to: Their codebase is in C, C++, or some other native code language. If they compile to asm.js, they get a free performance boost. If they compile to JS, they just get horrible slowness. The only difference between them, here, is a single compiler flag. I don't understand. > Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');? Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists? > Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js. > I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript. It's not a VM, there's no JIT involved.
pjmlp 12y ago
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.

TazeTSchnitzel 12y ago

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 single implementation * It can interface with existing JavaScript code, so it can use JS libraries and, similarly, JS code can use asm.js libraries * It is a completely open standard * It is architecture-independent (so's PNaCl, though)

masklinn 12y ago
> 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.js adds at least two functions to the Math namespace (imul and fround)
- TazeTSchnitzel 12y ago
  > 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).
amelius 12y ago
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.)
- TazeTSchnitzel 12y ago
  > 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 https://bugzilla.mozilla.org/show_bug.cgi?id=933001
  - amelius 12y ago
    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?
    - TazeTSchnitzel 12y ago
      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.
CmonDev 12y ago
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.
- TazeTSchnitzel 12y ago
  What the hell, why on earth would that be a good idea?
leoc 12y ago
> 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.
- TazeTSchnitzel 12y ago
saosebastiao 12y ago
> 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 I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');? Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.
- TazeTSchnitzel 12y ago
  > I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to anything else, except NaCl I suppose (though that requires more porting effort). I don't get what you mean by "going through the trouble of compiling their application to asm.js" versus ""normal" javascript wasn't good enough for them.". Why would they compile to normal JS? There's no reason to: Their codebase is in C, C++, or some other native code language. If they compile to asm.js, they get a free performance boost. If they compile to JS, they just get horrible slowness. The only difference between them, here, is a single compiler flag. I don't understand. > Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');? Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists? > Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js. > I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript. It's not a VM, there's no JIT involved.

pjmlp 12y ago

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.