4 ms·

What matters to me as a developer is this: will there be more compilers targeting PNaCl, or asm.js? Otherwise said, as a compiler writer, would you rather wri

What matters to me as a developer is this: will there be more compilers targeting PNaCl, or asm.js? Otherwise said, as a compiler writer, would you rather write a compiler that works in all browsers, and which needs no tools because of how simple the output is, or a compiler which targets just one browser, with a complex output to target?

cromwellian 13y ago
If you are a game developer, it doesn't much matter. Do you target a market of 500+ million Chrome users, or 2 billion web users, or 900 million Android users, or 500 million iOS users? You can write a game with fragmented performance, cross your fingers and hope it runs everywhere and try to hit the largest market possible, or, you can develop for a more predictable platform, target a smaller market, but potentially gain more revenue with less development cost. The idea that someone is going to just cross compile to asm.js and poof, the game will work everywhere is a pipe dream. This attitude is likely to draw public ire and bad reviews as people who happen to have VMs which won't optimize it as good as Firefox, get unpredictably bad performance. It's Android fragmentation made even worse. The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to maintain and certify four different versions in order to get best experience. Not much different than trying to target a PS3, XB360, and Wii with a multiplatform title. If you look at modern game platforms, both on mobile, and on console/desktop, they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's evaluation of asm.js (http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native...) lack of SIMD and multi-threading is a huge performance hit. SIMD can be fixed (e.g. what Dart did), but shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening. In short, it's a nice dream that you can write once and run everywhere high performance JS, the reality is, it isn't going to help major game developers and they will still need per-browser, per-platform extensive testing and tuning. End users don't care. When I buy a game from a store, I expect it to run at 30fps with no janks minimally. This is one reason why iOS and consoles extract great performance from platforms that have lower specs than competitors, because a fixed target offers more opportunities for optimization. I love the idea of write once run anywhere, but I think it's the wrong model for high performance cpu hungry games where you want to maximize overall system performance.
- kibwen 13y ago
  I agree with your assessment that "write once, run anywhere" will always be beholden to the lowest common denominator when it comes to games that try to push the limits of performance. However, with regard to your statement "shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening", it isn't entirely hopeless. Intel's Rivertrail[1] and Mozilla's Parallel JS[2][3] efforts might not pan out as well as they expect, but at no point has either entity thrown up its hands and declared the situation as impossible as you imply. [1] https://github.com/RiverTrail/RiverTrail/wiki https://github.com/RiverTrail/RiverTrail/wiki [2] http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-javascript/ http://smallcultfollowing.com/babysteps/blog/2012/01/09/para... [3] http://smallcultfollowing.com/babysteps/blog/categories/pjs/ http://smallcultfollowing.com/babysteps/blog/categories/pjs/
  - cromwellian 13y ago
    RiverTrail, like OpenCL is cool, but not every algorithm is amenable to these models.
- neeee 13y ago
  Support for asm.js in Chrom{e,ium} was announced at Google I/O, though.
- azakai 13y ago
  I agree that write once run anywhere is never quite so simple, but > The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox is an oversimplification as well. Many asm.js codebases already run well on Chrome, and that will continue to improve, for the same reasons that all browsers are now fast at SunSpider, Octane, Kraken, etc. But again, sure, if you need full performance everywhere, you may need to target multiple platforms and not just one. Some games might need to do that, but not all.
  - cromwellian 13y ago
    I agree for many casual Flash-like games it won't matter. But if you're shipping Call of Duty or Half Life 3, you really can't avoid treating the browser on a platform specific basis.

cromwellian 13y ago

If you are a game developer, it doesn't much matter. Do you target a market of 500+ million Chrome users, or 2 billion web users, or 900 million Android users, or 500 million iOS users? You can write a game with fragmented performance, cross your fingers and hope it runs everywhere and try to hit the largest market possible, or, you can develop for a more predictable platform, target a smaller market, but potentially gain more revenue with less development cost. The idea that someone is going to just cross compile to asm.js and poof, the game will work everywhere is a pipe dream. This attitude is likely to draw public ire and bad reviews as people who happen to have VMs which won't optimize it as good as Firefox, get unpredictably bad performance. It's Android fragmentation made even worse. The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to maintain and certify four different versions in order to get best experience. Not much different than trying to target a PS3, XB360, and Wii with a multiplatform title. If you look at modern game platforms, both on mobile, and on console/desktop, they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's evaluation of asm.js (http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native...) lack of SIMD and multi-threading is a huge performance hit. SIMD can be fixed (e.g. what Dart did), but shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening. In short, it's a nice dream that you can write once and run everywhere high performance JS, the reality is, it isn't going to help major game developers and they will still need per-browser, per-platform extensive testing and tuning. End users don't care. When I buy a game from a store, I expect it to run at 30fps with no janks minimally. This is one reason why iOS and consoles extract great performance from platforms that have lower specs than competitors, because a fixed target offers more opportunities for optimization. I love the idea of write once run anywhere, but I think it's the wrong model for high performance cpu hungry games where you want to maximize overall system performance.

kibwen 13y ago
I agree with your assessment that "write once, run anywhere" will always be beholden to the lowest common denominator when it comes to games that try to push the limits of performance. However, with regard to your statement "shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening", it isn't entirely hopeless. Intel's Rivertrail[1] and Mozilla's Parallel JS[2][3] efforts might not pan out as well as they expect, but at no point has either entity thrown up its hands and declared the situation as impossible as you imply. [1] https://github.com/RiverTrail/RiverTrail/wiki https://github.com/RiverTrail/RiverTrail/wiki [2] http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-javascript/ http://smallcultfollowing.com/babysteps/blog/2012/01/09/para... [3] http://smallcultfollowing.com/babysteps/blog/categories/pjs/ http://smallcultfollowing.com/babysteps/blog/categories/pjs/
- cromwellian 13y ago
  RiverTrail, like OpenCL is cool, but not every algorithm is amenable to these models.
neeee 13y ago
Support for asm.js in Chrom{e,ium} was announced at Google I/O, though.
azakai 13y ago
I agree that write once run anywhere is never quite so simple, but > The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox is an oversimplification as well. Many asm.js codebases already run well on Chrome, and that will continue to improve, for the same reasons that all browsers are now fast at SunSpider, Octane, Kraken, etc. But again, sure, if you need full performance everywhere, you may need to target multiple platforms and not just one. Some games might need to do that, but not all.
- cromwellian 13y ago
  I agree for many casual Flash-like games it won't matter. But if you're shipping Call of Duty or Half Life 3, you really can't avoid treating the browser on a platform specific basis.