3 ms·

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

by 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
> Why should we have to choose one or the other? Content negotiation is your friend. You don't have to choose one or the other. I'm comparing technical merits. > 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). It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. > 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. I said runtime/API, not "runtime language". I'm referring to the DOM and other Web APIs here, vs. Chrome's Pepper. It means browsers don't need yet another set of APIs, and you get access to all the benefits of the existing set of APIs. OK, you might not find the high-level DOM and the Web APIs that nice, but you get OpenGL ES and direct blitting, raw audio, raw controller input, and so on as well. > 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? I don't see how the syntax really matters. asm.js is essentially a well-supported portable bytecode. The fact it happens to be a subset of JavaScript doesn't make it bad. > 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). I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you? > A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl/PNaCl? Not to my knowledge. However, NaCl implements a new set of vendor-specific APIs (Pepper) and relies on single, specific implementations (LLVM, Pepper), making it difficult, if not impossible, for other browser vendors to implement it. You can't really standardise PNaCl for the same reason you could't reasonably standardise WebSQL.
- leoc 12y ago
  > It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. > I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you? Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases. If you're telling me that asm.js now consistently runs at roughly-as-good-as-native-code speeds across the board, then that is surprising but great news. It certainly didn't seem to be the case three years ago, when we were assured that it was impossible to efficiently implement bignums in code compiled to JS, but I suppose things have been moving quickly in this area. Unfortunately OP doesn't seem to fully support that idea, as it seems to imply that IonMonkey requires significant processor time to make the JS run fast. (Shuffling that overhead off to another thread may effectively remove the performance burden when running single-threaded code on a machine which has two or more idle cores and is plugged into the wall, but it comes back in other cases, including the case where several tabs are all running asm.js programs at the same time.)

by leoc 12y ago

TazeTSchnitzel 12y ago

> Why should we have to choose one or the other? Content negotiation is your friend. You don't have to choose one or the other. I'm comparing technical merits. > 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). It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. > 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. I said runtime/API, not "runtime language". I'm referring to the DOM and other Web APIs here, vs. Chrome's Pepper. It means browsers don't need yet another set of APIs, and you get access to all the benefits of the existing set of APIs. OK, you might not find the high-level DOM and the Web APIs that nice, but you get OpenGL ES and direct blitting, raw audio, raw controller input, and so on as well. > 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? I don't see how the syntax really matters. asm.js is essentially a well-supported portable bytecode. The fact it happens to be a subset of JavaScript doesn't make it bad. > 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). I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you? > A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl/PNaCl? Not to my knowledge. However, NaCl implements a new set of vendor-specific APIs (Pepper) and relies on single, specific implementations (LLVM, Pepper), making it difficult, if not impossible, for other browser vendors to implement it. You can't really standardise PNaCl for the same reason you could't reasonably standardise WebSQL.

leoc 12y ago
> It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. > I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you? Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases. If you're telling me that asm.js now consistently runs at roughly-as-good-as-native-code speeds across the board, then that is surprising but great news. It certainly didn't seem to be the case three years ago, when we were assured that it was impossible to efficiently implement bignums in code compiled to JS, but I suppose things have been moving quickly in this area. Unfortunately OP doesn't seem to fully support that idea, as it seems to imply that IonMonkey requires significant processor time to make the JS run fast. (Shuffling that overhead off to another thread may effectively remove the performance burden when running single-threaded code on a machine which has two or more idle cores and is plugged into the wall, but it comes back in other cases, including the case where several tabs are all running asm.js programs at the same time.)