> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums
Is this really a thing? Do C folks make fun of Rust?
Making Rust binaries smaller by default
81–90 of 199 posts
Re: Making Rust binaries smaller by default
#82So what's in the remaining huge 415KB hello world program? Can we get rid of 90% of it a couple more times?
Buffered I/O and synchronization primitives to avoid corrupting the buffer. The underlying vector implementation and memory allocator. Panic support and backtrace printer, which includes a Rust-specific name demangler and a not-so-small DWARF parser in Linux. Path support because backtraces would include source file paths. Zlib-compatible decompressor because ELF allows compressed sections (!). Then you have several…
> several formatters that are often pretty large (e.g. f32 and f64 would add at least 30 KB of binary …)
I know floats are full of scary corner cases, but… Assuming tens of bytes per an if statement, hundreds of corner cases just in formatting? Is it really that bad?
Re: Making Rust binaries smaller by default
#83Earlier quoted context omitted.
Additionally the panic = "abort" disables stack unwinding, and running destructors when panic occurs, so it's a big change to the semantics of the program. It's comparable to C++ land -fno-exceptions (not exactly, but similar).
IMHO when a piece of code decides to panic it should only happen when execution cannot continue under any circumstances, and in such cases all bets are off whether any cleanup code would actually still work. A hard abort might indeed be the best option.
That seems overly pessimistic (or perhaps overly optimistic about code that does not panic). Panics mostly exist to guard code from entering into such unrecoverable states, eg writing past the end of an array.
Re: Making Rust binaries smaller by default
#84> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?
People can be quite tribal. Especially the ones who haven't taken the time to learn what the other tribe is up to and why.
Re: Making Rust binaries smaller by default
#85> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?
What is this “C programmer” you speak of?
Anyone who’s been doing this for long enough is a polyglot.
Re: Making Rust binaries smaller by default
#86I was wondering if dead code elimination also removes the debug symbols related to the dead code?
The ~ 4 MiB of debug symbols the article talks about are for the whole libstd or just the portions that actually ended up in the binary?
I think the new default makes sense but I'd love to have the option to build a lean but debuggable release binary with just the needed symbols.
Re: Making Rust binaries smaller by default
#87Earlier quoted context omitted.
Buffered I/O and synchronization primitives to avoid corrupting the buffer. The underlying vector implementation and memory allocator. Panic support and backtrace printer, which includes a Rust-specific name demangler and a not-so-small DWARF parser in Linux. Path support because backtraces would include source file paths. Zlib-compatible decompressor because ELF allows compressed sections (!). Then you have several…
> several formatters that are often pretty large (e.g. f32 and f64 would add at least 30 KB of binary …) I know floats are full of scary corner cases, but… Assuming tens of bytes per an if statement, hundreds of corner cases just in formatting? Is it really that bad?
A naive implementation would be small, but a correct implementation (with some concrete definition of "correct") will need a sizable data table. I know this because I wrote that part of code [1] and somehow it is still in the std even though other algorithms now exist [2].
Re: Making Rust binaries smaller by default
#88> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?
What is this “C programmer” you speak of? Anyone who’s been doing this for long enough is a polyglot.
That mirrors my experience. I've hardly ever met really experienced people that are hardstuck on language flaming. Programming languages are tools, with general and situational up and downsides.
Re: Making Rust binaries smaller by default
#89Earlier quoted context omitted.
Comparing with the current Cargo default [1]: • `panic = "abort"` means that any panic terminates the program. This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. • `strip = true` means that anything depending on DWARF would no longer work. Backtraces won't work, but also unwinding will no longer work (so this is disastrous if you haven't set `pani…
All makes sense, but I don't agree with: > This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). For a server process the…
> IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling).
Rust panic is just a C++ exception in its implementation, and not every C++ programmer would terminate a process when an exception is thrown. Of course Rust panic is more resillient because Rust provides a memory safety and the logic error can be reasonably bounded as a result.
> Increased build time is acceptable for release mode IMHO.
I think the slowest possible configuration is at least 3x slower than the default, and that's too slow to be acceptable for most people. But you can always tune them up if you want---please note that this issue is all about defaults.
Re: Making Rust binaries smaller by default
#90Earlier quoted context omitted.
This program is not same to the Rust version. A more faithful version, assuming glibc, would look like this: #include #include #include #include void print_backtrace(void) { void *traces[50]; char **symbols; int num_traces, i; num_traces = backtrace(traces, sizeof(traces) / sizeof(*traces)); strings = backtrace_symbols(traces, num_traces); if (!strings) return; for (i = 0; i While this is still substantially differen…
Building your code (I fixed a few typos, strings -> symbols, fprintf(" -> fprintf(stderr, ") with gcc -s -Os -fuse-ld=lld a.c && ls -al a.out leads to a 5496 bytes ELF though. Which is not much larger than just printf("Hello World!\n"), see sibling comment. I think the point is C "cheated" by including a lot of goodness (format, backtrace etc) in the shared library so they does not have to be copied to each binary.
Thank you for the actual testing (and sorry for typos...). Yes, a C version is small because it dynamically links to libc.so in this case, and I meant to compare against a statically linked version. I primarily wrote this example as a response to the claim that an equivalent---it isn't---C code with musl is very small.