One comparison is with JavaScript: for a long time there was an assumption that a lot of optimizations were just inapplicable given the lack of a type system and everything, until eventually we found a way to do them.
Yes but this only goes so far … I wrote a little rant here about how AOT compilation (Rust, C++, Go) is better for a big class of problems, basically anything in involving languages – interpreters, type checkers, formatters, linters
To be controversial, JITs have “failed”, otherwise we wouldn’t be rewriting a lot of code. Emery Berger frames Perl / Python / JS / PHP as the “irrational exuberance” languages
The canonical example being that the TypeScript compiler would be a lot faster if it wasn’t running on a JavaScript runtime. All that type info is thrown away, and doesn’t contribute to speed.
Many people are rewriting these tools in AOT languages (esbuild in Go, etc.) and that choice makes a lot of sense. Python has a lot of really slow tools like Black and or yapf, compared with clang-format.
For Oils we wrote a Python-to-C++ translator that uses MyPy static types. It was more work to make the source program 100% statically typed, vs. trying to get a JIT to do it, but it’s way faster, and uses way less memory [1]. We basically have garbage-collected C++ semantics and not Python semantics (but Python syntax). So it’s all AOT, and no JIT at all.
I still prefer an interpreter-like development experience, and I like dynamic languages for metaprogramming. But if the concern is speed, then AOT compilation with static types is just better IMO. (For numeric problems, the pattern where you use Python to generate an IR and then compile/parallelize/GPU it is still AOT, so it’s true that you have to look more carefully, and can’t just go by the language)
To be fair to JIT folks, in their niche JITs seem to help. But AOTs and AOT-friendly languages obviously are not going anywhere and mycpp looks fascinating.
Not saying The Way is to sneak optimizations into languages that aren’t friendly to them, really just that the absolute ‘can’t X without Y’ can be tricky when sometimes life, uh, finds a way.
For some more color, I get a strong impression that the v8 codebase is monstrously complex, and kind of “topped out” several years ago.
That is, trying to make it faster now is like squeezing blood out of a stone. It seems impressive but I think under the hood it’s strained - https://v8.dev/blog
v8 is at least 2 million lines of code now, it’s probably almost the size of GCC or Clang.
I’ve been watching videos on WebAssembly for the past few years, and two of the co-creators Andreas Rossberg and Ben Titzer were also tech leads of v8. (WASM is basically JavaScript JITs in the browser given an alternative front end that’s not JS. My rough version of the history at the end of this comment - https://lobste.rs/s/djxada/missing_point_webassembly#c_dveoie )
It’s honestly a little surprising to me how much they throw shade at v8 :-P It sounds like they regret the state of the codebase, and it was not fun to work in.
On the other hand, mycpp is like a 5000 line Python program that prints C++. It’s dirt simple and naive (since I don’t really know how to write compilers), but it results in very fast code. As long as we can correctly print C++ types, then the C++ compiler does all the work.
So naively that’s 2M lines vs. 5000 lines, or a 400x code size difference. Honestly that sounds roughly right – v8 is more the product of 400 engineers, while mycpp is like 1.
But mycpp is much faster, just because it does straightforward AOT.
The tradeoff of course is that it took us quite awhile to make the Oils statically typed, so this technique is possible. Definitely longer than I thought, for a relatively small codebase. But there was really no other option, since it’s not like we will write a JIT … that is a crazy amount of engineering
Yes but this only goes so far … I wrote a little rant here about how AOT compilation (Rust, C++, Go) is better for a big class of problems, basically anything in involving languages – interpreters, type checkers, formatters, linters
https://news.ycombinator.com/item?id=35045520
To be controversial, JITs have “failed”, otherwise we wouldn’t be rewriting a lot of code. Emery Berger frames Perl / Python / JS / PHP as the “irrational exuberance” languages
The canonical example being that the TypeScript compiler would be a lot faster if it wasn’t running on a JavaScript runtime. All that type info is thrown away, and doesn’t contribute to speed.
Many people are rewriting these tools in AOT languages (esbuild in Go, etc.) and that choice makes a lot of sense. Python has a lot of really slow tools like Black and or yapf, compared with clang-format.
For Oils we wrote a Python-to-C++ translator that uses MyPy static types. It was more work to make the source program 100% statically typed, vs. trying to get a JIT to do it, but it’s way faster, and uses way less memory [1]. We basically have garbage-collected C++ semantics and not Python semantics (but Python syntax). So it’s all AOT, and no JIT at all.
Brief Descriptions of a Python to C++ Translator
I still prefer an interpreter-like development experience, and I like dynamic languages for metaprogramming. But if the concern is speed, then AOT compilation with static types is just better IMO. (For numeric problems, the pattern where you use Python to generate an IR and then compile/parallelize/GPU it is still AOT, so it’s true that you have to look more carefully, and can’t just go by the language)
[1] e.g. https://www.oilshell.org/release/0.20.0/benchmarks.wwz/mycpp-examples/
score 3 · canonical
To be fair to JIT folks, in their niche JITs seem to help. But AOTs and AOT-friendly languages obviously are not going anywhere and mycpp looks fascinating.
Not saying The Way is to sneak optimizations into languages that aren’t friendly to them, really just that the absolute ‘can’t X without Y’ can be tricky when sometimes life, uh, finds a way.
score 2 · canonical
For some more color, I get a strong impression that the v8 codebase is monstrously complex, and kind of “topped out” several years ago.
That is, trying to make it faster now is like squeezing blood out of a stone. It seems impressive but I think under the hood it’s strained - https://v8.dev/blog
v8 is at least 2 million lines of code now, it’s probably almost the size of GCC or Clang.
I’ve been watching videos on WebAssembly for the past few years, and two of the co-creators Andreas Rossberg and Ben Titzer were also tech leads of v8. (WASM is basically JavaScript JITs in the browser given an alternative front end that’s not JS. My rough version of the history at the end of this comment - https://lobste.rs/s/djxada/missing_point_webassembly#c_dveoie )
It’s honestly a little surprising to me how much they throw shade at v8 :-P It sounds like they regret the state of the codebase, and it was not fun to work in.
On the other hand, mycpp is like a 5000 line Python program that prints C++. It’s dirt simple and naive (since I don’t really know how to write compilers), but it results in very fast code. As long as we can correctly print C++ types, then the C++ compiler does all the work.
So naively that’s 2M lines vs. 5000 lines, or a 400x code size difference. Honestly that sounds roughly right – v8 is more the product of 400 engineers, while mycpp is like 1.
But mycpp is much faster, just because it does straightforward AOT.
The tradeoff of course is that it took us quite awhile to make the Oils statically typed, so this technique is possible. Definitely longer than I thought, for a relatively small codebase. But there was really no other option, since it’s not like we will write a JIT … that is a crazy amount of engineering
score 2 · canonical