5 ms·

Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, withou

Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.

bmurphy1976 12y ago
That's cool that they are trying, but what's the opportunity cost of not doing it? How much effort would it be to simply optimize asm.js now and then undo the optimization later when the core JIT gets smarter? Seems to me THAT is the way to go, but this is not my area of expertise.
jlongster 12y ago
While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance.
- nothrabannosir 12y ago
  asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with. EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.
  - TazeTSchnitzel 12y ago
    > asm.js represents LLVM bytecode No, emscripten compiles asm.js from LLVM IR, but asm.js itself is more like a portable bytecode for a 32-bit register machine. > The programmer sees errors when generating the asm.js, not when executing it. Why would that be the case? The point of asm.js is so browsers can optimise it. It doesn't matter what your tooling thinks, in the end what matters is whether browsers accept it. > Whether it is then executed by a JIT or not is, in this case, irrelevant. No, whether it is executed by a JIT is quite important. asm.js is a subset that browsers can validate and then compile ahead-of-time. If your code is failing validation and falling back to the usual JavaScript mode, there's a big performance penalty, and your code isn't asm.js-compliant! > Nobody writes asm.js by hand, no matter how it is executed. Actually, some people do. It's not the nicest of languages, but there are some people who do. But even if you don't, what if you're using buggy or outdated tooling producing incorrect output? What if you're targeting a browser that doesn't support some new asm.js feature? You need to know if your code didn't validate!
    - Sephr 12y ago
      > Actually, some people do [write asm.js code by hand] Who?
      - TazeTSchnitzel 12y ago
        People wanting high performance. For example, Grant Galitz's IodineGBA had some portions in asm.js https://github.com/taisel/IodineGBA https://github.com/taisel/IodineGBA
        Sephr 12y ago
        No, it doesn't. Where in IodineGBA do you see any hand-written asm.js code? Here's are some quotes from the author of that very library: "asm.js requires a style of coding only compilers can output. A person writing actual asm.js code by hand would need to be insane as asm.js code required style of coding is horribly disorganized"[1] "Unfortunately asm.js requires one giant array to put things on. No one in their right mind codes like that by hand."[2] 1: https://github.com/taisel/IodineGBA/issues/16#issuecomment-26540283 https://github.com/taisel/IodineGBA/issues/16#issuecomment-2... 2: https://github.com/taisel/IodineGBA/issues/16#issuecomment-26540283 https://github.com/taisel/IodineGBA/issues/16#issuecomment-2...
- TazeTSchnitzel 12y ago
  > One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance. Related, and you've sort of mentioned this: having your browser be able to validate asm.js is useful for web developers, because then they know if their code is broken (and so will run slower).
  - s-macke 12y ago
    Exactly. When I ported my software manually, it was the warning messages that helped. After that I can remove the "asm.js" statement and achieve almost the same performance (around 80% of max speed). asm.js runs currently through an foreign function interface in Firefox, which makes calling the asm.js code slower.
ndesaulniers 12y ago
Why does it have to be mutually exclusive? It's more work, but Google has more $$$ to spend than say Mozilla.

bmurphy1976 12y ago

That's cool that they are trying, but what's the opportunity cost of not doing it? How much effort would it be to simply optimize asm.js now and then undo the optimization later when the core JIT gets smarter? Seems to me THAT is the way to go, but this is not my area of expertise.

jlongster 12y ago

While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance.

nothrabannosir 12y ago
asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with. EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.
- TazeTSchnitzel 12y ago
  > asm.js represents LLVM bytecode No, emscripten compiles asm.js from LLVM IR, but asm.js itself is more like a portable bytecode for a 32-bit register machine. > The programmer sees errors when generating the asm.js, not when executing it. Why would that be the case? The point of asm.js is so browsers can optimise it. It doesn't matter what your tooling thinks, in the end what matters is whether browsers accept it. > Whether it is then executed by a JIT or not is, in this case, irrelevant. No, whether it is executed by a JIT is quite important. asm.js is a subset that browsers can validate and then compile ahead-of-time. If your code is failing validation and falling back to the usual JavaScript mode, there's a big performance penalty, and your code isn't asm.js-compliant! > Nobody writes asm.js by hand, no matter how it is executed. Actually, some people do. It's not the nicest of languages, but there are some people who do. But even if you don't, what if you're using buggy or outdated tooling producing incorrect output? What if you're targeting a browser that doesn't support some new asm.js feature? You need to know if your code didn't validate!
  - Sephr 12y ago
    > Actually, some people do [write asm.js code by hand] Who?
    - TazeTSchnitzel 12y ago
      People wanting high performance. For example, Grant Galitz's IodineGBA had some portions in asm.js https://github.com/taisel/IodineGBA https://github.com/taisel/IodineGBA
      - Sephr 12y ago
        No, it doesn't. Where in IodineGBA do you see any hand-written asm.js code? Here's are some quotes from the author of that very library: "asm.js requires a style of coding only compilers can output. A person writing actual asm.js code by hand would need to be insane as asm.js code required style of coding is horribly disorganized"[1] "Unfortunately asm.js requires one giant array to put things on. No one in their right mind codes like that by hand."[2] 1: https://github.com/taisel/IodineGBA/issues/16#issuecomment-26540283 https://github.com/taisel/IodineGBA/issues/16#issuecomment-2... 2: https://github.com/taisel/IodineGBA/issues/16#issuecomment-26540283 https://github.com/taisel/IodineGBA/issues/16#issuecomment-2...
TazeTSchnitzel 12y ago
> One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really big for comprehending performance. Related, and you've sort of mentioned this: having your browser be able to validate asm.js is useful for web developers, because then they know if their code is broken (and so will run slower).
- s-macke 12y ago
  Exactly. When I ported my software manually, it was the warning messages that helped. After that I can remove the "asm.js" statement and achieve almost the same performance (around 80% of max speed). asm.js runs currently through an foreign function interface in Firefox, which makes calling the asm.js code slower.

ndesaulniers 12y ago

Why does it have to be mutually exclusive? It's more work, but Google has more $$$ to spend than say Mozilla.