Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

AFAICT the v8 JIT collects such information form code's behavior, and uses it to generate efficient machine code.

If v8 could accept Typescript directly, it probably could pass this kind of information to the JIT directly, too. But the input language is ES6 or something like it, and it has to follow the calling conventions of it. I'm afraid that adorning ES6 with this information would be either brittle or backwards-incompatible.



> I'm afraid that adorning ES6 with this information would be either brittle or backwards-incompatible

Like I said above, it could be shipped as separate (optional) metadata files associated with source files, the same way that source maps already work


It can't trust that all the metadata is correct, otherwise security issues can happen. And if you need to do that, why not just gather / regenerate the same information at compile time.

Also, what do you do about code loading? e.g. scripts loaded from other files at runtime, or eval? Does it throw an error if a third-party script uses a function incorrectly? Or do we assume that metadata is local-use only?

There are a lot of things in JavaScript and also the "browser environment" (e.g. ads, third-party scripts) that can limit the utility of traditional compiler techniques.


There are already stepped levels of optimization going on in the JS engine; it goes to great lengths to reverse-engineer whether something can probably be optimized or not, and to handle all the edge cases where it needs to bail out into a less-efficient mode when some assumption is violated. All I'm talking about is a way to give it extra hints about what to eagerly optimize and how. All of that other robustness can stay in place.


Pretty much all that buys you is a small reduction in an already-small warm-up phase before the jit chooses a late-stage optimization (possibly with an increased cost for loading that phase, so even that small gain may be reduced). Only for code that uses this. And performs worse if it proves incorrect, as bail-out logic is generally a bit costly.

Browsers have experimented with hints quite a lot. Nearly all of them have been rolled back, since adding the general strategies to the jit is vastly more useful for everyone, and perform roughly as good or better since they identify the optimization everywhere, rather than only in annotated code.

---

The only ones I'd call "successful" so far have been 1) `"use strict";` which is not really an optimization hint, as it opts you into additional errors, and 2) asm.js, which has been rolled back as browsers now just recognize the patterns.

asm.js did at least have a very impressive run for a while... but it's potentially even more at risk of disappearing completely than many, since it's rather strictly a compiler target and not something humans write. wasm may end up devouring it entirely, and it could happen rather quickly since asm.js degrades to "it's just javascript" and it continues working if you drop all the special optimization logic (which is to its credit - it has a sane exit strategy!)


Missed that, thanks. That could indeed work. It could even nicely dovetail into the Typescript (or Reason, or Elm) compilation process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: