3 ms·
> but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. I don’t think that there’s any evidenc
by db48x 3y ago
> but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else.
I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html>
All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
- jchw 3y agoYeah, I was talking about C++ specifically. I am extremely skeptical you can get that much better for C++ without sacrificing performance, correctness, etc. Rust is different. It has a completely different design for translation units and modules that C++ can't adopt without hard breaking changes, due to e.g. the way its macro system works. There are teams at all of Google, Microsoft, et al that spend time on C++ build performance. At this point, it's not even necessarily just about faster build times. Their builds could be measured in environmental impact at that scale.
- thechao 3y agoI feel like there's room for C++ without headers or includes — a completely clean break.
- johntb86 3y agoMold is substantially faster than other linkers [0], so that's evidence there's still room for improvement in the C++ compiler space. It does help that there are a lot of linker features that are only used in special environments (like bare-metal systems). [0]: https://www.gem5.org/project/2023/02/16/benchmarking-linkers.html https://www.gem5.org/project/2023/02/16/benchmarking-linkers...
- jchw 3y agoMold really is a big improvement, I'll give you that. (I'm a big fan of mold, to the point where I happily joined the Github Sponsors when it went more open recently.) But, the compilation stage is a tough nut to crack.
- pjmlp 3y agoC++ also has modules.
- jchw 3y agoFor right now, this doesn't seriously help the problem, for multiple reasons. C++ modules actually tend to reduce compilation performance, since modules need to be processed before their dependents, whereas normal translation units are fully independent of each-other.
- pjmlp 3y agoIt surely does, as per Microsoft remarks doing import std; is faster than #include <iostream>. Since VC++ modules support got good enough, that all my side projects only use modules.
- ptspts 3y agoIs rustc is backward-compatible, does it typically compile .rs files written 1 year ago? 5 years ago?
- deleted 3y ago[deleted]
- db48x 3y agoRust has really great support for backward–compatibility. A few breaking changes to the language have been made over the years (such as the introduction of async/await), resulting in several different editions of the language. The compiler supports all editions equally, and different crates can even be in different editions, even if they are linked into the same program. That means that code written for Rust 1.0 still works perfectly, and there is no need to update it to the latest edition in order to continue using it even in programs that are written in the latest edition.