5 ms·

I'm a huge fan of Rust (I write in it for a living), but I still can't help wonder how they are going to tolerate the compile times. A couple of drivers...no pr

I'm a huge fan of Rust (I write in it for a living), but I still can't help wonder how they are going to tolerate the compile times. A couple of drivers...no problem, but what happens once they get a large number of drivers in Rust? Compile times will definitely start going up considerably. I wonder how much this has been considered, or possibly they have no plans to do anything this extensive?

CraigJPerry 4y ago
It might not be a big hurdle. OS developers aren’t as sensitive to compile times as app devs. An hour of futzing to bring up on a hardware dev board isn’t unheard of (although 5-10 mins would be more typical). There was a big regression in compile times in the linux 2.2 to 2.4 time frame (the kernel grew a lot of functionality) but i don’t recall it getting much more than a little grumbling. That was in the time of the Linux from Scratch book and Gentoo stage 0 builds. Some people don’t mind overnight compiles if it means they can specify just exactly the right combo of compiler flags to eeek out the max performance of their cpu.
- guenthert 4y ago
  I worked on a (legacy now) larg-ish code base (mostly C++ '03 with some self-imposed restrictions, but extensive usage of templates) for an 'embedded' system (enterprise NAS). A full build took north of 6h on the reasonable beefy desk-side workstations available to us (we considered distributed builds, but never got to test it afair). Every once in a while there was some grumbling about the build times, but it never really improved (every three years or so we got better build machines, but by that time the code base had grown as well), partly, I suspect, due to https://xkcd.com/303/ https://xkcd.com/303/ and partly because we learned to work-around that by finding the Makefile in the tree which (likely) gave us a proper build in the shortest possible time for the files we were actually working on (not being helped by the most complex Makefile tree I've ever seen). I very much doubt that such large build times would go over well in the Linux kernel community.
- yencabulator 4y ago
  Kernel compiles are a classic benchmark by which Linus has judged performance-related patches. Kernel developers do care(, mostly about incremental builds).
kibwen 4y ago
Given the disposition of kernel developers and the bespoke needs of drivers, I assume that Rust-written drivers will be neither pulling in dependencies willy-nilly nor will they be using generics all that heavily (but feel free to correct me if I assume wrongly). In that instance I don't think the Rust compilatiom process would impose any undue burden, especially since Rust can only be used for optional components of the kernel since it doesn't compile for all the targets that the kernel supports.
- sebzim4500 4y ago
  The Asahi GPU driver which is currently being developed uses a proc macro to deal with the different versions of firmware that the driver must support (i.e. fields are added/removed in firmware updates, and the driver must support both). That probably will never compile especially quickly. I'm not sure how sensitive kernel devs are to clean build times. Presumably doing a non-incremental build is relatively rare?
  - kibwen 4y ago
    > That probably will never compile especially quickly. Can you link the code? Proc macros are not inherently slow to compile, but most proc macros pull in the `syn` and `quote` crates for convenience, which are fairly heavyweight (and then most people experience proc macros most commonly via Serde, which is doing a ton of work on its own). In simple cases you can forego most of that work, and some libraries like https://github.com/Manishearth/absolution https://github.com/Manishearth/absolution exist as lightweight alternatives in these cases. Depending on what the Asahi driver needs it could also benefit from something like this (although without seeing the code I'm not sure why it would need proc macros when it sounds like conditional compilation via `cfg` would suffice there).
- loeg 4y ago
  A big source of compile time used to be proc macros — the kernel could just disallow those?
- Matthias247 4y ago
  If you watch the actual talk and check code at https://github.com/Rust-for-Linux https://github.com/Rust-for-Linux you will see that it’s actually pretty heavy on generics and macros. Eg for the trait that defines file system operations (https://github.com/Rust-for-Linux/linux/blob/459035ab65c0ebb8d7054b24b6c00de907819eb2/rust/kernel/file.rs#L774 https://github.com/Rust-for-Linux/linux/blob/459035ab65c0ebb...) and other bindings to C code. I was actually surprised of seeing those, since they certainly don’t help with telling people a story that Rust is an easy language. But it’s probably the best one can do when having to interface with predefined APIs. But You are certainly right in that external dependencies won’t be an issue.
Gwypaas 4y ago
For the professional work I have done in Rust the compile times are workable when using cargo workspaces and incremental compilation. Making sure to when possible work directly in a member crate compiling only that for the iteration cycle. That requires a DAG structure for all dependencies so does not work everywhere. Getting CI up to speed is a completely different (awful) topic.
playdmc2 4y ago
increased compile times are a reasonable tradeoff for correctness, no? hardware can always be thrown at the problem. as soon as someone does a c oopsie you're going to lose whatever time you saved to debugging
Groxx 4y ago
When tightly controlled, Rust compilation times are quite good. Without attention it can bloat tremendously with proc macros and excessive generics (turn them into dyns!), but it's totally manageable. Depending on your corners of the ecosystem, your default experience could be a few orders of magnitude better or worse than someone else's.
- nu11ptr 4y ago
  I haven't done much experimentation, but I've heard the same. Currently, for new projects I try to design with as many crates as possible in order to a) keep them small b) make as many 'spokes' (aka not dependent on other crates) as possible. This helps a ton and something I wish I'd have known before starting some of my large projects. I also wish I had used more trait objects and less generics - the overhead rarely matters in practice.
  - Groxx 4y ago
    Traits vs generics: yeah, personally I hope to one day see a language that allows application developers to decide what gets monomorphized, rather than library developers. It seems like you could usually just synthesize the boxing needed. So why would you ever leave that choice in the library's hands, which has no idea how it will be used?
  - rane 4y ago
    Mind expanding on the b) a bit? If by that you mean writing things from scratch instead of pulling a dependency that does it already, it sounds a bit counterintuitive.
    - Groxx 4y ago
      I believe they mean spokes as opposed to "wheels with other spokes", i.e. leaves vs trees. The best dependency trees are as short and wide as possible. It means fewer changes with each upgrade, fewer chances of conflicts between them, and generally more-parallel compilation and better build caching. Which is true in every language, but every community seems to need to relearn it from scratch.

CraigJPerry 4y ago

It might not be a big hurdle. OS developers aren’t as sensitive to compile times as app devs. An hour of futzing to bring up on a hardware dev board isn’t unheard of (although 5-10 mins would be more typical). There was a big regression in compile times in the linux 2.2 to 2.4 time frame (the kernel grew a lot of functionality) but i don’t recall it getting much more than a little grumbling. That was in the time of the Linux from Scratch book and Gentoo stage 0 builds. Some people don’t mind overnight compiles if it means they can specify just exactly the right combo of compiler flags to eeek out the max performance of their cpu.

guenthert 4y ago
I worked on a (legacy now) larg-ish code base (mostly C++ '03 with some self-imposed restrictions, but extensive usage of templates) for an 'embedded' system (enterprise NAS). A full build took north of 6h on the reasonable beefy desk-side workstations available to us (we considered distributed builds, but never got to test it afair). Every once in a while there was some grumbling about the build times, but it never really improved (every three years or so we got better build machines, but by that time the code base had grown as well), partly, I suspect, due to https://xkcd.com/303/ https://xkcd.com/303/ and partly because we learned to work-around that by finding the Makefile in the tree which (likely) gave us a proper build in the shortest possible time for the files we were actually working on (not being helped by the most complex Makefile tree I've ever seen). I very much doubt that such large build times would go over well in the Linux kernel community.
yencabulator 4y ago
Kernel compiles are a classic benchmark by which Linus has judged performance-related patches. Kernel developers do care(, mostly about incremental builds).

kibwen 4y ago

Given the disposition of kernel developers and the bespoke needs of drivers, I assume that Rust-written drivers will be neither pulling in dependencies willy-nilly nor will they be using generics all that heavily (but feel free to correct me if I assume wrongly). In that instance I don't think the Rust compilatiom process would impose any undue burden, especially since Rust can only be used for optional components of the kernel since it doesn't compile for all the targets that the kernel supports.

sebzim4500 4y ago
The Asahi GPU driver which is currently being developed uses a proc macro to deal with the different versions of firmware that the driver must support (i.e. fields are added/removed in firmware updates, and the driver must support both). That probably will never compile especially quickly. I'm not sure how sensitive kernel devs are to clean build times. Presumably doing a non-incremental build is relatively rare?
- kibwen 4y ago
  > That probably will never compile especially quickly. Can you link the code? Proc macros are not inherently slow to compile, but most proc macros pull in the `syn` and `quote` crates for convenience, which are fairly heavyweight (and then most people experience proc macros most commonly via Serde, which is doing a ton of work on its own). In simple cases you can forego most of that work, and some libraries like https://github.com/Manishearth/absolution https://github.com/Manishearth/absolution exist as lightweight alternatives in these cases. Depending on what the Asahi driver needs it could also benefit from something like this (although without seeing the code I'm not sure why it would need proc macros when it sounds like conditional compilation via `cfg` would suffice there).
loeg 4y ago
A big source of compile time used to be proc macros — the kernel could just disallow those?
Matthias247 4y ago
If you watch the actual talk and check code at https://github.com/Rust-for-Linux https://github.com/Rust-for-Linux you will see that it’s actually pretty heavy on generics and macros. Eg for the trait that defines file system operations (https://github.com/Rust-for-Linux/linux/blob/459035ab65c0ebb8d7054b24b6c00de907819eb2/rust/kernel/file.rs#L774 https://github.com/Rust-for-Linux/linux/blob/459035ab65c0ebb...) and other bindings to C code. I was actually surprised of seeing those, since they certainly don’t help with telling people a story that Rust is an easy language. But it’s probably the best one can do when having to interface with predefined APIs. But You are certainly right in that external dependencies won’t be an issue.

Gwypaas 4y ago

For the professional work I have done in Rust the compile times are workable when using cargo workspaces and incremental compilation. Making sure to when possible work directly in a member crate compiling only that for the iteration cycle. That requires a DAG structure for all dependencies so does not work everywhere. Getting CI up to speed is a completely different (awful) topic.

playdmc2 4y ago

increased compile times are a reasonable tradeoff for correctness, no? hardware can always be thrown at the problem. as soon as someone does a c oopsie you're going to lose whatever time you saved to debugging

Groxx 4y ago

When tightly controlled, Rust compilation times are quite good. Without attention it can bloat tremendously with proc macros and excessive generics (turn them into dyns!), but it's totally manageable. Depending on your corners of the ecosystem, your default experience could be a few orders of magnitude better or worse than someone else's.

nu11ptr 4y ago
I haven't done much experimentation, but I've heard the same. Currently, for new projects I try to design with as many crates as possible in order to a) keep them small b) make as many 'spokes' (aka not dependent on other crates) as possible. This helps a ton and something I wish I'd have known before starting some of my large projects. I also wish I had used more trait objects and less generics - the overhead rarely matters in practice.
- Groxx 4y ago
  Traits vs generics: yeah, personally I hope to one day see a language that allows application developers to decide what gets monomorphized, rather than library developers. It seems like you could usually just synthesize the boxing needed. So why would you ever leave that choice in the library's hands, which has no idea how it will be used?
- rane 4y ago
  Mind expanding on the b) a bit? If by that you mean writing things from scratch instead of pulling a dependency that does it already, it sounds a bit counterintuitive.
  - Groxx 4y ago
    I believe they mean spokes as opposed to "wheels with other spokes", i.e. leaves vs trees. The best dependency trees are as short and wide as possible. It means fewer changes with each upgrade, fewer chances of conflicts between them, and generally more-parallel compilation and better build caching. Which is true in every language, but every community seems to need to relearn it from scratch.