4 ms·

Note that that step sheds libc entirely (so the binary needs to provide the minimal things that libc does for your platform, namely that assembly you mention, a

Note that that step sheds libc entirely (so the binary needs to provide the minimal things that libc does for your platform, namely that assembly you mention, and you'd have to do the same for a C binary that did that) and gets rid of 3kb (16kb -> 13kb), but changing the linker flags to avoid page-aligning the binary brings it down to 400 bytes. I would have loved if the author had tried that on the libc version too, just for comparison's sake. In a lot of conversations around Rust binary sizes some people extrapolate from the "Hello, World!" size difference as if the additional cost on top of a bare C binary was linear, when in reality it is (approximately) a constant cost. That on top of completely disregarding that the "bloat" is doing something (panic machinery, string formatting, DWARF symbol storage, DWARF symbol parsing, etc.).

tremon 3y ago
It's definitely not a constant cost, presumably due to the link-time optimization that rustc does. I've had binaries go from 800kB to 6MB simply by switching from getopts to the clap crate, for example.
- pornel 3y ago
  Binary using clap with all the bells and whistles, even without LTO, is 900KB after strip. The standard library has 4MB of debug info baked in, which due to its special integration with Cargo is always added, even when you explicitly configure `debug=false`. This is what usually surprises people and makes Rust executables seem huge.
LtWorf 3y ago
So it doesn't strip unneeded stuff?
joseluis 3y ago
I found that the stripping of the libc made impossible for me to manage signals that didn't exit the program. E.g. Sigint worked fine as long as the callback didnt return to the caller but e.g. trying to use Sigwinch or sigcontinue segfaulted and I never found a way to make that work from scratch in this type of binaries without linking to libc... I wonder if that's even possible.
userbinator 3y ago
That on top of completely disregarding that the "bloat" is doing something (panic machinery, string formatting, DWARF symbol storage, DWARF symbol parsing, etc.). The point is that it'll never be doing something, and the compiler can clearly see that, but decides to add that dead code anyway.
- estebank 3y ago
  Printing to stdout is a fallible operation.
  - userbinator 3y ago
    What do you do if it fails, print a message to stdout saying that it failed? ...and what if that fails?
    - estebank 3y ago
      println can panic, which by default tries to print to stderr, which can succeed independently of the state of stdout, and the global panic handler can be overriden to write to a log file, pipe an event to a port or just abort. But specialising the panic handler to instead only abort for the specific case where the only reason for a panic would be println is gold plating of the highest order. Adding complexity to the compiler and language to code golf the hello world binary size because 260kb is too much bloat is time I'd rather spend doing things that help the 99.99999% of other cases.

tremon 3y ago

It's definitely not a constant cost, presumably due to the link-time optimization that rustc does. I've had binaries go from 800kB to 6MB simply by switching from getopts to the clap crate, for example.

pornel 3y ago
Binary using clap with all the bells and whistles, even without LTO, is 900KB after strip. The standard library has 4MB of debug info baked in, which due to its special integration with Cargo is always added, even when you explicitly configure `debug=false`. This is what usually surprises people and makes Rust executables seem huge.

LtWorf 3y ago

So it doesn't strip unneeded stuff?

joseluis 3y ago

I found that the stripping of the libc made impossible for me to manage signals that didn't exit the program. E.g. Sigint worked fine as long as the callback didnt return to the caller but e.g. trying to use Sigwinch or sigcontinue segfaulted and I never found a way to make that work from scratch in this type of binaries without linking to libc... I wonder if that's even possible.

userbinator 3y ago

That on top of completely disregarding that the "bloat" is doing something (panic machinery, string formatting, DWARF symbol storage, DWARF symbol parsing, etc.). The point is that it'll never be doing something, and the compiler can clearly see that, but decides to add that dead code anyway.

estebank 3y ago
Printing to stdout is a fallible operation.
- userbinator 3y ago
  What do you do if it fails, print a message to stdout saying that it failed? ...and what if that fails?
  - estebank 3y ago
    println can panic, which by default tries to print to stderr, which can succeed independently of the state of stdout, and the global panic handler can be overriden to write to a log file, pipe an event to a port or just abort. But specialising the panic handler to instead only abort for the specific case where the only reason for a panic would be println is gold plating of the highest order. Adding complexity to the compiler and language to code golf the hello world binary size because 260kb is too much bloat is time I'd rather spend doing things that help the 99.99999% of other cases.