This is a great story. I wish it ended with some comparison of the impact of this change in terms of code size and runtime performance.
I just played around with GCC’s LTO and found that it supports cross-language inlining at least. Unfortunately there’s no Rust frontend for GCC so I learned enough Fortran to call a method and print the result and verified that it does a good job of that when you pass -flto to gfortran and gcc.
If you cared about compile times you wouldn’t be using Rust. The theory is that the language and other tooling will make up for any developer productivity losses from slow compiles.
Rust users and compiler developers do care about compile times. Current situation is not pleasant, but as usual with Rust, there’s ongoing work to have the cake and eat it too.
This is a great story. I wish it ended with some comparison of the impact of this change in terms of code size and runtime performance.
I just played around with GCC’s LTO and found that it supports cross-language inlining at least. Unfortunately there’s no Rust frontend for GCC so I learned enough Fortran to call a method and print the result and verified that it does a good job of that when you pass
-fltotogfortranandgcc.Rust certainly does add lots of wrapping calls to everything, nice to remove them via inlining, even if it still probably means slower compile times.
If you cared about compile times you wouldn’t be using Rust. The theory is that the language and other tooling will make up for any developer productivity losses from slow compiles.
And don’t turn LTO on outside of release builds.
Rust users and compiler developers do care about compile times. Current situation is not pleasant, but as usual with Rust, there’s ongoing work to have the cake and eat it too.