5 ms·

Will be interesting to see how much compile times suffer once rust starts being used more heavily in the kernel. In my gentoo days I remember the compile time

Will be interesting to see how much compile times suffer once rust starts being used more heavily in the kernel. In my gentoo days I remember the compile time for firefox suddenly going up from 20 minutes to several hours which left a sour taste in my mouth with regards to rust. Has there been much improvement in compile times in the past ~2 years?

Ericson2314 5y ago
Insofar that it is a bunch of driver "leaves" for the forseable future, it should more embarrassing parallel.
adgjlsfhk1 5y ago
TLDR, yes https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed-up-the-rust-compiler-one-last-time/ https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed...
swsieber 5y ago
Roughly dropped by about 30% or more? Here's a dashboard that tracks times of certain benchmark tasks by compiler version: https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros. And as someone else mentioned, things should be able to be compiled in parallel. Also, some crates for firefox are absurdly huge in terms of compile times - they are definitely outliers (IIUC). (Edit: I was thinking of this issue in Servo, so not definitely firefox releated: https://github.com/servo/servo/issues/1799 https://github.com/servo/servo/issues/1799)
- loeg 5y ago
  In particular proc macros are slow; regular macros less so.
  - nicoburns 5y ago
    And specifically proc-macros that parse rust-like syntax. It's the `syn` library that's slow. Proc macros that have a custom parser tend to be quite fast.
    - the_duke 5y ago
      Interesting, I always assumed that syn was fast enough to not be a bottleneck. Do you have some related benchmarks, eg comparing it to the rustc and rust-analyzer parsers?
      - nicoburns 5y ago
        I don't, but I've definitely seen examples of non-syn proc macros that were super-fast.
      - matklad 5y ago
        This is more nuanced, as there are three separate components: * time to compile the syn itself * time to run syn on the inputs * time to compile whatever syn generated I didn’t do a super thorough studies of things, but my impression is that 2, performance of syn itself, is rarely an issue. Most of the time it is 1) (and the associated problem of decreased build parallelism because half of the crates wait for syn to compile) and 3). To get a feeling how costly a simple proc macro is, run this benchmark: https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037bc0925a6a84174566eb1/tests/it/main.rs#L441 https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....
- seoaeu 5y ago
  Yes, servo is an outlier. But it also apparently isn’t that bad: > Building it takes almost 40 seconds
- Asraelite 5y ago
  > Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros There's a lot of unavoidable generic types like Option, Result, RefCell etc. Do these make up any significant part of the issue with compile times?
- nindalf 5y ago
  That page averages all the builds across different code bases. It doesn’t specify which version/tag of which code base, nor does it talk about the hardware. https://arewefastyet.pages.dev/ https://arewefastyet.pages.dev/ - This page tracks compile times across some common crates over all supported compiler versions, with different hardware (2, 4, 8, 16 cores). This used to be https://arewefastyet.rs https://arewefastyet.rs but the domain expired. The tldr - speed ups of between 25-30% in these crates over the last 3 years.
  - NextHendrix 5y ago
    Thanks for the interesting link, looks like on the whole build times have been coming down. One interesting observation is that helloworld now takes about 4 times longer[0] (though only to 0.8 seconds). What could have caused this? [0] https://i.imgur.com/O3viDc8.png https://i.imgur.com/O3viDc8.png
    - nindalf 5y ago
      I’m not really sure. But since it’s stayed under a second I guess it’s not a huge deal. Also, it’s possible that the last few releases might have sped it up a bit. That page only tracks till 1.52. I believe the latest release is 1.57.
    - adgjlsfhk1 5y ago
      If you do setup that in general saves time, small things sometimes won't benefit.
howdydoo 5y ago
>Has there been much improvement in compile times in the past ~2 years? Yes. Source: https://nnethercote.github.io/2021/11/12/the-rust-compiler-has-gotten-faster-again.html https://nnethercote.github.io/2021/11/12/the-rust-compiler-h... In my experience, compile times are more a function of project structure than anything else. The compilation unit is a crate, so keep your crates nice and small, and you'll be fine.
xyproto 5y ago
There has been many improvements, but it's still slow compared to ie. Go.
filmor 5y ago
I think that jump was due to lto (link time optimsation) getting activated by default for Firefox on Gentoo around that time. It looked very strange at first, because the build log just pauses while the lto passes hog a lot of cpu and memory for 20min or so. Rust has been in Firefox for about 5 years now, I think.
agumonkey 5y ago
I think rust will also have an effect on C drivers. People will rewrite their code to match safety levels. Even without rust based driver on your system you might benefit without compilation time penalty.
kingcharles 5y ago
Security > Kernel compile time

Ericson2314 5y ago

Insofar that it is a bunch of driver "leaves" for the forseable future, it should more embarrassing parallel.

adgjlsfhk1 5y ago

TLDR, yes https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed-up-the-rust-compiler-one-last-time/ https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed...

swsieber 5y ago

Roughly dropped by about 30% or more? Here's a dashboard that tracks times of certain benchmark tasks by compiler version: https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros. And as someone else mentioned, things should be able to be compiled in parallel. Also, some crates for firefox are absurdly huge in terms of compile times - they are definitely outliers (IIUC). (Edit: I was thinking of this issue in Servo, so not definitely firefox releated: https://github.com/servo/servo/issues/1799 https://github.com/servo/servo/issues/1799)

loeg 5y ago
In particular proc macros are slow; regular macros less so.
- nicoburns 5y ago
  And specifically proc-macros that parse rust-like syntax. It's the `syn` library that's slow. Proc macros that have a custom parser tend to be quite fast.
  - the_duke 5y ago
    Interesting, I always assumed that syn was fast enough to not be a bottleneck. Do you have some related benchmarks, eg comparing it to the rustc and rust-analyzer parsers?
    - nicoburns 5y ago
      I don't, but I've definitely seen examples of non-syn proc macros that were super-fast.
    - matklad 5y ago
      This is more nuanced, as there are three separate components: * time to compile the syn itself * time to run syn on the inputs * time to compile whatever syn generated I didn’t do a super thorough studies of things, but my impression is that 2, performance of syn itself, is rarely an issue. Most of the time it is 1) (and the associated problem of decreased build parallelism because half of the crates wait for syn to compile) and 3). To get a feeling how costly a simple proc macro is, run this benchmark: https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037bc0925a6a84174566eb1/tests/it/main.rs#L441 https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....
seoaeu 5y ago
Yes, servo is an outlier. But it also apparently isn’t that bad: > Building it takes almost 40 seconds
Asraelite 5y ago
> Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros There's a lot of unavoidable generic types like Option, Result, RefCell etc. Do these make up any significant part of the issue with compile times?
nindalf 5y ago
That page averages all the builds across different code bases. It doesn’t specify which version/tag of which code base, nor does it talk about the hardware. https://arewefastyet.pages.dev/ https://arewefastyet.pages.dev/ - This page tracks compile times across some common crates over all supported compiler versions, with different hardware (2, 4, 8, 16 cores). This used to be https://arewefastyet.rs https://arewefastyet.rs but the domain expired. The tldr - speed ups of between 25-30% in these crates over the last 3 years.
- NextHendrix 5y ago
  Thanks for the interesting link, looks like on the whole build times have been coming down. One interesting observation is that helloworld now takes about 4 times longer[0] (though only to 0.8 seconds). What could have caused this? [0] https://i.imgur.com/O3viDc8.png https://i.imgur.com/O3viDc8.png
  - nindalf 5y ago
    I’m not really sure. But since it’s stayed under a second I guess it’s not a huge deal. Also, it’s possible that the last few releases might have sped it up a bit. That page only tracks till 1.52. I believe the latest release is 1.57.
  - adgjlsfhk1 5y ago
    If you do setup that in general saves time, small things sometimes won't benefit.

howdydoo 5y ago

>Has there been much improvement in compile times in the past ~2 years? Yes. Source: https://nnethercote.github.io/2021/11/12/the-rust-compiler-has-gotten-faster-again.html https://nnethercote.github.io/2021/11/12/the-rust-compiler-h... In my experience, compile times are more a function of project structure than anything else. The compilation unit is a crate, so keep your crates nice and small, and you'll be fine.

xyproto 5y ago

There has been many improvements, but it's still slow compared to ie. Go.

filmor 5y ago

I think that jump was due to lto (link time optimsation) getting activated by default for Firefox on Gentoo around that time. It looked very strange at first, because the build log just pauses while the lto passes hog a lot of cpu and memory for 20min or so. Rust has been in Firefox for about 5 years now, I think.

agumonkey 5y ago

I think rust will also have an effect on C drivers. People will rewrite their code to match safety levels. Even without rust based driver on your system you might benefit without compilation time penalty.

kingcharles 5y ago

Security > Kernel compile time