10 ms·

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-for-more-performant-javascript/ https://clipperhouse.com/does-typescript-make-for-more-perfo...

askmike 8y ago
IMO The problem as it stands now is that when developing typescript you have a compiler running on your machine doing the typechecking. It will error out and simply not compile when you try to pass a string to a fn expecting a number. What if there is a bug (or even a misconfiguration in your project)? Or typescript changes over time (and now there are different versions all needed to be supported)? Or what if the types from typescript (designed for programmers) are not always inline with V8 internal representation of objects?) Or what if people push typescript through V8 with compile time errors? (The compiler should have prevented this from happening - but you can pump whatever you want into V8, including things considered broken by typescript). You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling). As of now there are little guarantees with the javascript language (which is what comes out of your typescript compiler). AFAIK typescript is designed to help programmers find common bugs. Not saying it's not possible, but more work is needed into bridging the two.
- enitihas 8y ago
  Wouldn't it be good if JavaScript also starts supporting python like type annotations (completely optional, but unlike python used to guide the optimizer. Given that some non trivial amount of JS is already generated after type checking (typescript, flow, and all the statically typed languages compiling to JS), all this compile time type info could be made available to the optimizer.
  - askmike 8y ago
    For speed purposes? This post is for example already talking about how fast JS is getting without types. I'd say it would be a lot easier to simply focus on the WebAssembly format, you can write your code in a number of (typed) languages and compile into wasm which is designed to be fast. Javascript already comes with a few decades of bagage, and things are already changing really fast (ES6 and newer versions). Not everyone likes types and the people who do can use typescript (or flow). And the people who need insane performance (games, etc) can use WebAssembly.
    - enitihas 8y ago
      Yes for speed purposes. And yes some people may not like types, that's why I said completely optional. Anyways the optimizer tries to figure out the types on it's own, so give it a non blank slate to start with. You are correct in noting that js is already fast enough, but the problem is the sort of performance gotchas(order of keys in objects) as mentioned in the post aren't really obvious during development time. Types may help level the unpredictability.
  - dblohm7 8y ago
    That's basically what asm.js was, just less friendly to human readers.
    - lifthrasiir 8y ago
      asm.js put a type information to every single expression node, something you would never do even in the most statically typed languages.
  - conceptme 8y ago
    Python totally ignores them at runtime, PHP has this but it actually slows down the code a bit. It does make catching bugs easier.
- jahewson 8y ago
  I quite disagree. Look at JVM performance, there’s been huge improvements over time and a Java program compiled 20 years ago will get the same improvements as one compiled today. Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler.
  - askmike 8y ago
    I very much agree with you! > You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling). I meant this in reference to runtime speed optimisations coming from types. V8 is improving every day!
  - weberc2 8y ago
    > Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler. I can’t help myself, but the JVM performs at par with managed AOT languages (Go, Haskell, OCaml, etc) and strictly slower than the unmanaged AOT languages (C, C++, Rust). The JVM does outperform various AOT Java compilers, but that’s probably an artifact of the decades of optimizations that went into the JVM; the same investment in an AOT compiler would close the gap to within the margin of error. Anyway, sorry for my compulsive nitpicking; hopefully it was interesting.
    - repolfx 8y ago
      Lots of people believe this but it's false. JVM vs C++ depends very much on the code shapes and what the code is doing. C++ that's very heavy on virtual function calls can be faster written as Java. On the other hand if you use a lot of SIMD intrinsics and things like that, C++ can be a lot faster. W.R.T. AOT vs JIT, as others are pointing out, Graal is a compiler that can execute in both modes, i.e. it's a comparable compiler. JITC is about a 20% win for relatively static languages like Java and can be massively larger (like 4000%+) for other languages like JavaScript or Ruby. In fact the nature of very dynamic languages like Ruby or Python or JavaScript mean there's little point trying to AOT compile them at all because there'd be almost no optimisations you could safely do ahead of time.
readittwice 8y ago
I don't think so: TypeScript/JavaScript-Types are too coarse-grained for optimizations: For example number is a double in JS. For generating good machine code you really need to know whether the number is int or double. The same for string: Depending on the JS engine there are actually a lot of different string types. Even if we consider that good enough or somehow solved, understanding type annotations only helps you reaching peak performance faster. It doesn't really make peak performance faster. Also there are the PyPy and Dart devs that in theory could use type annotations, but both don't. For PyPy they even have an entry in the FAQ: http://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance http://doc.pypy.org/en/latest/faq.html#would-type-annotation...
- dvlsg 8y ago
  An int64 type is being added to Javascript in the near future, I believe. Of course it will take a while to be supported everywhere, but they are taking steps in that direction at least.
- masklinn 8y ago
  I think the type annotations themselves don't do anything, but the typing strongly pushes developers towards monomorphic (or at least non-megamorphic) calls sites; and having proper-ish data types may also encourages consistent order of initialisation. I don't really know about the details fo Pypy, but from what I gathered from performance talks about V8 between the hidden classes and inline caching it would strongly benefit from these behavioural changes. Basically, it doesn't preclude the runtime from having to do its analysis, but it makes the analysis & optimisations "hit" at higher rates than they would otherwise do.
- wruza 8y ago
  >For generating good machine code you really need to know whether the number is int or double Do you? I remember reading that LJ is able to infer ints for e.g. loops with no specific effort (neither performance hit).
solidr53 8y ago
Yeah, I've always wondered this too. It would be cool to be able to extract typings in a separate file, like source maps, and send over the wire along with the JavaScript bundle (for compatibility). It would definitely help moving sections of the code up the tier ladder, not unlike Web Assembly. I even predict that future typescript versions would include stricter typings optimized for an browser to solve problems like others have mentioned in the thread. Or just a TypeScript engine in the browser, like ehm Dartium. I guess someone at Microsoft already did this on IE in a hackathon or something.
- the_duke 8y ago
  I'd much prefer that optional type annotations make it into the spec, like they did for Python and PHP.
  - mxkxkucikf 8y ago
    Typescript being a superset of javascript does allow optional type annotations. RTFM.
    - syspec 8y ago
      i think they mean, make it into the JS spec.
    - yipbub 8y ago
      RTF-OP

askmike 8y ago

IMO The problem as it stands now is that when developing typescript you have a compiler running on your machine doing the typechecking. It will error out and simply not compile when you try to pass a string to a fn expecting a number. What if there is a bug (or even a misconfiguration in your project)? Or typescript changes over time (and now there are different versions all needed to be supported)? Or what if the types from typescript (designed for programmers) are not always inline with V8 internal representation of objects?) Or what if people push typescript through V8 with compile time errors? (The compiler should have prevented this from happening - but you can pump whatever you want into V8, including things considered broken by typescript). You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling). As of now there are little guarantees with the javascript language (which is what comes out of your typescript compiler). AFAIK typescript is designed to help programmers find common bugs. Not saying it's not possible, but more work is needed into bridging the two.

enitihas 8y ago
Wouldn't it be good if JavaScript also starts supporting python like type annotations (completely optional, but unlike python used to guide the optimizer. Given that some non trivial amount of JS is already generated after type checking (typescript, flow, and all the statically typed languages compiling to JS), all this compile time type info could be made available to the optimizer.
- askmike 8y ago
  For speed purposes? This post is for example already talking about how fast JS is getting without types. I'd say it would be a lot easier to simply focus on the WebAssembly format, you can write your code in a number of (typed) languages and compile into wasm which is designed to be fast. Javascript already comes with a few decades of bagage, and things are already changing really fast (ES6 and newer versions). Not everyone likes types and the people who do can use typescript (or flow). And the people who need insane performance (games, etc) can use WebAssembly.
  - enitihas 8y ago
    Yes for speed purposes. And yes some people may not like types, that's why I said completely optional. Anyways the optimizer tries to figure out the types on it's own, so give it a non blank slate to start with. You are correct in noting that js is already fast enough, but the problem is the sort of performance gotchas(order of keys in objects) as mentioned in the post aren't really obvious during development time. Types may help level the unpredictability.
- dblohm7 8y ago
  That's basically what asm.js was, just less friendly to human readers.
  - lifthrasiir 8y ago
    asm.js put a type information to every single expression node, something you would never do even in the most statically typed languages.
- conceptme 8y ago
  Python totally ignores them at runtime, PHP has this but it actually slows down the code a bit. It does make catching bugs easier.
jahewson 8y ago
I quite disagree. Look at JVM performance, there’s been huge improvements over time and a Java program compiled 20 years ago will get the same improvements as one compiled today. Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler.
- askmike 8y ago
  I very much agree with you! > You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling). I meant this in reference to runtime speed optimisations coming from types. V8 is improving every day!
- weberc2 8y ago
  > Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler. I can’t help myself, but the JVM performs at par with managed AOT languages (Go, Haskell, OCaml, etc) and strictly slower than the unmanaged AOT languages (C, C++, Rust). The JVM does outperform various AOT Java compilers, but that’s probably an artifact of the decades of optimizations that went into the JVM; the same investment in an AOT compiler would close the gap to within the margin of error. Anyway, sorry for my compulsive nitpicking; hopefully it was interesting.
  - repolfx 8y ago
    Lots of people believe this but it's false. JVM vs C++ depends very much on the code shapes and what the code is doing. C++ that's very heavy on virtual function calls can be faster written as Java. On the other hand if you use a lot of SIMD intrinsics and things like that, C++ can be a lot faster. W.R.T. AOT vs JIT, as others are pointing out, Graal is a compiler that can execute in both modes, i.e. it's a comparable compiler. JITC is about a 20% win for relatively static languages like Java and can be massively larger (like 4000%+) for other languages like JavaScript or Ruby. In fact the nature of very dynamic languages like Ruby or Python or JavaScript mean there's little point trying to AOT compile them at all because there'd be almost no optimisations you could safely do ahead of time.

readittwice 8y ago

I don't think so: TypeScript/JavaScript-Types are too coarse-grained for optimizations: For example number is a double in JS. For generating good machine code you really need to know whether the number is int or double. The same for string: Depending on the JS engine there are actually a lot of different string types. Even if we consider that good enough or somehow solved, understanding type annotations only helps you reaching peak performance faster. It doesn't really make peak performance faster. Also there are the PyPy and Dart devs that in theory could use type annotations, but both don't. For PyPy they even have an entry in the FAQ: http://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance http://doc.pypy.org/en/latest/faq.html#would-type-annotation...

dvlsg 8y ago
An int64 type is being added to Javascript in the near future, I believe. Of course it will take a while to be supported everywhere, but they are taking steps in that direction at least.
masklinn 8y ago
I think the type annotations themselves don't do anything, but the typing strongly pushes developers towards monomorphic (or at least non-megamorphic) calls sites; and having proper-ish data types may also encourages consistent order of initialisation. I don't really know about the details fo Pypy, but from what I gathered from performance talks about V8 between the hidden classes and inline caching it would strongly benefit from these behavioural changes. Basically, it doesn't preclude the runtime from having to do its analysis, but it makes the analysis & optimisations "hit" at higher rates than they would otherwise do.
wruza 8y ago
>For generating good machine code you really need to know whether the number is int or double Do you? I remember reading that LJ is able to infer ints for e.g. loops with no specific effort (neither performance hit).

solidr53 8y ago

Yeah, I've always wondered this too. It would be cool to be able to extract typings in a separate file, like source maps, and send over the wire along with the JavaScript bundle (for compatibility). It would definitely help moving sections of the code up the tier ladder, not unlike Web Assembly. I even predict that future typescript versions would include stricter typings optimized for an browser to solve problems like others have mentioned in the thread. Or just a TypeScript engine in the browser, like ehm Dartium. I guess someone at Microsoft already did this on IE in a hackathon or something.

the_duke 8y ago
I'd much prefer that optional type annotations make it into the spec, like they did for Python and PHP.
- mxkxkucikf 8y ago
  Typescript being a superset of javascript does allow optional type annotations. RTFM.
  - syspec 8y ago
    i think they mean, make it into the JS spec.
  - yipbub 8y ago
    RTF-OP