5 ms·

>I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some

>I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on As others have pointed out, Mozilla has been less than receptive when similar situations were reversed. I also know from working with the NaCl and PPAPI teams that they repeatedly reached out to Mozilla in an effort to publicly develop a mutually agreeable standard, but they were not well received. So, given past precedent, the way asm.js was introduced isn't necessarily bad, but it certainly feels a bit hypocritical. >> relies extensively on engine quirks >That would be a bad bug in the asm.js spec. Can you please elaborate? Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. It's certainly an ingenious way to get backwards compatibility while basically defining a new IR, but it is a bit... quirky. As I mentioned elsewhere, I think asm.js might really catch on. It could be the IR that finally becomes universal, in large part because your backwards compatibility strategy is so damn clever. That said, I also see a few obvious pain points that will need solutions: * Reasonable debugging support (maybe just a metadata standard morally equivalent to symbol files) * Threading (even just co-routines, it seems some behavior needs to be specified) * Load performance (validation and code caching seem needed, which are very tractable but just mean more work)

azakai 14y ago
> As others have pointed out, Mozilla has been less than receptive when similar situations were reversed. That's a long conversation, and I likely know nothing of the non-public aspects of it. From what I know of the public stuff, I don't think it is the same in reverse. I do see the general similarity you refer to, I just think there are some fundamental differences that explain the different responses. Happy to discuss this more if you want. > Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. I still don't know what you mean, can you please say what concretely in the spec you are referring to?
- justinschuh 14y ago
  >> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. >I still don't know what you mean, can you please say what concretely in the spec you are referring to? You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at. To make that performant you have to hack in things like manual memory management and use type coercions to game existing engine behavior. To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense. And I happily admit that type coercions and similar tricks are a very clever way to structure your IR while simultaneously maintaining compatibility and improving performance in existing JS engines. However, in doing so you're already relying heavily on unspecced implementation details of existing engines. So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved.
  - azakai 14y ago
    > You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at I agree it was not designed for it. However I a not sure what "inherently good at" means - after v8 showed up in 2008, for example, many types of code suddenly became very fast. Were they always inherently fast? > To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. I disagree. Firefox did pick that option because it seemed best, but I believe it is possible to achieve similar speeds with other approaches. As the slide here shows, http://kripken.github.com/mloc_emscripten_talk/#/27 http://kripken.github.com/mloc_emscripten_talk/#/27 on many benchmarks, even without any new optimizations modern JS engines are already fast on asm.js code. And with new optimizations, even without things you just mentioned, they should be able to get fast on the rest. I saw some activity on the v8 bug tracker indicating possible work in that direction, which I am very curious and hopeful about. > And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense. Yes, it is not intended to be - like the output of closure compiler, etc. Note though that emscripten can generate asm.js in debug mode, which is not minified, and actually quite readable - you can recognize function and variable names, for example. It looks a little quirky to be sure ;) but it is more readable than compiler IRs like LLVM for example, in my opinion (and certainly far more readable than x86 or ARM assembly). > However, in doing so you're already relying heavily on unspecced implementation details of existing engines. Performance is not specced at all for JavaScript. Again, when v8, nitro and tracemonkey came out in 2008-2009, many types of JS code suddenly got fast. There wasn't a spec for any of that. No one says modern JS engines should use int32 when a value never goes out of the int32 range, but all modern JS engines do that (in hot functions). > So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved. I fully agree it is a hack, and it has various pain points. It's a compromise, not a clean solution from scratch. I hope we can resolve many of those pain points in time, and that we can do that in collaboration with all browser vendors together.
fivealive 14y ago
> I also know from working with the NaCl and PPAPI teams that they repeatedly reached out to Mozilla in an effort to publicly develop a mutually agreeable standard, but they were not well received. They weren't well received I suppose because Pepper is a binary API that duplicates everything already in the browser. Why does PP have to be so large? Because with NaCl it's incredibly awkward to call javascript functions from native code, and vice versa. It's not webby.
- justinschuh 14y ago
  That would be a reasonable argument if Mozilla wasn't still adding extensions to NPAPI, a far less webby technology that's a much worse design and outright dangerous for end-users. And yes, NaCl has its awkwardness, but it's far better than NPAPI, and if you look a bit you'll realize that NaCl's awkwardness is specifically because it can support things that asm.js can't. NaCl has real native threads, clean debugging, and a simpler legacy code path, but the cost is the complexity of the implementation. The funny thing in all this is that I'm really not a proponent of NaCl. I find it technically very interesting, but I never considered architecture-specific NaCl viable for the Web, and there are still kinks to work out with PNaCl. I just find the attitude towards asm.js curious, because it carries so many of the past criticisms of NaCl (not human readable, initially developed in private, etc.).
  - fivealive 14y ago
    Why would Mozilla add extensions to NPAPI, for more advanced plugins that must be trusted or expensively sandboxed because they are normally compiled? Mozilla is doing everything in the web, adding sound and graphic APIs to html not duplicating them for legacy native code. It doesn't even make sense for Google to do Pepper, let alone Mozilla. Real threads essentially mean that every call must copy all data or else another thread could modify the data while it is being used by trusted code, or all threads have to be suspended. That's clumsy and not a good solution.
    - cromwellian 14y ago
      Real threads also mean you get to maximize hardware resources. Modern game engines leverage multi-core.

azakai 14y ago

> As others have pointed out, Mozilla has been less than receptive when similar situations were reversed. That's a long conversation, and I likely know nothing of the non-public aspects of it. From what I know of the public stuff, I don't think it is the same in reverse. I do see the general similarity you refer to, I just think there are some fundamental differences that explain the different responses. Happy to discuss this more if you want. > Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. I still don't know what you mean, can you please say what concretely in the spec you are referring to?

justinschuh 14y ago
>> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. >I still don't know what you mean, can you please say what concretely in the spec you are referring to? You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at. To make that performant you have to hack in things like manual memory management and use type coercions to game existing engine behavior. To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense. And I happily admit that type coercions and similar tricks are a very clever way to structure your IR while simultaneously maintaining compatibility and improving performance in existing JS engines. However, in doing so you're already relying heavily on unspecced implementation details of existing engines. So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved.
- azakai 14y ago
  > You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at I agree it was not designed for it. However I a not sure what "inherently good at" means - after v8 showed up in 2008, for example, many types of code suddenly became very fast. Were they always inherently fast? > To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. I disagree. Firefox did pick that option because it seemed best, but I believe it is possible to achieve similar speeds with other approaches. As the slide here shows, http://kripken.github.com/mloc_emscripten_talk/#/27 http://kripken.github.com/mloc_emscripten_talk/#/27 on many benchmarks, even without any new optimizations modern JS engines are already fast on asm.js code. And with new optimizations, even without things you just mentioned, they should be able to get fast on the rest. I saw some activity on the v8 bug tracker indicating possible work in that direction, which I am very curious and hopeful about. > And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense. Yes, it is not intended to be - like the output of closure compiler, etc. Note though that emscripten can generate asm.js in debug mode, which is not minified, and actually quite readable - you can recognize function and variable names, for example. It looks a little quirky to be sure ;) but it is more readable than compiler IRs like LLVM for example, in my opinion (and certainly far more readable than x86 or ARM assembly). > However, in doing so you're already relying heavily on unspecced implementation details of existing engines. Performance is not specced at all for JavaScript. Again, when v8, nitro and tracemonkey came out in 2008-2009, many types of JS code suddenly got fast. There wasn't a spec for any of that. No one says modern JS engines should use int32 when a value never goes out of the int32 range, but all modern JS engines do that (in hot functions). > So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved. I fully agree it is a hack, and it has various pain points. It's a compromise, not a clean solution from scratch. I hope we can resolve many of those pain points in time, and that we can do that in collaboration with all browser vendors together.

fivealive 14y ago

> I also know from working with the NaCl and PPAPI teams that they repeatedly reached out to Mozilla in an effort to publicly develop a mutually agreeable standard, but they were not well received. They weren't well received I suppose because Pepper is a binary API that duplicates everything already in the browser. Why does PP have to be so large? Because with NaCl it's incredibly awkward to call javascript functions from native code, and vice versa. It's not webby.

justinschuh 14y ago
That would be a reasonable argument if Mozilla wasn't still adding extensions to NPAPI, a far less webby technology that's a much worse design and outright dangerous for end-users. And yes, NaCl has its awkwardness, but it's far better than NPAPI, and if you look a bit you'll realize that NaCl's awkwardness is specifically because it can support things that asm.js can't. NaCl has real native threads, clean debugging, and a simpler legacy code path, but the cost is the complexity of the implementation. The funny thing in all this is that I'm really not a proponent of NaCl. I find it technically very interesting, but I never considered architecture-specific NaCl viable for the Web, and there are still kinks to work out with PNaCl. I just find the attitude towards asm.js curious, because it carries so many of the past criticisms of NaCl (not human readable, initially developed in private, etc.).
- fivealive 14y ago
  Why would Mozilla add extensions to NPAPI, for more advanced plugins that must be trusted or expensively sandboxed because they are normally compiled? Mozilla is doing everything in the web, adding sound and graphic APIs to html not duplicating them for legacy native code. It doesn't even make sense for Google to do Pepper, let alone Mozilla. Real threads essentially mean that every call must copy all data or else another thread could modify the data while it is being used by trusted code, or all threads have to be suspended. That's clumsy and not a good solution.
  - cromwellian 14y ago
    Real threads also mean you get to maximize hardware resources. Modern game engines leverage multi-core.