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.
> 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).)
> 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.
The target model of the asm.js (and therefore WebAsm) intentionally doesn't assume the "VM" features that Java VM has. It's much, much lower level. No classes. Even no strings.
Java VM receives the classes, methods, strings, has GC and all that, but it has to JIT to reach that lower level to be efficient and has to do a kind of establishing what's actually used, similarly to what tracing JIT engines for classic JavaScript do.
I believe that kind of run-time measurements and then code generation and optimization is what some Java people call PGO, and what asm.js at the moment intentionally (by design) avoids.
In short, Java's PGO on the user side is not what PGO for static languages like C is (by the developer). And asm.js is even lower than C. It's really closer to... asm.
Exactly because asm.js avoided these decisions was Firefox with asm.js support faster than Chrome at the time the later treated all js code the same.
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.