3 ms·

yes i understand that. my question is, can that inferred type info be used to output the optimized bytecode as asm.js so that it can be included right away. lik

yes i understand that. my question is, can that inferred type info be used to output the optimized bytecode as asm.js so that it can be included right away. like statically compressed .gz assets (pre-optimized). it would effectively make a js -> asm.js compiler

aardvark179 12y ago
Possibly, but the types by a VM are rarely guaranteed to be completely accurate (some traps will be included in optimised code to capture the cases where types may not be as expected). They may only be true for the particular input data, other other libraries used, or stuff like that. Using previous runs to inform the JIT of expected types is entirely reasonable though, and think various JS implementations already do this.
- leeoniya 12y ago
  > some traps will be included in optimised code to capture the cases where types may not be as expected none of that should matter. if the resulting JIT'd code is faster with the traps than the plain js without them, so be it.
CHY872 12y ago
Erm, so you could possibly do some stuff like this (probably not for Js). It's called profile guided optimisation - you compile, run, take measurements, and the compiler uses those measurements to pick the right optimisations to use. I don't know how desirable it would be - you'd be shifting the burden from the compiler to the network, basically. In particular, you'd still have to compile it, which means that all you're gaining is the time before JIT decides that the code's super hot. A nicer approach might be like Oracle hints - you have a small comment you place above a function that tells the JIT how you want it compiled. You test your software using an instrumented browser, and that adds the comments between you finishing and it running. It kinda ups the complexity by loads, though - and I bet the benefits would be relatively small. Stuff like minifying and compressed assets has really tangible benefits, but here you have something that can easily be done wrong, and really only improves the execution of a very small overall percentage of functions.

aardvark179 12y ago

Possibly, but the types by a VM are rarely guaranteed to be completely accurate (some traps will be included in optimised code to capture the cases where types may not be as expected). They may only be true for the particular input data, other other libraries used, or stuff like that. Using previous runs to inform the JIT of expected types is entirely reasonable though, and think various JS implementations already do this.

leeoniya 12y ago
> some traps will be included in optimised code to capture the cases where types may not be as expected none of that should matter. if the resulting JIT'd code is faster with the traps than the plain js without them, so be it.

CHY872 12y ago

Erm, so you could possibly do some stuff like this (probably not for Js). It's called profile guided optimisation - you compile, run, take measurements, and the compiler uses those measurements to pick the right optimisations to use. I don't know how desirable it would be - you'd be shifting the burden from the compiler to the network, basically. In particular, you'd still have to compile it, which means that all you're gaining is the time before JIT decides that the code's super hot. A nicer approach might be like Oracle hints - you have a small comment you place above a function that tells the JIT how you want it compiled. You test your software using an instrumented browser, and that adds the comments between you finishing and it running. It kinda ups the complexity by loads, though - and I bet the benefits would be relatively small. Stuff like minifying and compressed assets has really tangible benefits, but here you have something that can easily be done wrong, and really only improves the execution of a very small overall percentage of functions.