7 ms·

I fear the limitation that it has to be a subset of JS must lead to performance trade-offs, through the lack of 64-bit integer types or single precision floatin

• pcwalton 13y ago
  This is not a fundamental limitation of asm.js. For example, there is already an extension introduced for compiled code that can be optionally used for improved performance: Math.imul. Similar extensions can be introduced later.
  • capisce 13y ago
    With the trade off that the code size is greatly increased and that the performance when falling back to pure JavaScript will be dog slow. If the performance of an application is only acceptable on the subset of browsers that implement asm.js then the portability advantage over PNaCL isn't worth that much.
    • surrealize 13y ago
      The only actual numbers I've seen, from emscripten author Alon Zakai, show gzipped minified emscripten JS output as comparable in size to gzipped native code: http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling...
    • pcwalton 13y ago
      > With the trade off that the code size is greatly increased http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... > If the performance of an application is only acceptable on the subset of browsers that implement asm.js then the portability advantage over PNaCL isn't worth that much. The Unreal Engine demo has proven that, even for games, these limitations don't result in "dog slow" performance on browsers that don't support asm.js.
      • capisce 13y ago
        The Unreal Engine demo does pretty much all of its work on the GPU.