7 ms·

For everyone saying that the claim that asm.js runs everywhere is invalid, because only in browsers that implement the optimization will it be feasible, remembe

For everyone saying that the claim that asm.js runs everywhere is invalid, because only in browsers that implement the optimization will it be feasible, remember that most games are built to scale performance. On browsers that don't implement the asm.js optimizations, the game could feasibly turn off visual effects and scale down the game so that it runs, just not as pretty or realistic. There's a huge difference between "this game only runs in this one browser that implements this full VM" and "this games runs everywhere, but only with maximum graphics & physics in browsers that implement the asm.js optimizations".

niggler 14y ago
'There's a huge difference between "this game only runs in this one browser that implements this full VM" and "this games runs everywhere, but only with maximum graphics & physics in browsers that implement the asm.js optimizations".' That's quite a bit of marketing here. If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and it's not obvious to me within the confines of JS if you can actually do better than 1.5x), people would switch to a browser that supports NaCl (first the hardcore gamers, then the rest of us). Your argument only makes sense if asm.js and NaCl are at performance parity. Note that people still write native iOS games, even though they could run everywhere if they did it in JS.
- pcwalton 14y ago
  > If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and it's not obvious to me within the confines of JS if you can actually do better than 1.5x), people would switch to a browser that supports NaCl (first the hardcore gamers, then the rest of us). NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. > and it's not obvious to me within the confines of JS if you can actually do better than 1.5x Why not? Is there a technical reason?
  - niggler 14y ago
    Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. Even the modest 32-bit integer multiplication is tricky (you only have 52-53 bits of mantissa). Mozilla proposed `Math.imul` extension. goog.math.long provides a mechanism using an array, and emscripten does something similar (but can also use the hack if you are sure there won't be overflow issues)
    - pcwalton 14y ago
      > Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. No, in asm.js, numbers are not always floats. There is a type system that can classify numbers into integers. Native 64 bit integers are being worked on as an extension.
      - niggler 14y ago
        32 bit integers can be represented exactly in a Number but not 64 bit integers. And the typed array system provides Int32Array and Uint32Array but no 64-bit Downvoters: which part of the statement is factually incorrect? Read the ES3 and ES5 specs
        pcwalton 14y ago
        Implementing 64-bit integers on top of JavaScript is going to happen. It's far less effort to implement 64-bit integers than to adopt Native Client, and JavaScript needs 64-bit ints anyway—the Node community has been asking for it for a long time, for example.
    - jlongster 14y ago
      Just like pcwalton said, you can trick js engines to do real 32-bit arithmetic. (x|0 + y|0)|0 tells the engine that it's 32-bits all the way through, and it optimizes it appropriately and never touches floats. 64-bits is a problem, yes, but again like pcwalton said, it is being worked on for post ES6 era. Obviously, if the Unreal Engine is working, it's not necessarily critical & a show-stopper, but it is needed for certain things. Edit: Math.imul is needed because the number can become large enough to where the engine converts it to a double, and then converts it back and you lose precision (I think that's how it works). It's the only arithmetic that needs fixing.
  - mtgx 14y ago
    Curious, is the performance of PNacl much worse than regular NaCl? I actually like NaCl, but asm.js sounds like a more suited option in the long term, since the other browsers are probably much less likely to adopt NaCl anyway, unless they are going to develop similar sandbox technology as Google, which I think is pretty unlikely right now. So because of that I see the others adopting asm.js much faster than NaCl.
  - pifflesnort 14y ago
    > NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON, SSE, and other architecture-specific hardware features that make substantial differences in performance. So why shouldn't you compare NaCL to asm.js? PNaCL is there to cover the case where we move past ARM and x86, in which case it provides the ability to target new architectures from existing deployed code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries, optimized for a given client.
    - hosay123 14y ago
      We've already moved past ARM and x86: there's a bunch of MIPS Android tablets and phones on the market (just not in the West), and MIPS is extremely popular in home appliances (e.g. most LCD TVs). But this is besides the point. The real question is what the web will look like even 10 years from now, with a large installed base of arch-specific binaries everywhere. I don't want to have to explain to my kids why their browser requires the equivalent of a PDP11 emulator installed to watch certain classic movies and games.
      - pifflesnort 14y ago
        We haven't moved past ARM and x86. Those two cover almost the entire mobile/tablet/desktop market. If there's a real MIPS resurgence outside of WiFi routers (eg, extremely cheap/low-quality tablets), then they can use PNaCL just fine until a native NaCL target is implemented. However, given the market weight behind ARM and x86, this seems extraordinarily unlikely to be used outside of some extreme edge players. IIRC, MIPS support isn't even mainlined into Android.
        hosay123 14y ago
        Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures, one of which is a bitcode format that doesn't even run at native speeds, despite the name. I really love where this is going. [Edit] You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs, you have a totally separate offline manifest format that doesn't work like a regular web app, then you have 20 varieties of dumb formats pushed by a single company to advance its private for-profit agenda, when we already had all the vendor-neutral components openly specified, in place and deployed, that just needed some incremental improvement.
- hermanhermitage 14y ago
  NaCl gets >2x slowdown in some cases as the restrictions enforced by proof carrying code gets in the way (dynamic code generation, instruction set filtering). There are faster more efficient ways of isolating a process - and better provided at an OS level (see Xax for instance). PCC makes sense where you need to inline externally delivered code in a process - inline driver filters and so on.
  - BrendanEich 14y ago
    Right, NaCl early work had beautiful in-process SFI. But that went away soon, and it was OOP-isolated on top. I never got a straight story as to why. /be
- maksimlin 14y ago
  The reason people "write native iOS games" is that today, it the shortest and easiest path between them and $$$. But that is changing and may still be true tomorrow but maybe not next year.
magicalist 14y ago
Because it's still javascript, I'm not particularly worried; Unreal support will likely be a powerful incentive to improve performance on the smaller instruction set even if asm.js itself doesn't catch on. However, in many typical graphics-heavy cases, your statements aren't really true. Many of the heavy visual effects are offloaded to the GPU if at all possible (especially in the case of Unreal Engine's OpenGL ES path, as it has to rely on the speed of mobile CPUs otherwise), and data is preprocessed wherever possible so that it doesn't have to be done at runtime. This takes the CPU out of many of the bottlenecks where the difference between asm.js code and regular JITed js would make a large difference. If you're using Emscripten with typed arrays at all, you're going to get a huge reduction in GC pressure as well. You will be able to scale things like physics (since something like PhysX doesn't run on mobile GPUs anyway), but any gameplay-affecting physical interactions won't be relying on actual CPU-based physics simulation. In any case, Emscripten is a powerful tool even without asm.js, and I will bet that these demos will still run pretty well in browsers without it. Sufficient incentive (like, a popular WebGL game) would be enough to get framerates as rocksteady as what we're seeing in Firefox with support. The big news here is that Mozilla has convinced Epic to bet on the web (where they were previously throwing all their weight behind their Flash-based engine), and they've demonstrated with a major, non-trivial piece of software how easy the porting process can be. Moreover, because it's Mozilla, we know that they'll make sure that cross-browser support is baked in, so that if or when other browsers are fast enough to play these games, they'll be able to. Serious kudos to Mozilla for this win.
- jlongster 14y ago
  You're right that a lot of the scaling probably happens with the GPU, and that Emscripten-generated code is still the most performant javascript possible (no GC, consistently typed for inference, etc). I think there are places where the CPU is the bottleneck though, since we're talking about crazy complex 3d games. Managing a large scene graph, and updating physics are some examples. Simply reducing the viewable distance is a huge help when you are CPU bottlenecked for those reasons (most likely physics). Agreed that no matter what, the Unreal port will help optimize the typed array/no GC code path! Exciting times.

niggler 14y ago

'There's a huge difference between "this game only runs in this one browser that implements this full VM" and "this games runs everywhere, but only with maximum graphics & physics in browsers that implement the asm.js optimizations".' That's quite a bit of marketing here. If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and it's not obvious to me within the confines of JS if you can actually do better than 1.5x), people would switch to a browser that supports NaCl (first the hardcore gamers, then the rest of us). Your argument only makes sense if asm.js and NaCl are at performance parity. Note that people still write native iOS games, even though they could run everywhere if they did it in JS.

pcwalton 14y ago
> If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and it's not obvious to me within the confines of JS if you can actually do better than 1.5x), people would switch to a browser that supports NaCl (first the hardcore gamers, then the rest of us). NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. > and it's not obvious to me within the confines of JS if you can actually do better than 1.5x Why not? Is there a technical reason?
- niggler 14y ago
  Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. Even the modest 32-bit integer multiplication is tricky (you only have 52-53 bits of mantissa). Mozilla proposed `Math.imul` extension. goog.math.long provides a mechanism using an array, and emscripten does something similar (but can also use the hack if you are sure there won't be overflow issues)
  - pcwalton 14y ago
    > Numbers are IEEE754 floats and no currently accepted spec provides native 64 bit integers with arithmetic. No, in asm.js, numbers are not always floats. There is a type system that can classify numbers into integers. Native 64 bit integers are being worked on as an extension.
    - niggler 14y ago
      32 bit integers can be represented exactly in a Number but not 64 bit integers. And the typed array system provides Int32Array and Uint32Array but no 64-bit Downvoters: which part of the statement is factually incorrect? Read the ES3 and ES5 specs
      - pcwalton 14y ago
        Implementing 64-bit integers on top of JavaScript is going to happen. It's far less effort to implement 64-bit integers than to adopt Native Client, and JavaScript needs 64-bit ints anyway—the Node community has been asking for it for a long time, for example.
  - jlongster 14y ago
    Just like pcwalton said, you can trick js engines to do real 32-bit arithmetic. (x|0 + y|0)|0 tells the engine that it's 32-bits all the way through, and it optimizes it appropriately and never touches floats. 64-bits is a problem, yes, but again like pcwalton said, it is being worked on for post ES6 era. Obviously, if the Unreal Engine is working, it's not necessarily critical & a show-stopper, but it is needed for certain things. Edit: Math.imul is needed because the number can become large enough to where the engine converts it to a double, and then converts it back and you lose precision (I think that's how it works). It's the only arithmetic that needs fixing.
- mtgx 14y ago
  Curious, is the performance of PNacl much worse than regular NaCl? I actually like NaCl, but asm.js sounds like a more suited option in the long term, since the other browsers are probably much less likely to adopt NaCl anyway, unless they are going to develop similar sandbox technology as Google, which I think is pretty unlikely right now. So because of that I see the others adopting asm.js much faster than NaCl.
- pifflesnort 14y ago
  > NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON, SSE, and other architecture-specific hardware features that make substantial differences in performance. So why shouldn't you compare NaCL to asm.js? PNaCL is there to cover the case where we move past ARM and x86, in which case it provides the ability to target new architectures from existing deployed code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries, optimized for a given client.
  - hosay123 14y ago
    We've already moved past ARM and x86: there's a bunch of MIPS Android tablets and phones on the market (just not in the West), and MIPS is extremely popular in home appliances (e.g. most LCD TVs). But this is besides the point. The real question is what the web will look like even 10 years from now, with a large installed base of arch-specific binaries everywhere. I don't want to have to explain to my kids why their browser requires the equivalent of a PDP11 emulator installed to watch certain classic movies and games.
    - pifflesnort 14y ago
      We haven't moved past ARM and x86. Those two cover almost the entire mobile/tablet/desktop market. If there's a real MIPS resurgence outside of WiFi routers (eg, extremely cheap/low-quality tablets), then they can use PNaCL just fine until a native NaCL target is implemented. However, given the market weight behind ARM and x86, this seems extraordinarily unlikely to be used outside of some extreme edge players. IIRC, MIPS support isn't even mainlined into Android.
      - hosay123 14y ago
        Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures, one of which is a bitcode format that doesn't even run at native speeds, despite the name. I really love where this is going. [Edit] You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs, you have a totally separate offline manifest format that doesn't work like a regular web app, then you have 20 varieties of dumb formats pushed by a single company to advance its private for-profit agenda, when we already had all the vendor-neutral components openly specified, in place and deployed, that just needed some incremental improvement.
hermanhermitage 14y ago
NaCl gets >2x slowdown in some cases as the restrictions enforced by proof carrying code gets in the way (dynamic code generation, instruction set filtering). There are faster more efficient ways of isolating a process - and better provided at an OS level (see Xax for instance). PCC makes sense where you need to inline externally delivered code in a process - inline driver filters and so on.
- BrendanEich 14y ago
  Right, NaCl early work had beautiful in-process SFI. But that went away soon, and it was OOP-isolated on top. I never got a straight story as to why. /be
maksimlin 14y ago
The reason people "write native iOS games" is that today, it the shortest and easiest path between them and $$$. But that is changing and may still be true tomorrow but maybe not next year.

magicalist 14y ago

Because it's still javascript, I'm not particularly worried; Unreal support will likely be a powerful incentive to improve performance on the smaller instruction set even if asm.js itself doesn't catch on. However, in many typical graphics-heavy cases, your statements aren't really true. Many of the heavy visual effects are offloaded to the GPU if at all possible (especially in the case of Unreal Engine's OpenGL ES path, as it has to rely on the speed of mobile CPUs otherwise), and data is preprocessed wherever possible so that it doesn't have to be done at runtime. This takes the CPU out of many of the bottlenecks where the difference between asm.js code and regular JITed js would make a large difference. If you're using Emscripten with typed arrays at all, you're going to get a huge reduction in GC pressure as well. You will be able to scale things like physics (since something like PhysX doesn't run on mobile GPUs anyway), but any gameplay-affecting physical interactions won't be relying on actual CPU-based physics simulation. In any case, Emscripten is a powerful tool even without asm.js, and I will bet that these demos will still run pretty well in browsers without it. Sufficient incentive (like, a popular WebGL game) would be enough to get framerates as rocksteady as what we're seeing in Firefox with support. The big news here is that Mozilla has convinced Epic to bet on the web (where they were previously throwing all their weight behind their Flash-based engine), and they've demonstrated with a major, non-trivial piece of software how easy the porting process can be. Moreover, because it's Mozilla, we know that they'll make sure that cross-browser support is baked in, so that if or when other browsers are fast enough to play these games, they'll be able to. Serious kudos to Mozilla for this win.

jlongster 14y ago
You're right that a lot of the scaling probably happens with the GPU, and that Emscripten-generated code is still the most performant javascript possible (no GC, consistently typed for inference, etc). I think there are places where the CPU is the bottleneck though, since we're talking about crazy complex 3d games. Managing a large scene graph, and updating physics are some examples. Simply reducing the viewable distance is a huge help when you are CPU bottlenecked for those reasons (most likely physics). Agreed that no matter what, the Unreal port will help optimize the typed array/no GC code path! Exciting times.