5 ms·

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/do

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_XNCLemj42FqfsRLp49nDQMZ1y7fwf5YjaI4/view https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp... [1] https://groups.google.com/g/strengthen-js/c/ojj3TDxbHpQ/m/5ENNAiUzEgAJ https://groups.google.com/g/strengthen-js/c/ojj3TDxbHpQ/m/5E...

brundolf 6y ago
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
- k__ 6y ago
  Isn't that what asm.js did?
  - brundolf 6y ago
    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.
    - jacobolus 6y ago
      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.
    - pornel 6y ago
      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.
- nine_k 6y ago
  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.
  - brundolf 6y ago
    > 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
    - nine_k 6y ago
      Missed that, thanks. That could indeed work. It could even nicely dovetail into the Typescript (or Reason, or Elm) compilation process.
    - Jasper_ 6y ago
      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.
      - brundolf 6y ago
        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.
- bastawhiz 6y ago
  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.
- rtpg 6y ago
  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.
- chmod775 6y ago
  >"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.
  - eyelidlessness 6y ago
    > 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.

brundolf 6y ago

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

k__ 6y ago
Isn't that what asm.js did?
- brundolf 6y ago
  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.
  - jacobolus 6y ago
    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.
  - pornel 6y ago
    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.
nine_k 6y ago
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.
- brundolf 6y ago
  > 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
  - nine_k 6y ago
    Missed that, thanks. That could indeed work. It could even nicely dovetail into the Typescript (or Reason, or Elm) compilation process.
  - Jasper_ 6y ago
    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.
    - brundolf 6y ago
      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.
bastawhiz 6y ago
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.
rtpg 6y ago
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.
chmod775 6y ago
>"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.
- eyelidlessness 6y ago
  > 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.