8 ms·

From what I understand writing fast javascript is hard because the engines are improving so fast no one knows what is fast yet. Thus asm.js is a promise to deve

by Danieru 13y ago

From what I understand writing fast javascript is hard because the engines are improving so fast no one knows what is fast yet. Thus asm.js is a promise to developers: "Stay within the subset and your javascript will be fast". Yet it never was "use asm" which made asm.js fast. It was the js engine. "use asm" carries symantical knowledge so a browser can warn if you break out of the subset. It also serves as a strong hint that should make the optimizer's easier. This is why I think asm.js is the future. Mozila does not need buy in from Google, or Apple, or MS. Instead developers can compile to asm.js and their code will run, and in time it will run faster. So in effect Chrome supports arm.js but they are not making a promise. I think it would be better for the internet if they made this promise.

eliben 13y ago
> Stay within the subset and your javascript will be fast You do realize that asm.js was not designed to be written by hand, don't you? It's a target for compilers. There are no bounds "to stay within" for hand-written JS which is still the vast majority of the code out there.
- Danieru 13y ago
  I do, which is why I said developers may "compile" their program into asm.js Even still someone has to write that compiler and they want to know what will be fast. I do not see many people writing asm.js by hand beyond optimizing vital sections.
camus2 13y ago
> Mozila does not need buy in from Google, or Apple, or MS. So why Chrome should buy from Firefox? why should they follow the asm.js spec ? Maybe it i the wrong answer to a real problem, javascript speed and its memory foodprint.Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better.
- Danieru 13y ago
  A fair question. I think it has parallels to Intel's itanium vs AMD's x64. I cannot pretend to know what is best in a perfect world. Yet I am willing to pretend to know what is the more practical way forward. Native Client is and was an interesting approach, but it requires buy in. Buy in which it was not getting, and it had several years to get said buy in. When asm.js got announced I can only saw I was shocked. asm.js is brilliant! Brilliant in the same way utf-8 is. It does not require heavy changes yet could bring 90% of the benefit. It does not require a new sandbox. It is cross-platform and cross-architecture!
  - fulafel 13y ago
    NaCl is only enabled for Chrome app store apps. it's not for web apps. That may change after PNaCl is released.
    - zobzu 13y ago
      yeah but it will still be chrome only. asm.js stuff runs anywhere. just happens to run faster on firefox right now/for now.
      - fulafel 13y ago
        I was saying that you can't judge it a flop for lack of buy-in since they haven't launched it yet.
- pcwalton 13y ago
  > Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better. PNaCl is also a subset that is not meant to be written by hand—of LLVM IR. The difference is that asm.js subsets a language that is universally supported by all Web browsers, has massive traction, and has a detailed specification.
  - DannyBee 13y ago
kybernetikos 13y ago
I want "use asm" as a way of getting extra 'compile time' checking. If I say "use asm" and do something that isn't optimizable by mistake, it should give me an error rather than silently falling back to slow code.
- aegiso 13y ago
  That's all very nice, but it ain't gonna happen because of backwards compatibility. One of the main points of asm.js is that it runs everywhere the same as plain JS, whether the platform knows about asm.js or not.
  - reubenmorais 13y ago
    What? It already happened. That's exactly what happens when you do something that is not part of the asm.js subset in "use asm" code.
    - aegiso 13y ago
      I don't use Firefox but if that's the case then asm.js can no longer claim to be "just javascript". I wasn't expecting that one. Interestingly enough, this makes the V8 approach all the more welcome since it doesn't break backwards compatibility.
      - yohanatan 13y ago
        It sounds like you missed the distinction between a) displays an error and falls back to slower code and b) does not display an error and silently falls back to slower code. Neither of these options break any compatibility with Javascript proper (and yet one of them is highly more desirable than the other).
      - azakai 13y ago
        asm.js does not break backwards compatibility, asm.js code runs exactly the same in all browsers (if it doesn't, that's a bug and must be fixed of course). Firefox will warn about asm.js validation errors, but those are just warnings in the web console. They do not affect semantics of execution at all, and are undetectable by the running code. So the code will run identically in all browsers regardless of whether it happens to fall in the asm.js subset or not.
elisee 13y ago
On Firefox (which originally introduced it), finding "use asm" at the top of the script makes a subset of JavaScript faster by enabling an Ahead-Of-Time optimizing compiler. See http://badassjs.com/post/43420901994/asm-js-a-low-level-highly-optimizable-subset-of http://badassjs.com/post/43420901994/asm-js-a-low-level-high.... From what I understand, "asm.js" code without the "use asm" directive in Firefox would run slower because it wouldn't check it for compliance with the asm.js subset and enable the specialized AOT codepath. It's an interesting approach but feels a bit like over-specialization. The V8 guys on the other hand, decided to ignore the directive entirely and have been able to improve their (more "generic") JIT compiler to get it to run the same code almost as fast as Firefox's Ahead-Of-Time compiler in a lot of cases.
- azakai 13y ago
  Both v8 and spidermonkey JITs are close to the asm.js AOT in many (but not all) benchmarks, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... There is no difference in approach between Firefox and Chrome there, both believe JITs can achieve excellent performance, and are always pushing that further. So both browsers "ignore" the "use asm" hint in that sense. The only difference is that Firefox, in addition, has an asm.js AOT module that detects asm.js and can optimize it very well (using the same backend as the JIT, but taking advantage of type information from the asm.js type system). But that AOT does not mean anything about the rest of the JS engine.
  - rcthompson 13y ago
    So conceptually, the only thing that "use asm" does (in Firefox) is to tell the optimizer/JIT/whatever to assume certain types in advance rather than having it infer them at runtime?
    - azakai 13y ago
      Pretty much, yeah. The normal JIT is used, but first Firefox type checks the asm.js code, during which it detects all the types. Then it just tells the JIT what those types are. This reuses existing functionality in the JIT, as all modern JITs have mechanisms to receive type information - it's typically collected by monitoring types at runtime, the only difference is that here the types are collected through the asm.js type checker. There are also a few runtime changes as well with asm.js code. For example, the JS engine knows that asm.js code cannot throw exceptions (asm.js code is very low-level, so JS exceptions are not possible), so it can avoid emitting some things it would normally emit in order to handle deopts due to exceptions and so forth. (Of course this does not require an AOT, a JIT could also detect the lack of need for that overhead, perhaps this is already done in some cases, but the AOT guarantees it is done for all asm.js code.)

by Danieru 13y ago

eliben 13y ago

> Stay within the subset and your javascript will be fast You do realize that asm.js was not designed to be written by hand, don't you? It's a target for compilers. There are no bounds "to stay within" for hand-written JS which is still the vast majority of the code out there.

Danieru 13y ago
I do, which is why I said developers may "compile" their program into asm.js Even still someone has to write that compiler and they want to know what will be fast. I do not see many people writing asm.js by hand beyond optimizing vital sections.

camus2 13y ago

> Mozila does not need buy in from Google, or Apple, or MS. So why Chrome should buy from Firefox? why should they follow the asm.js spec ? Maybe it i the wrong answer to a real problem, javascript speed and its memory foodprint.Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better.

Danieru 13y ago
A fair question. I think it has parallels to Intel's itanium vs AMD's x64. I cannot pretend to know what is best in a perfect world. Yet I am willing to pretend to know what is the more practical way forward. Native Client is and was an interesting approach, but it requires buy in. Buy in which it was not getting, and it had several years to get said buy in. When asm.js got announced I can only saw I was shocked. asm.js is brilliant! Brilliant in the same way utf-8 is. It does not require heavy changes yet could bring 90% of the benefit. It does not require a new sandbox. It is cross-platform and cross-architecture!
- fulafel 13y ago
  NaCl is only enabled for Chrome app store apps. it's not for web apps. That may change after PNaCl is released.
  - zobzu 13y ago
    yeah but it will still be chrome only. asm.js stuff runs anywhere. just happens to run faster on firefox right now/for now.
    - fulafel 13y ago
      I was saying that you can't judge it a flop for lack of buy-in since they haven't launched it yet.
pcwalton 13y ago
> Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better. PNaCl is also a subset that is not meant to be written by hand—of LLVM IR. The difference is that asm.js subsets a language that is universally supported by all Web browsers, has massive traction, and has a detailed specification.
- DannyBee 13y ago

kybernetikos 13y ago

I want "use asm" as a way of getting extra 'compile time' checking. If I say "use asm" and do something that isn't optimizable by mistake, it should give me an error rather than silently falling back to slow code.

aegiso 13y ago
That's all very nice, but it ain't gonna happen because of backwards compatibility. One of the main points of asm.js is that it runs everywhere the same as plain JS, whether the platform knows about asm.js or not.
- reubenmorais 13y ago
  What? It already happened. That's exactly what happens when you do something that is not part of the asm.js subset in "use asm" code.
  - aegiso 13y ago
    I don't use Firefox but if that's the case then asm.js can no longer claim to be "just javascript". I wasn't expecting that one. Interestingly enough, this makes the V8 approach all the more welcome since it doesn't break backwards compatibility.
    - yohanatan 13y ago
      It sounds like you missed the distinction between a) displays an error and falls back to slower code and b) does not display an error and silently falls back to slower code. Neither of these options break any compatibility with Javascript proper (and yet one of them is highly more desirable than the other).
    - azakai 13y ago
      asm.js does not break backwards compatibility, asm.js code runs exactly the same in all browsers (if it doesn't, that's a bug and must be fixed of course). Firefox will warn about asm.js validation errors, but those are just warnings in the web console. They do not affect semantics of execution at all, and are undetectable by the running code. So the code will run identically in all browsers regardless of whether it happens to fall in the asm.js subset or not.

elisee 13y ago

On Firefox (which originally introduced it), finding "use asm" at the top of the script makes a subset of JavaScript faster by enabling an Ahead-Of-Time optimizing compiler. See http://badassjs.com/post/43420901994/asm-js-a-low-level-highly-optimizable-subset-of http://badassjs.com/post/43420901994/asm-js-a-low-level-high.... From what I understand, "asm.js" code without the "use asm" directive in Firefox would run slower because it wouldn't check it for compliance with the asm.js subset and enable the specialized AOT codepath. It's an interesting approach but feels a bit like over-specialization. The V8 guys on the other hand, decided to ignore the directive entirely and have been able to improve their (more "generic") JIT compiler to get it to run the same code almost as fast as Firefox's Ahead-Of-Time compiler in a lot of cases.

azakai 13y ago
Both v8 and spidermonkey JITs are close to the asm.js AOT in many (but not all) benchmarks, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... There is no difference in approach between Firefox and Chrome there, both believe JITs can achieve excellent performance, and are always pushing that further. So both browsers "ignore" the "use asm" hint in that sense. The only difference is that Firefox, in addition, has an asm.js AOT module that detects asm.js and can optimize it very well (using the same backend as the JIT, but taking advantage of type information from the asm.js type system). But that AOT does not mean anything about the rest of the JS engine.
- rcthompson 13y ago
  So conceptually, the only thing that "use asm" does (in Firefox) is to tell the optimizer/JIT/whatever to assume certain types in advance rather than having it infer them at runtime?
  - azakai 13y ago
    Pretty much, yeah. The normal JIT is used, but first Firefox type checks the asm.js code, during which it detects all the types. Then it just tells the JIT what those types are. This reuses existing functionality in the JIT, as all modern JITs have mechanisms to receive type information - it's typically collected by monitoring types at runtime, the only difference is that here the types are collected through the asm.js type checker. There are also a few runtime changes as well with asm.js code. For example, the JS engine knows that asm.js code cannot throw exceptions (asm.js code is very low-level, so JS exceptions are not possible), so it can avoid emitting some things it would normally emit in order to handle deopts due to exceptions and so forth. (Of course this does not require an AOT, a JIT could also detect the lack of need for that overhead, perhaps this is already done in some cases, but the AOT guarantees it is done for all asm.js code.)