3 ms·

> This promise was, as far as I understand, effectively abandoned first by the introduction of "Baseline" compilers (Liftoff, in V8 terminology)... This, I don

> This promise was, as far as I understand, effectively abandoned first by the introduction of "Baseline" compilers (Liftoff, in V8 terminology)... This, I don't understand... AFAICT the "baseline" compiler's entire job is to get pixels on the screen as fast as possible and then they use optimization strategies to recompile code sections or functions or whatever to speed it up based on $reasons.

kevingadd 3y ago
One of the historical problems with JS for the kind of application WASM gets used for was that you had no way to predict how a given piece of JS would perform in each browser. The quality of the generated code was dependent on a ton of factors, and code could randomly get de-optimized during execution if you accidentally did something like pass a double into a function that had previously only been passed integers, despite the two being the same JS type. JS compilers are full of weird heuristics based on things like (I kid you not) how many characters are in your function's source code. WASM originally promised to be AOT compiled once, start to finish, with consistent performance. The design omitted some useful (perhaps essential) things in order to be able to provide this.