On: The Linux Kernel Prepares for Rust 1.77 Upgrade

[mcqueenjordan]

Another thing just to mention here is `strip`, which IIRC `cargo build --release` doesn't do by default. I think `stripping` binaries can reduce binary size by up to 80-85% in some cases (but certainly not all; just tried it locally on a 1M rust binary and got 40% reduction).

FWIW, you can configure this in Cargo.toml:

[profile.release] strip = true

[nindalf → mcqueenjordan]

Check out Making Rust binaries smaller by default (https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-b...). Previously discussed a few weeks ago at https://news.ycombinator.com/item?id=39112486.

That change will be live on 21st March, so manual strips won't be required after that.

[habibur → mcqueenjordan]

You can strip C compiled binaries too. And that halves the binary size. The point is for example a hello world Rust binaries is 300kb after striping while C compiled one is 15kb. A difference of 20 times.

[pornel → habibur]

Such comparison exaggerates the difference, because it’s a one-time constant overhead, not a multiplicative overhead.

i.e. all programs are larger by 275KB, not larger by 20x.

Rust doesn’t have the privilege of having a system-wide shared stdlib to make hello world executables equally small.

The overhead comes from Rust having more complex type-safe printf, and error handling code for when the print fails. C doesn’t handle the print error, and C doesn’t print stack traces on error. Most of that 200KB Rust overhead is a parser for dwarf debug info to print the stack trace.

[estebank → habibur]

You might be interested in reading https://darkcoding.net/software/a-very-small-rust-binary-ind...

[Narishma → habibur]

But C doesn't statically link the standard library by default like Rust does.

[habibur → Narishma]

Hello world deps for C :

    linux-vdso.so.1 (0x00007fff25cb8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fe5f08d9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe5f0ae2000)

And for Rust

    linux-vdso.so.1 (0x00007ffc109f9000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8eda404000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f8eda222000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8eda4a8000)

Rather Rust has 1 more dynamically linked library than C.

[fl0ki → habibur]

That might be true for Hello World, but libgcc_s is where a lot of builtins for C itself go, so you'll find it ends up linked into a lot of non-trivial C programs as well. See https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

[Kamq → habibur]

You missed the word "statically" in the post you commented on.

Dynamically linked libs rarely contribute heavily to binary bloat

[habibur → Kamq]

The benefit of statically linking becomes moot when it doesn't reduce the number of dynamically linked libraries. That's the point.

[Dylan16807 → habibur]

That's not why rust statically links the runtime. The main benefit is that they don't have to try to design and maintain a stable ABI for it. Which is not moot.

More generally, you statically link something to avoid distribution hassles of various kinds, not because you care about the specific number.