Zig starting to look nice, but compile speed is painfully slow..
Everyone wants to go after Go, but they fail to understand how important compile speed is
Everyone wants to go after Go, but they fail to understand how important compile speed is
It takes a lot of time investment to make compilation fast, and we have gone all in on this investment. There was almost an entire year when not much happened besides the compiler rewrite (which is now done). Finally, we are starting to see some fruits of our labor. Some upcoming milestones that will affect compilation speed:
* x86 backend (90% complete) - eliminates the biggest compilation speed bottleneck, which is LLVM.
* our own self-hosted ELF linker - instead of relying on LLD, we tightly couple our linker directly with the compiler in order to speed up compilation.
* incremental compilation (in place binary patching) - after this Zig will only compile functions affected by changes since the last build.
* Interned types & values. Speed up Semantic Analysis which is the remaining bottleneck of the compiler
* Introduce a separate thread for linking / machine code generation, instead of ping-ponging between Semantic Analysis & linking/mcg
* Multi-threaded semantic analysis. Attack the last remaining bottleneck of the compiler with brute force
Anyway, I won't argue with cold hard performance facts if you have some to share, but I won't stand accused of failing to prioritize compilation speed.
Based on your Milan presentation as well, I have a lot of hope that Zig is seriously pushing on this.
To write a fast compiler, it has to be fast from the start. It is extremely difficult to make a slow compiler fast because usually there are pervasive design issues that cannot be eliminated by hotspot optimization. These design decisions often reflect the design of the language itself, which is to say that some languages are more amenable to fast compilation than others and I suspect that Zig is at best average or slightly above average for languages of similar expressivity.
The focus on compilation speed is one of the reasons I'm so interested in Zig.
The compiler uses an interesting data-oriented design to represent the AST nodes, etc. You can read about it here:
- https://mitchellh.com/zig/parser#anatomy-of-an-ast-node
- https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i...
The creator of Zig also has a talk from Handmade Seattle talking about some of the performance gains they've had using these techniques:
And a talk "Zig 2023 Roadmap" that is basically all about compilation speed:
Extremely correct. In particular, if care isn't taken at the initial design phase of a language to ensure compilation isn't slow, it's likely going to end up being just that. Much in the same way untested code is likely to be incorrect.
Note that I used "isn't slow" instead of "is fast" deliberately. You don't need to, nor should, stress about low-level optimizations, you just need to get the high-level design right. A poorly written quicksort will run circles around the most optimized bubble sort.
WRT to the other backends, I was aware of them which is why I said _even with a different backend_. I don't think they have a prayer of self compiling zig in under a second with the current language design with any backend but I'd be happy to be proved wrong.
VC++ does import std in a fraction of time it takes to #include <iostream>.