10 ms·

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

by dicroce 11y ago

ianetaylor 11y ago
To be fair to google they are supporting asm.js, just with a different implementation design. Native Client is orthogonal.
teacup50 11y ago
Why? asm.js is a hack relative to NaCL.
- acdha 11y ago
  There's no need to be disparaging – NaCL is more ambitious but asm.js has a backwards compatibility path. Both are valid engineering decisions, particularly since it's really easy to imagine a world where if NaCL delivers some major benefits the same toolchain could generate both for a seamless upgrade.
  - detrino 11y ago
    IOW, sometimes a hack can be a valid engineering decision.
- flohofwoe 11y ago
  In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ http://floooh.github.io/oryol/). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only real difference is whether a pthreads-style threading model is supported or not (PNaCl does, asm.js does not, but work is underway at Mozilla to implement a true pthreads-style model via SharedArrayBuffer).
  - TazeTSchnitzel 11y ago
    There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not using x86-64 or ARM, too bad! And PNaCl uses LLVM, so there's only one implementation. Compare this to asm.js. It's a strict subset of ECMAScript/JavaScript, which has several high-quality implementations, and is portable across platforms. It uses the existing standard web APIs, which also have several high-quality implementations.
    - flohofwoe 11y ago
      Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code, at least for WebGL, the performance behaviour on Chrome between WebGL and Pepper's GL wrapper is basically identical, and most other exposed API features are so similar to their HTML5 counterparts that it is almost certain that there's the same code underneath.
      - TazeTSchnitzel 11y ago
        > Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.
        dman 11y ago
        Do you think Google could be persuaded to contribute PNaCL as an open standard?
        dragonwriter 11y ago
        Judging from their FAQ [0] on it, it doesn't seem like they are generally opposed to the idea, just see it as premature at this time. [0] https://developer.chrome.com/native-client/faq https://developer.chrome.com/native-client/faq
- ndesaulniers 11y ago
  This kind of remark is getting pretty childish. On some level, all technology is black magic or "hacks". With a little bit of understanding, you learn all "hacks" are petty card tricks.
- cpeterso 11y ago
  Does NaCl have any advantage over asm.js other than implementation aesthetics?
  - pjspycha 11y ago
    Isn't concurrency and parallelism the big ones?
nothrabannosir 11y ago
Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.
- bmurphy1976 11y ago
  That's cool that they are trying, but what's the opportunity cost of not doing it? How much effort would it be to simply optimize asm.js now and then undo the optimization later when the core JIT gets smarter? Seems to me THAT is the way to go, but this is not my area of expertise.
- jlongster 11y ago
  While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance.
  - nothrabannosir 11y ago
    asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with. EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.
WorldWideWayne 11y ago
I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.
- flohofwoe 11y ago
  On the other hand, for the first time in history, you have true "write once run everywhere". I can take my native C/C++ GL demos that normally run on the desktop, compile them to asm.js, distribute them via a simple URL, and users just click on a link and run the demo on every OS. No download and installation, no browser warnings about dangerous executables, no virus scanner scare popups. Compare this with iOS, where I need to be a certified Apple developer, need to sign my all my code, and can only distribute through the app store (and since it's only small graphics demos without real use, the gatekeepers would never let them through).
  - WaxProlix 11y ago
    Sounds like the sandbox-escaping game is going to get pretty intense in the coming years.
    - darkmighty 11y ago
      I don't think it will be all that hard from a security standpoint. This means mostly fixing the major mess that has been security at the OS level and isn't changing any time soon. We're not supposed to be giving any application all power they want. We just want to let them use the GPU and take inputs on focus, and if they misbehave we kill them. If they need anything else, they'll have to ask the user. It took Microsoft what, two decades? to realize this. And it's only sightly better now. The mobile OSes were the first to grasp this but it's still imperfect. Java almost got there but I believe it lost traction because of UI, lack of clear leadership and being tied to a language. We're going to have to go with browsers because although it's a big pile of hacks they are finally realizing the obvious (in hindsight) way we should develop most applications. I have no doubt it will continue to catch on.
flohofwoe 11y ago
I would really love to see Native Client on Android as alternative to the dreaded Android NDK, and I really don't understand why this hasn't already happened, it's so incredibly obvious. Just give us the ability to deploy and run a PNaCl executable directly as normal Android application, and without all the Java and JNI shenanigans. The Pepper API has a lot more to offer than what's exposed through the NDK headers, and the SDK itself is much easier to get up and running then the NDK.
- higherpurpose 11y ago
  Yeah, I'd like to see that, too. It might make supporting Go on Android easier, too. Even Rust could probably be used then for Android apps.
  - steveklabnik 11y ago
    We already test every PR against Android with Rust, but you can't use any of the native toolkit stuff afaik, it's the same as if you used C.
- pjmlp 11y ago
  I would just be happy if they offered the same as iOS and WP, access to OS APIs to all languages. However I bet the Android team only added the NDK forced by upper management, given how little care they give to it.
tracker1 11y ago
Google has done a number of optimizations that enhance asm.js performance while not specifically targeting asm.js. This results in real time performance that sometimes beats Firefox, which has asm.js built in. While I would like to see more effort to the areas of asm.js that are slow, I can't discount the Chrome/v8 team's approach.
- nnethercote 11y ago
  But the Chrome/V8 teams is still benefiting from the existence of asm.js, because the subset of JS that people can use and expect good performance from is now well-defined. Prior to asm.js this kind of certainty wasn't available for either JS engine developers or JS authors.
  - verbin217 11y ago
    I'm not sure I understand the purpose of your comment. Google's optimizations can achieve asmjs-like performance outside the well-defined subset so it doesn't necessarily benefit Google. If compile-to-js language authors target the subset ubiquitously and exclusively it may actually hurt Google.
- bad_user 11y ago
  > This results in real time performance that sometimes beats Firefox While Chrome's results have been impressive, in my experience Firefox does much better for Asm.js code - at least for the games I've been playing. So what benchmarks have you seen? Also, Google not getting involved in asm.js to make it better, but developing and promoting PNaCL and Dart, well that to me just smells like Microsoft's lock-in tactics with IExplorer in the nineties.
Siecje 11y ago
What does Google need to do to support asm.js? I thought asm.js is a subset of JavaScript so shouldn't it already be supported?
- sp332 11y ago
  It runs, but running in the normal JS engine is slow. If code validates as asm.js code, you can compile it with fewer checks and no garbage collection, so that it would run a lot faster. https://en.wikipedia.org/wiki/Asm.js#Performance https://en.wikipedia.org/wiki/Asm.js#Performance Chrome already provides some speedup on asm.js code https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/
- RussianCow 11y ago
  By "support", I think the parent means "optimize". Chrome does not do the same kinds of optimizations for asm.js that Firefox does.
drawkbox 11y ago
asm.js support in Chrome was moved to "assigned" in February this year: https://code.google.com/p/v8/issues/detail?id=2599 https://code.google.com/p/v8/issues/detail?id=2599 Looks to be the year of WebGL + asm.js across all browsers sometime this year. If so next year could be big for WebGL and web gaming again. And one day it could also make an impact on mobile but that seems to be moving ahead with things like Apple Metal and Khronos Vulkan (OpenGL successor - https://www.khronos.org/vulkan https://www.khronos.org/vulkan).
JoshTriplett 11y ago
While I'd like to see asm.js implemented for compatibility, I greatly prefer native code over compiling to a JavaScript subset in the hopes of getting something vaguely resembling the original code back. I understand why other browsers don't implement the Pepper API, because it's highly Chrome-specific; however, I'd like to see other browsers implementing the native-code sandbox, at least.
- vesinisa 11y ago
  Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations). Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted, versioned APIs coordinated by large, possibly competing and mutually incompatible engineering efforts. The asm.js spec is actually so simple it fits on a single web page: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ Yet it pretty much manages to achieve all that NaCl does by being also forwards-compatible with all the DOM-based extensions like HTML5 without needing any additional APIs (many asm.js demos for example bind to WebGL - this does not require any additional "asm.js API", as the browser's existing WebGL implementation suffices)
  - JoshTriplett 11y ago
    As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper. > Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them. asm.js involves compiling native code to JavaScript in the hopes that browsers will translate it back to some semblance of the same native code.
    - vesinisa 11y ago

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

by dicroce 11y ago

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

To be fair to google they are supporting asm.js, just with a different implementation design. Native Client is orthogonal.

teacup50 11y ago

Why? asm.js is a hack relative to NaCL.

acdha 11y ago
There's no need to be disparaging – NaCL is more ambitious but asm.js has a backwards compatibility path. Both are valid engineering decisions, particularly since it's really easy to imagine a world where if NaCL delivers some major benefits the same toolchain could generate both for a seamless upgrade.
- detrino 11y ago
  IOW, sometimes a hack can be a valid engineering decision.
flohofwoe 11y ago
In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ http://floooh.github.io/oryol/). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only real difference is whether a pthreads-style threading model is supported or not (PNaCl does, asm.js does not, but work is underway at Mozilla to implement a true pthreads-style model via SharedArrayBuffer).
- TazeTSchnitzel 11y ago
  There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not using x86-64 or ARM, too bad! And PNaCl uses LLVM, so there's only one implementation. Compare this to asm.js. It's a strict subset of ECMAScript/JavaScript, which has several high-quality implementations, and is portable across platforms. It uses the existing standard web APIs, which also have several high-quality implementations.
  - flohofwoe 11y ago
    Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code, at least for WebGL, the performance behaviour on Chrome between WebGL and Pepper's GL wrapper is basically identical, and most other exposed API features are so similar to their HTML5 counterparts that it is almost certain that there's the same code underneath.
    - TazeTSchnitzel 11y ago
      > Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.
      - dman 11y ago
        Do you think Google could be persuaded to contribute PNaCL as an open standard?
        dragonwriter 11y ago
        Judging from their FAQ [0] on it, it doesn't seem like they are generally opposed to the idea, just see it as premature at this time. [0] https://developer.chrome.com/native-client/faq https://developer.chrome.com/native-client/faq
ndesaulniers 11y ago
This kind of remark is getting pretty childish. On some level, all technology is black magic or "hacks". With a little bit of understanding, you learn all "hacks" are petty card tricks.
cpeterso 11y ago
Does NaCl have any advantage over asm.js other than implementation aesthetics?
- pjspycha 11y ago
  Isn't concurrency and parallelism the big ones?

nothrabannosir 11y ago

Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.

bmurphy1976 11y ago
That's cool that they are trying, but what's the opportunity cost of not doing it? How much effort would it be to simply optimize asm.js now and then undo the optimization later when the core JIT gets smarter? Seems to me THAT is the way to go, but this is not my area of expertise.
jlongster 11y ago
While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance.
- nothrabannosir 11y ago
  asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with. EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.

WorldWideWayne 11y ago

I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.

flohofwoe 11y ago
On the other hand, for the first time in history, you have true "write once run everywhere". I can take my native C/C++ GL demos that normally run on the desktop, compile them to asm.js, distribute them via a simple URL, and users just click on a link and run the demo on every OS. No download and installation, no browser warnings about dangerous executables, no virus scanner scare popups. Compare this with iOS, where I need to be a certified Apple developer, need to sign my all my code, and can only distribute through the app store (and since it's only small graphics demos without real use, the gatekeepers would never let them through).
- WaxProlix 11y ago
  Sounds like the sandbox-escaping game is going to get pretty intense in the coming years.
  - darkmighty 11y ago
    I don't think it will be all that hard from a security standpoint. This means mostly fixing the major mess that has been security at the OS level and isn't changing any time soon. We're not supposed to be giving any application all power they want. We just want to let them use the GPU and take inputs on focus, and if they misbehave we kill them. If they need anything else, they'll have to ask the user. It took Microsoft what, two decades? to realize this. And it's only sightly better now. The mobile OSes were the first to grasp this but it's still imperfect. Java almost got there but I believe it lost traction because of UI, lack of clear leadership and being tied to a language. We're going to have to go with browsers because although it's a big pile of hacks they are finally realizing the obvious (in hindsight) way we should develop most applications. I have no doubt it will continue to catch on.

flohofwoe 11y ago

I would really love to see Native Client on Android as alternative to the dreaded Android NDK, and I really don't understand why this hasn't already happened, it's so incredibly obvious. Just give us the ability to deploy and run a PNaCl executable directly as normal Android application, and without all the Java and JNI shenanigans. The Pepper API has a lot more to offer than what's exposed through the NDK headers, and the SDK itself is much easier to get up and running then the NDK.

higherpurpose 11y ago
Yeah, I'd like to see that, too. It might make supporting Go on Android easier, too. Even Rust could probably be used then for Android apps.
- steveklabnik 11y ago
  We already test every PR against Android with Rust, but you can't use any of the native toolkit stuff afaik, it's the same as if you used C.
pjmlp 11y ago
I would just be happy if they offered the same as iOS and WP, access to OS APIs to all languages. However I bet the Android team only added the NDK forced by upper management, given how little care they give to it.

tracker1 11y ago

Google has done a number of optimizations that enhance asm.js performance while not specifically targeting asm.js. This results in real time performance that sometimes beats Firefox, which has asm.js built in. While I would like to see more effort to the areas of asm.js that are slow, I can't discount the Chrome/v8 team's approach.

nnethercote 11y ago
But the Chrome/V8 teams is still benefiting from the existence of asm.js, because the subset of JS that people can use and expect good performance from is now well-defined. Prior to asm.js this kind of certainty wasn't available for either JS engine developers or JS authors.
- verbin217 11y ago
  I'm not sure I understand the purpose of your comment. Google's optimizations can achieve asmjs-like performance outside the well-defined subset so it doesn't necessarily benefit Google. If compile-to-js language authors target the subset ubiquitously and exclusively it may actually hurt Google.
bad_user 11y ago
> This results in real time performance that sometimes beats Firefox While Chrome's results have been impressive, in my experience Firefox does much better for Asm.js code - at least for the games I've been playing. So what benchmarks have you seen? Also, Google not getting involved in asm.js to make it better, but developing and promoting PNaCL and Dart, well that to me just smells like Microsoft's lock-in tactics with IExplorer in the nineties.

Siecje 11y ago

What does Google need to do to support asm.js? I thought asm.js is a subset of JavaScript so shouldn't it already be supported?

sp332 11y ago
It runs, but running in the normal JS engine is slow. If code validates as asm.js code, you can compile it with fewer checks and no garbage collection, so that it would run a lot faster. https://en.wikipedia.org/wiki/Asm.js#Performance https://en.wikipedia.org/wiki/Asm.js#Performance Chrome already provides some speedup on asm.js code https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/
RussianCow 11y ago
By "support", I think the parent means "optimize". Chrome does not do the same kinds of optimizations for asm.js that Firefox does.

drawkbox 11y ago

asm.js support in Chrome was moved to "assigned" in February this year: https://code.google.com/p/v8/issues/detail?id=2599 https://code.google.com/p/v8/issues/detail?id=2599 Looks to be the year of WebGL + asm.js across all browsers sometime this year. If so next year could be big for WebGL and web gaming again. And one day it could also make an impact on mobile but that seems to be moving ahead with things like Apple Metal and Khronos Vulkan (OpenGL successor - https://www.khronos.org/vulkan https://www.khronos.org/vulkan).

JoshTriplett 11y ago

While I'd like to see asm.js implemented for compatibility, I greatly prefer native code over compiling to a JavaScript subset in the hopes of getting something vaguely resembling the original code back. I understand why other browsers don't implement the Pepper API, because it's highly Chrome-specific; however, I'd like to see other browsers implementing the native-code sandbox, at least.

vesinisa 11y ago
Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations). Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted, versioned APIs coordinated by large, possibly competing and mutually incompatible engineering efforts. The asm.js spec is actually so simple it fits on a single web page: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ Yet it pretty much manages to achieve all that NaCl does by being also forwards-compatible with all the DOM-based extensions like HTML5 without needing any additional APIs (many asm.js demos for example bind to WebGL - this does not require any additional "asm.js API", as the browser's existing WebGL implementation suffices)
- JoshTriplett 11y ago
  As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper. > Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them. asm.js involves compiling native code to JavaScript in the hopes that browsers will translate it back to some semblance of the same native code.
  - vesinisa 11y ago