6 ms·

Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Gi

by _bxg1 7y ago

Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Given that we often have it on hand already (TypeScript) or could integrate it into our build process (webpack). Obviously plain JS needs to still work without all that, but it could be a compelling point of optimization for large-scale apps. Perhaps the JS bytecode just isn't standardized across browsers?

XCSme 7y ago
You can with asm.js: https://2ality.com/2013/02/asm-js.html https://2ality.com/2013/02/asm-js.html
- _bxg1 7y ago
  That's not the same thing; asm.js is a precursor to WASM which is a bytecode language that doesn't include garbage collection, and asm.js is actually an interpreter for it that's written in JS. The JS bytecode the article talks about is generated from JS and interpreted by C++. In other words, it isn't practical to compile JS to WASM, and especially not to asm.js. The browser's JIT compilation of JS targets something completely different.
  - erikpukinskis 7y ago
    The point is, if you care about performance use asm.js. If you don’t then just use whatever standard path browsers provide and any optimization they do is gravy.
  - XCSme 7y ago
    I was mostly replying to this: "JS developers don't have the option to send along some of this information themselves; type information, JS bytecode", that in JS you can send some type information with asm.js hints (or TypedArrays), but yes you don't send it directly to the C++ interpreter, but to the JS interpreter, which presumably will pass it further.
WorldMaker 7y ago
JS tried to add (optional) type hints in the ES4 standard that was never adopted (outside of tangential things like ActionScript 3). It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future. (Well-typed code should prevent most JIT bailouts, at least. Typescript linters could possibly give even better "shape" warnings than they currently do, such as catching the issue the React team recently found of bailouts in the V8 engine due to "shapes" being built with "small integers" being reallocated to doubles at runtime. However, such lint warnings would probably be JIT engine specific, and maybe premature optimization in 90%+ of usages.)
- _bxg1 7y ago
  Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?
  - WorldMaker 7y ago
    In the long term, I hope that at least a compromise like the Python annotation approach could be reached (standardize the parsing, but ignore the semantics). Typescript type annotations share a surface level syntax with them in some ways, and also with ES4's type annotation attempt. "Type maps" are an interesting idea. You could probably piggy back on/boostrap from WASM types.
  - tomcam 7y ago
    Sounds good in theory, but it seems like rich territory for mismatched types in the source and map files.
    - _bxg1 7y ago
      I don't see why that would happen; you wouldn't be writing these by hand
xamuel 7y ago
One way to see it's more subtle than meets the eye: suppose the website defines a function F which is annotated as taking a string argument. The website itself only ever calls F with strings. But suppose I go to the website, open the console, and punch in F(1). Of course, this sort of thing could be guarded against, but the point is just that it would introduce more complexity than initially meets the eye.
- dymk 7y ago
  Engines already have to do this - check the type of an argument before calling the compiled version of the function. What the OP is suggesting is simply prefilling the type and instruction caches with information that the build system was already able to gleen.
- _bxg1 7y ago
  And that would probably amount to a "bailout". I'm only talking about providing hints that can be used to skip parts of the described process, not getting rid of it altogether.
  - leeoniya 7y ago
    i always wondered why it wasn't possible to use a js app in "record" mode and then export any witnessed type & profiling information from the JIT and deliver it alongside the source (like a sourcemap).
    - antiuniverse 7y ago
      That might be considered an example of profile-guided optimization: https://en.wikipedia.org/wiki/Profile-guided_optimization https://en.wikipedia.org/wiki/Profile-guided_optimization
      - leeoniya 7y ago
        yes, i was going to say PGO :)
landonxjames 7y ago
Deno[0], a project from the original author of Node, will natively run TypeScript, so I'm hoping it will have some of those sorts of optimizations. [0]https://github.com/denoland/deno https://github.com/denoland/deno
- hoten 7y ago
  Unless he's making his own JS engine, it won't.
- snek 7y ago
  It doesn't natively run typescript, it just includes a webpacked version of the typescript transpiler.

by _bxg1 7y ago

XCSme 7y ago

You can with asm.js: https://2ality.com/2013/02/asm-js.html https://2ality.com/2013/02/asm-js.html

_bxg1 7y ago
That's not the same thing; asm.js is a precursor to WASM which is a bytecode language that doesn't include garbage collection, and asm.js is actually an interpreter for it that's written in JS. The JS bytecode the article talks about is generated from JS and interpreted by C++. In other words, it isn't practical to compile JS to WASM, and especially not to asm.js. The browser's JIT compilation of JS targets something completely different.
- erikpukinskis 7y ago
  The point is, if you care about performance use asm.js. If you don’t then just use whatever standard path browsers provide and any optimization they do is gravy.
- XCSme 7y ago
  I was mostly replying to this: "JS developers don't have the option to send along some of this information themselves; type information, JS bytecode", that in JS you can send some type information with asm.js hints (or TypedArrays), but yes you don't send it directly to the C++ interpreter, but to the JS interpreter, which presumably will pass it further.

WorldMaker 7y ago

JS tried to add (optional) type hints in the ES4 standard that was never adopted (outside of tangential things like ActionScript 3). It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future. (Well-typed code should prevent most JIT bailouts, at least. Typescript linters could possibly give even better "shape" warnings than they currently do, such as catching the issue the React team recently found of bailouts in the V8 engine due to "shapes" being built with "small integers" being reallocated to doubles at runtime. However, such lint warnings would probably be JIT engine specific, and maybe premature optimization in 90%+ of usages.)

_bxg1 7y ago
Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?
- WorldMaker 7y ago
  In the long term, I hope that at least a compromise like the Python annotation approach could be reached (standardize the parsing, but ignore the semantics). Typescript type annotations share a surface level syntax with them in some ways, and also with ES4's type annotation attempt. "Type maps" are an interesting idea. You could probably piggy back on/boostrap from WASM types.
- tomcam 7y ago
  Sounds good in theory, but it seems like rich territory for mismatched types in the source and map files.
  - _bxg1 7y ago
    I don't see why that would happen; you wouldn't be writing these by hand

xamuel 7y ago

One way to see it's more subtle than meets the eye: suppose the website defines a function F which is annotated as taking a string argument. The website itself only ever calls F with strings. But suppose I go to the website, open the console, and punch in F(1). Of course, this sort of thing could be guarded against, but the point is just that it would introduce more complexity than initially meets the eye.

dymk 7y ago
Engines already have to do this - check the type of an argument before calling the compiled version of the function. What the OP is suggesting is simply prefilling the type and instruction caches with information that the build system was already able to gleen.
_bxg1 7y ago
And that would probably amount to a "bailout". I'm only talking about providing hints that can be used to skip parts of the described process, not getting rid of it altogether.
- leeoniya 7y ago
  i always wondered why it wasn't possible to use a js app in "record" mode and then export any witnessed type & profiling information from the JIT and deliver it alongside the source (like a sourcemap).
  - antiuniverse 7y ago
    That might be considered an example of profile-guided optimization: https://en.wikipedia.org/wiki/Profile-guided_optimization https://en.wikipedia.org/wiki/Profile-guided_optimization
    - leeoniya 7y ago
      yes, i was going to say PGO :)

landonxjames 7y ago

Deno[0], a project from the original author of Node, will natively run TypeScript, so I'm hoping it will have some of those sorts of optimizations. [0]https://github.com/denoland/deno https://github.com/denoland/deno

hoten 7y ago
Unless he's making his own JS engine, it won't.
snek 7y ago
It doesn't natively run typescript, it just includes a webpacked version of the typescript transpiler.