Using TS type annotations for JavaScript engine optimization
1–10 of 11 posts
Re: Using TS type annotations for JavaScript engine optimization
#2> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash.
>
> But we could define the type using type annotations (TS)!
>
> Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :)
This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app will crash. Also I get the sense that the author assumes type "string" always means non-null and non-undefined but this is only true if the strictNullChecks compiler option is enabled.
Nonetheless, cool to see folks experimenting in the JS engine arena, especially around AOT!
Re: Using TS type annotations for JavaScript engine optimization
#3> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :) This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app w…
A useful way to think of this kind of thing is to hoist the assertions into the caller, where they can be optimized out.
There's a lot of poorly-explored room in compiler design to take generalized invariants/preconditions/postconditions into consideration (explicit ones are useful for opaque functions defined in a different TU), not just things considered "types" (the problem with types is that they have different lifetime/allocation concerns than assertions).
Re: Using TS type annotations for JavaScript engine optimization
#4> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :) This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app w…
> Disabling `strictNullChecks`
Are people this eager to be PIP'd?
Re: Using TS type annotations for JavaScript engine optimization
#5> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :) This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app w…
A useful way to think of this kind of thing is to hoist the assertions into the caller, where they can be optimized out. There's a lot of poorly-explored room in compiler design to take generalized invariants/preconditions/postconditions into consideration (explicit ones are useful for opaque functions defined in a different TU), not just things considered "types" (the problem with types is that they have different l…
Refinement types and liquid types (which are a subclass of refinement types).
Re: Using TS type annotations for JavaScript engine optimization
#6Just a hitch found on https://porffor.goose.icu/
On running the example 'Array Reading' with an optimization level of 3 I get the following error
CompileError: WebAssembly.instantiate(): Compiling function #2 failed: local.set[0] expected type f64, found global.get of type i32 @+207
Is this expected?
Re: Using TS type annotations for JavaScript engine optimization
#7Earlier quoted context omitted.
A useful way to think of this kind of thing is to hoist the assertions into the caller, where they can be optimized out. There's a lot of poorly-explored room in compiler design to take generalized invariants/preconditions/postconditions into consideration (explicit ones are useful for opaque functions defined in a different TU), not just things considered "types" (the problem with types is that they have different l…
Refinement types and liquid types (which are a subclass of refinement types).
From what I've seen, those are poorly done in practice, usually in multiple ways.
Recently I've been writing code to deal with partial alignment. The desired invariants here typically involves at least 3 variables:
align must be a power of 2. Since this involves only one variable, refinement types can handle this one just fine at least (expression: n && !(n & (n-1)) ).
0 Now consider ABI compatibility, say if we had forgotten to add the skew != 0 condition somewhere. If old code calls the function, it needs to hit a thunk that verifies the condition. New code however should have done that in the caller and thus enter the code directly. Where is the compiler tooling to support this? Clearly, invariants (and pre- and post-conditions, which are just invariants for a finite time) need to be able to specify what version of your code they were first specified in. That's a lot of information to specify in a function type which often gets disregarded.
Re: Using TS type annotations for JavaScript engine optimization
#8> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :) This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app w…
> Disabling `strictNullChecks` Are people this eager to be PIP'd?
You don't really get the luxury of being opinionated about Typescript settings when you are implementing a runtime
Re: Using TS type annotations for JavaScript engine optimization
#9> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :) This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app w…
> Disabling `strictNullChecks` Are people this eager to be PIP'd?
[dead]
Re: Using TS type annotations for JavaScript engine optimization
#10Just a hitch found on https://porffor.goose.icu/ On running the example 'Array Reading' with an optimization level of 3 I get the following error CompileError: WebAssembly.instantiate(): Compiling function #2 failed: local.set[0] expected type f64, found global.get of type i32 @+207 Is this expected?
Unfortunately yes, optimizer at high levels is very unstable/aggressive at the moment. Currently working on refactoring things for perf generally instead of just an optimizer, but definitely will fix in the future!