Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 15, 2022 23:46 UTC (Fri) by Hello71 (guest, #103412)
In reply to: Rustaceans at the border by tialaramex
Parent article: Rustaceans at the border

> When C was invented such things would be too heavy, but today Rust's compiler and linker are certainly smart enough that if you never actually perform sort_unstable the code to implement it is omitted from your binary

afaik, unix linkers have pruned unnecessary object files from the final link for basically as long as unix has existed. this is the origin of needing to specify -l flags in dependency order. this doesn't help with dynamic linking, but rust has no magic pixie dust there either.

to post comments

Rustaceans at the border

Posted Apr 16, 2022 1:00 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (2 responses)

> unix linkers have pruned unnecessary object files from the final link for basically as long as unix has existed

Yes, but Rust goes farther. It doesn't just prune unused object files as a whole but individual functions, global data, trait implementations, and even code paths, taking advantage of static analysis across module boundaries. The closest equivalent in C would be link-time optimization, which is relatively new and not enabled by default.

Rustaceans at the border

Posted Apr 16, 2022 11:26 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Any C compiler worth its salt already can put each function into its own section, which the linker then skips if it's not referenced. This scheme has been supported by gcc/ld since, umm, whenever. It's hardly as comprehensive as LTO but gets the job done well enough for the kernel and, frankly, most other codebases that aren't heavily obfuscated C++.

Rustaceans at the border

Posted Apr 17, 2022 2:48 UTC (Sun) by willy (subscriber, #9762) [Link]

You might want to check whether CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is set in your kernel before making such confident assertions.