6 ms·

'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

by 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.
    - niggler 14y ago
      "(x|0 + y|0)|0 tells the engine that it's 32-bits all the way through" You conveniently skipped the complaint: "Even the modest 32-bit integer multiplication is tricky (you only have 52-53 bits of mantissa)"
    - jlongster 14y ago
      @niggler I did at first but I added a quick edit after I posted. It's not a hard thing to fix.
      - niggler 14y ago
        "It's not a hard thing to fix." But then you get back into the game of asking browser vendors to make changes, which was one of the original selling points of asm.js (that browser vendors didn't have to make changes).
        jlongster 14y ago
        Sure, it's unfortunate, but it's one obscure edge case that they can implement instantly. They are still pushed to implement asm.js anyway, so that just comes with it. If they don't, things like BananaBread do still run, so it's not required, it's just an obscure edge case.
        BrendanEich 14y ago
- 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.

by niggler 14y ago

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.
  - niggler 14y ago
    "(x|0 + y|0)|0 tells the engine that it's 32-bits all the way through" You conveniently skipped the complaint: "Even the modest 32-bit integer multiplication is tricky (you only have 52-53 bits of mantissa)"
  - jlongster 14y ago
    @niggler I did at first but I added a quick edit after I posted. It's not a hard thing to fix.
    - niggler 14y ago
      "It's not a hard thing to fix." But then you get back into the game of asking browser vendors to make changes, which was one of the original selling points of asm.js (that browser vendors didn't have to make changes).
      - jlongster 14y ago
        Sure, it's unfortunate, but it's one obscure edge case that they can implement instantly. They are still pushed to implement asm.js anyway, so that just comes with it. If they don't, things like BananaBread do still run, so it's not required, it's just an obscure edge case.
      - BrendanEich 14y ago
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.