"The world needs better compiler tools, tools which are built as libraries. ... they must have clean APIs, be as decoupled from each other as possible, and be easy to modify/extend. ... clean layering, decent design, and avoiding tying the libraries to a specific use. ... Oh yeah, did I mention that we want the resultant libraries to be as fast as possible?" - Chris Lattner, 2007. Introduction of LLVM chris, you're a smart guy. if only you could forsee the thousands of lines of C++ code
LLVM is currently not the most important thing for compilation time in rust. LLVM is pretty well paralelized. Most of the time is spent in the frontend as it is not yet parallelized as type resulution for rust is very complex. Eg. compilation of rustc by rustc spends 2/3 of the time in the frontend on one thread. This will change in the future and when rustc's frontend is sufficiently parallel LLVM will be the bottleneck. Nightly rustc can compile rustc with 1/2 of the time spent in the frontend by doing things in parallel.
The fact that multiple languages who use LLVM and have also implemented their own backend that is orders of magnitude faster than LLVM just shows how badly optimized LLVM is
@@warvinn a couple of languages are thankfully, Rust, Jai, Zig & Odin all have plans to develop their own backends, I think most of them want to retain LLVM in some capacity due to the wide amount of platforms it supports, but for regular x64 builds they intend to replace it
2:44 with bevy one way to make it less anoying is loading a bunch of data from files.. Some even use it for ui. As to not make ui/data changes require a recompile.
LLVM is literally built with planned obsolescence, it has very high minimum requirements and multiple dependencies of specific version with even higher requirements, so it is not sustainable for long-term support at all
It's good to have alternatives but there's also the inherent complexity of making a state of the art optimizing compiler toolchain. Like you could use tcc to build almost everything, the result is wasted cycles at runtime.
I think the only reason to use it is to prototype, but if you're serious about developing a language then ideally you would write something from scratch. I'm still working on my code generator to target ARM, and that's taking me longer than I'd like, but ARM platforms are slower and so I need it to be better than LLVM. As for why I wrote my own x86 code generator, well, I know x86 assembly and it was fun. It's not as fun learning ARM assembly, but I'm also considering writing my own assembler and using Intel syntax for ARM.
Compiling loads of rust is in fact faster than compiling loads of C++ simply because copy paste include model leads to so much duplicated work. Dependencies in C++ are hard and costly that's why you have a few, rust's compiler makes having dependencies cheaper that's why you need to build 300+ crates for a nontrivial project (so it evens out at the end?)
Also to clarify - debug builds in rust are fully incremental by default except for linking (mold is a god send, highly recommend). Release builds not as much and they do thin lto by default. You can crank up the compiler to do a unit build of the whole dependency tree it makes the compile times truly miserable (I had one that took 20 minutes for a ~500 crates project) and it's still less pain than doing that with a C++ codebase of comparable size.
Not really true, because Rust took on the same problem as C++ with monomorphization. Includes cost, yes, but they're mostly costly because of templates. Well... traits have that exact same problem. Most libs, including big libs, are 99% traits. Just like most C++ libs are 99% templates. So its the same problem.
@@lucass8119 monomorphizing something once is still faster than monomorphising the same thing in every compilation unit. also it's inherent complexit, you want things not to jump through vtables most of the time.
![Chris Langan - The Interview THEY Didn't Want You To See - CTMU [Full Version; Timestamps]](http://i.ytimg.com/vi/9miVG2xT5jY/mqdefault.jpg)
![Chris Langan - The Interview THEY Didn't Want You To See - CTMU [Full Version; Timestamps]](/img/tr.png)
Any CS student can write a compiler with LLVM as a backend or even GCCs. The true feat is to design a good intermediate code and OPTIMIZING IT.
"The world needs better compiler tools, tools which are built as libraries.
... they must have clean APIs, be as decoupled from each other as possible, and be easy to modify/extend.
... clean layering, decent design, and avoiding tying the libraries to a specific use.
... Oh yeah, did I mention that we want the resultant libraries to be as fast as possible?"
- Chris Lattner, 2007. Introduction of LLVM
chris, you're a smart guy. if only you could forsee the thousands of lines of C++ code
You look like you're in high school but talk like you have a phd and ten years of experience.
He is in high school LOL. Crazy honestly, what a smart kid.
LLVM is currently not the most important thing for compilation time in rust. LLVM is pretty well paralelized. Most of the time is spent in the frontend as it is not yet parallelized as type resulution for rust is very complex. Eg. compilation of rustc by rustc spends 2/3 of the time in the frontend on one thread. This will change in the future and when rustc's frontend is sufficiently parallel LLVM will be the bottleneck. Nightly rustc can compile rustc with 1/2 of the time spent in the frontend by doing things in parallel.
The fact that multiple languages who use LLVM and have also implemented their own backend that is orders of magnitude faster than LLVM just shows how badly optimized LLVM is
And with Cranelift already usable on nightly (for linux and mac at least), Rust is already offering alternatives to llvm
@@warvinn a couple of languages are thankfully, Rust, Jai, Zig & Odin all have plans to develop their own backends, I think most of them want to retain LLVM in some capacity due to the wide amount of platforms it supports, but for regular x64 builds they intend to replace it
Lewis Thomas Garcia Elizabeth Jackson Shirley
Love these stream clips bro
2:44 with bevy one way to make it less anoying is loading a bunch of data from files.. Some even use it for ui. As to not make ui/data changes require a recompile.
You provided no reason whatsoever on why you think LLVM is slow, disliked
What else could you expect from a toolchain that starts with two L?
L
LLVM is literally built with planned obsolescence, it has very high minimum requirements and multiple dependencies of specific version with even higher requirements, so it is not sustainable for long-term support at all
It's good to have alternatives but there's also the inherent complexity of making a state of the art optimizing compiler toolchain. Like you could use tcc to build almost everything, the result is wasted cycles at runtime.
I think the only reason to use it is to prototype, but if you're serious about developing a language then ideally you would write something from scratch. I'm still working on my code generator to target ARM, and that's taking me longer than I'd like, but ARM platforms are slower and so I need it to be better than LLVM. As for why I wrote my own x86 code generator, well, I know x86 assembly and it was fun. It's not as fun learning ARM assembly, but I'm also considering writing my own assembler and using Intel syntax for ARM.
so what the alternative ? qbe? straight asm?
Everybody knows that true chads just write their own machine language. Who needs a full keyboard when all the computer understands is just 1s and 0s?
Compiling loads of rust is in fact faster than compiling loads of C++ simply because copy paste include model leads to so much duplicated work.
Dependencies in C++ are hard and costly that's why you have a few, rust's compiler makes having dependencies cheaper that's why you need to build 300+ crates for a nontrivial project (so it evens out at the end?)
Also to clarify - debug builds in rust are fully incremental by default except for linking (mold is a god send, highly recommend). Release builds not as much and they do thin lto by default. You can crank up the compiler to do a unit build of the whole dependency tree it makes the compile times truly miserable (I had one that took 20 minutes for a ~500 crates project) and it's still less pain than doing that with a C++ codebase of comparable size.
Not really true, because Rust took on the same problem as C++ with monomorphization. Includes cost, yes, but they're mostly costly because of templates. Well... traits have that exact same problem. Most libs, including big libs, are 99% traits. Just like most C++ libs are 99% templates. So its the same problem.
@@lucass8119 monomorphizing something once is still faster than monomorphising the same thing in every compilation unit.
also it's inherent complexit, you want things not to jump through vtables most of the time.