3 ms·
I am reading correctly that this makes deliberately unsound optimizations? For example it seems to assume that `console.log` or `print` will never change, and t
by ridiculous_fish 5y ago
I am reading correctly that this makes deliberately unsound optimizations? For example it seems to assume that `console.log` or `print` will never change, and there's no deopt check?
edit: I missed the section titled "Configurable optimizations" where it addresses this.
- whizzter 5y agoNot 100% on how they do everything but remember that this is mostly a tool for porting JS games, soundness isn't a top priority really, rather running real-world game code is and that code doesn't always do too much funky stuff. As such I'd guess that they have an initial pass that just looks for bad patterns (eval,etc) and totally ignores optimizing those, next up you look for other things (like writes to named properties, if nobody ever writes to a .log property it's probably fairly safe since the main task is AOT compiling code). There's probably a switch-es to enable a safer mode for various things where a fast-path is the default but fallbacks would work,etc.
- ridiculous_fish 5y agoAgreed, there's a lot of optimizations you can unlock if you ignore JS misfeatures like modifying Array.prototype. But it's important for compilers to be precise about the semantics they implement. I just saw the section about enabling checks for when the assumptions are violated, that's a good thing to have.