4 ms·

> For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice? WebAssem

by acqq 10y ago

> For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice? WebAssembly is treated just like other "real binaries" produced for the "real" OS. Whatever survived the static optimizations while producing the binaries is converted, at the end, to the pure machine code, you don't "trace" it in run-time by the user. > even very static languages like C benefit from speculative optimisations which may need to be reversed. I'm not aware of "speculative optimisations which may need to be reversed" in C, and I'd be very interested to read what you mean when you write that, possibly with some links and references. Do you mean run-time, by the user, or something else?

Someone 10y ago
I think that is left open to the implementation. _If_ an implementer thinks there is a benefit in doing so, he's free to do so. In fact, that's similar to how a CPU runs "real binaries". Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it. That's only small bits, but it _is_ runtime information. I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code.
- acqq 10y ago
  I think you confuse the tracing during the interpretation of JavaScript with asm.js&WebAsm. Namely asm.js&WebAsm are designed to avoid as much as possible anything deciding in the run-time, except for verifying and generating the machine code, exactly because these "let's see what the code is doing in the run-time" were already implemented and were used for "plain" JavaScript, but had too much overhead, compared to what asm.js&WebAsm does (or avoids to do), for the kind of uses where asm.js&WebAsm are desired. For the "plain" JavaScript, there are the run-time decisions. > Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it. Sure. But that run-time information is internal to the CPU. And the CPU will use it for the native binary code that is the final result of asm.js or WebAsm, just like any other. But that native binary code is "static," it's explicitly not "small traced chunks" the way "plain" JavaScript is handled. > I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. If you manage to develop software method that actually improves the execution speed of the native code in run-time, you'd be famous and (if you know how to market it) rich.
  - barrkel 10y ago
    > I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. That's exactly what profile-guided optimization does. It's not a new invention, it's working technology. And it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. Specific example: a common tradeoff made in compilation is between space and speed, and there are some cases - like padding to align a jump target - that can win big speed improvements in inner loops, but are pessimal when used liberally (because code size inflates and doesn't fit in cache). Realigning jump targets is something that can be done to compiled code, in particular compiled code before it has been linked, when all the relocations and fixups are still available. Having information about hot code can make a big difference here. (BTW: optimizing linkers are surprisingly involved here, particularly for targets that have a bunch of addressing modes, like x86. Some ways of writing in fixups can result in smaller code (e.g. 1 byte offsets rather than 2 byte offsets), but this effect cascades: making code smaller can make what used to be a 2 byte offset possible to fit in 1 byte. Don't underestimate the amount of optimization that your linker does with native code (if you have a smart linker; my experience is from the Delphi compiler source).)
    - acqq 10y ago
      > it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary. And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS which does PGO on the native binaries when user runs them. Maybe you know of something like that? The PGO I know is always a slow process, done only before shipping the binary to the user, it's a kind of "post-processing" step of compiling, not of the normal execution at the user's computer.
      - 10y ago

by acqq 10y ago

Someone 10y ago

I think that is left open to the implementation. _If_ an implementer thinks there is a benefit in doing so, he's free to do so. In fact, that's similar to how a CPU runs "real binaries". Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it. That's only small bits, but it _is_ runtime information. I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code.

acqq 10y ago
I think you confuse the tracing during the interpretation of JavaScript with asm.js&WebAsm. Namely asm.js&WebAsm are designed to avoid as much as possible anything deciding in the run-time, except for verifying and generating the machine code, exactly because these "let's see what the code is doing in the run-time" were already implemented and were used for "plain" JavaScript, but had too much overhead, compared to what asm.js&WebAsm does (or avoids to do), for the kind of uses where asm.js&WebAsm are desired. For the "plain" JavaScript, there are the run-time decisions. > Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it. Sure. But that run-time information is internal to the CPU. And the CPU will use it for the native binary code that is the final result of asm.js or WebAsm, just like any other. But that native binary code is "static," it's explicitly not "small traced chunks" the way "plain" JavaScript is handled. > I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. If you manage to develop software method that actually improves the execution speed of the native code in run-time, you'd be famous and (if you know how to market it) rich.
- barrkel 10y ago
  > I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. That's exactly what profile-guided optimization does. It's not a new invention, it's working technology. And it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. Specific example: a common tradeoff made in compilation is between space and speed, and there are some cases - like padding to align a jump target - that can win big speed improvements in inner loops, but are pessimal when used liberally (because code size inflates and doesn't fit in cache). Realigning jump targets is something that can be done to compiled code, in particular compiled code before it has been linked, when all the relocations and fixups are still available. Having information about hot code can make a big difference here. (BTW: optimizing linkers are surprisingly involved here, particularly for targets that have a bunch of addressing modes, like x86. Some ways of writing in fixups can result in smaller code (e.g. 1 byte offsets rather than 2 byte offsets), but this effect cascades: making code smaller can make what used to be a 2 byte offset possible to fit in 1 byte. Don't underestimate the amount of optimization that your linker does with native code (if you have a smart linker; my experience is from the Delphi compiler source).)
  - acqq 10y ago
    > it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary. And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS which does PGO on the native binaries when user runs them. Maybe you know of something like that? The PGO I know is always a slow process, done only before shipping the binary to the user, it's a kind of "post-processing" step of compiling, not of the normal execution at the user's computer.
    - 10y ago