Hacker News Reader

The V8 team experimented with "Strong Mode" which was approximately this - a fast subset of JS [0]. The experiment was ended [1]

[0] https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

[1] https://groups.google.com/g/strengthen-js/c/ojj3TDxbHpQ/m/5E...

From a quick glance this looks like a further subsetting a la strict mode, which isn't really what I meant

I clarified in another thread, but what I meant to convey is a way of giving very specific hints about specific pieces of one codebase:

"Function X will only ever take two arguments, they will be of types Y and Z"

"This object will only ever have these properties; it will never have properties created or deleted"

"This prototype will never be modified at runtime"

This could guarantee ahead-of-time that certain optimizations - packing an object as a struct instead of a hashmap, for example - can be done, so that V8 doesn't have to spend time speculating about whether or not to JIT something

Isn't that what asm.js did?

Maybe from a certain perspective. But it worked by conforming the bundle to a particular subset of JS that the authors knew to be optimized, instead of expressing information to the interpreter outright. That seems like a comparatively limited channel for communication.

From what I understand, in Safari at least they tried to make many of the optimizations general. So if you use asm.js-style type indications in your code even without following the full spec, you might see some performance benefit.

I have sometimes found a speedup when adding apparently an superfluous |0.

The highly optimizable, explicit and precise code for the interpreter is WASM.

JS VMs don't need more hints from the code. They need guarantees. They already analyze and profile JS, but as long as JS is allowed to be dynamic (and it has to, it won't be JS without it), then they have to keep the complexity and cost of all the extra runtime checks and possible deoptimizations.

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

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

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!)

The problem is less about the annotations (you can already infer most of this from a single pass over the code) than it is about the calls. If you have a reference to a function, you need that data handy. Unless you're copying it around with your function reference, you don't have that data (and it's prohibitively expensive to try).

JS is heavy on function references (closures are one of the most popular JS idioms), so it's not easy to know at call time how you can optimize your code.

OK let's say you have f, it only takes arguments a:Y, and b:Z.

I call f(Z, Y). What happens? Does the machine segfault? Probably not.... so you're in "check the types at the callsite" territory. And honestly those kind of boundary checks are the problem, so to speak.

Are we doing static analysis of the entire codebase (a sort of closed-world theory?) You could maybe do something like this for non-exported functions, though at the V8 level that's tough.

I think that there would be possibilities to somehow get systems to be set up in a way to do more cleverness along these lines, but so long as you're taking in stuff from the outside world you end up needing to set up relatively costly checks, relative to the cost of the "default" JS semantics that you're trying to avoid paying.

>"This object will only ever have these properties; it will never have properties created or deleted"

>"This prototype will never be modified at runtime"

You can already give these hints with Object.freeze/Object.seal

Not really hints though, they enforce a certain behavior. Because hints aren't enough. A JS engine may already assume you'll never change the objects, but it still has to support cases where you then do so anyways.

I don't think these alone would enable any substantial speedups, since the performance issues arise where unknown objects are used.

> You can already give these hints with Object.freeze/Object.seal

You can but my understanding is the performance tradeoffs aren't great unless you have a workload that especially benefits from it. Those calls are expensive.

This may be a bit of a reach, but there's AssemblyScript [1], which is a compiler from a strict variant of TypeScript to WebAssembly. Since technically V8 is also a WebAssembly engine, porting some part of your codebase from JS/TS to AssemblyScript could improve your performance.

[1]: https://www.assemblyscript.org/

Does V8 actually run compiler optimizations on WebAssembly? I thought it came pre-optimized and it just executed it.

My impression of WASM was it's ok but it's not very expressive for an assembly language - at least it has integers though. gcc.godbolt.org doesn't give you any library functions for it, even memcpy(), so I couldn't do a lot of testing.

I think it does. Here's an article introducing Liftoff [1] with the relevant parts:

> With Liftoff and TurboFan, V8 now has two compilation tiers for WebAssembly: Liftoff as the baseline compiler for fast startup and TurboFan as optimizing compiler for maximum performance.

> Immediately after Liftoff compilation of a module finished, the WebAssembly engine starts background threads to generate optimized code for the module.

[1]: https://v8.dev/blog/liftoff

> already uncommon

It's definitely not uncommon though. Just to provide one example: how often do you use all the arguments to `.map` callback?

Usually you'd write something like `arr.map(x => x + 1)`.

However, to spell out all the arguments you'd have to write `arr.map((x, i, arr) => x + 1)`.

And there's tons of other functions like that in stdlib or 3rd-party libs that people use without passing or accepting all the args. That's why this optimisation is so useful.

This is exactly the kind of thing that TypeScript generated JS could help optimize. Because tsc can see that this `map` call is, in fact, Array.prototype.map, it can deduce that the lambda will get sent three values. It could generate dummy arguments for that in the JS output. It could just as easily generate a hint to the same effect in some constraint file as the GP suggests.

In general I think this is an interesting idea, but I feel like this has a lot of overlap with asm.js and WebAssembly.

With this standard we would have standard dynamic JavaScript as the world knows it today, a restricted subset ('constraint spec') that is still designed for human readability/writability, and then asm.js/WebAssembly, which would not be written directly but instead would be an output of code written in other languages. Programmers will want interoperability between all of these paths, and that is a lot of complexity for these engines to manage.

There's already "use strict" that does some of this to enable optimizations and other stuff. Maybe it should be even stricter or something similar could be used.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Right but I'm talking about very specific hints for one codebase

"Function X will only ever take two arguments, they will be of types Y and Z"

"This object will only ever have these properties; it will never have properties created or deleted"

"This prototype will never be modified at runtime"

It still has to verify that those assertions are true in practice. Any random person at the console can call a function and pass whatever they like.

The only real way to make that work would be a new `<script type="typed-module" />` variant that implemented a subset of JS in a typed environment.

My guess is that this could happen in the future, but everyone is watching Typescript as a testing ground to find exactly what works, what doesn't, and what works, but isn't desirable.

There's already a mechanism for bailing out when optimization assumptions are violated; they could be made more eagerly but retain the ability to degrade

> "This object will only ever have these properties; it will never have properties created or deleted"

Already in JavaScript: Object.seal(object)

> "This prototype will never be modified at runtime"

Already in JavaScript: Object.freeze(myPrototype)

Regarding your update: I think there is some interest in passing TS type annotations on to the JS VM/JIT, but my impression is still that TC39 is rather shy on the subject after the still not entirely healed scars of ES4.

I know I would love to see TS type annotations made syntactically valid if semantically ignored (ala Python's type annotations PEPs), simply to make sure valid TS runs in the browser without a build step to better unify the "subset". It wouldn't be a far shot from there to seeing at least some small type annotation hints support in JS engines. Though I definitely understand the concerns and wariness that anything done there would be very engine-specific and in danger of lock in for the web.

I heard there were some V8-specific prototype attempts from some of the Deno developers, but I don't recall how far those attempts got or if they had anything in the way of results.

I think this is what WASM is meant to achieve. It allows for much more precise semantics without needing to parse an AST.