Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Rust binaries smaller by default

kobzol.github.io

Post reply on HN
Print view View original

151–160 of 199 posts

Re: Making Rust binaries smaller by default

#151

Post by kobzol »

nsteel wrote: post #135
lifthrasiir wrote: post #37

Earlier quoted context omitted.

The stack frame is a list of return addresses which have to be translated to a file name and line number. Such debug information is within a specific ELF section in the predefined format. In this simple case you may be able to hard-code the offset to the section (and guarantee that it was never compressed), but any additional C or Rust library will break this assumption, so a general parser has to be included.

Sorry if this is dumb but if the idea is stripping debug stuff, why would a parser for translating return addresses into file names and line numbers be useful? EDIT: oh, ok, so I guess it's because strip is "debuginfo" here, rather than "true".

There is some work underway to enable removing the backtrace generation/parsing from Rust binaries. It's hardcoded for now though.

Re: Making Rust binaries smaller by default

#152

Post by sestep »

nindalf wrote: post #108
pdimitar wrote: post #100

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary. I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't take Rust seriously because of it. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berating and ignoring Rust on th…

> so I guess I'll have to wait several more years A feature that's landed in Rust nightly will be part of the next beta release (at most 6 weeks away) and then the following full release (exactly 6 weeks away). For this feature in particular, rustbot added a tag of 1.77.0, which is releasing on 21st March 2024, less than 2 months away. It's possible you've confused this with more complex features that stay on nightly…

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30

Are you saying that the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?

The Cargo doc page on `build-std` says that it is an "unstable feature" which will only eventually end up in stable once it is stabilized: https://doc.rust-lang.org/cargo/reference/unstable.html#buil... and Kobzol's linked post above indicates that `build-std` is "sadly still unstable."

Re: Making Rust binaries smaller by default

#153

Post by pdimitar »

lifthrasiir wrote: post #103
pdimitar wrote: post #100

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary. I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't take Rust seriously because of it. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berating and ignoring Rust on th…

But why? I mean, I'm also obsessed of the byte size from time to time and I do often optimize for the size when it's doable, but in practice anything below 1 MB seems small enough that you don't need to optimize further. There are so many low-hanging fruits when it comes to the Rust binary size...

Mostly because CPU caches matter a lot. Executing 7-8 different Rust binaries, in a loop, that are each north of 10MB+ is bound to be less performant than corresponding smaller programs.

Never had the time or dedication to actually verify this but I've been bitten by programs and OS-es that trash the cache too much and I've seen humanly perceivable lags because of it. But maybe in this case I am overreacting.

Re: Making Rust binaries smaller by default

#154

Post by pdimitar »

MrJohz wrote: post #139
0x000xca0xfe wrote: post #134

Earlier quoted context omitted.

I work in embedded software and we fight for every megabyte of NAND flash. Multiple smaller executables add up, too. Reducing the binary size is usually more important than performance (and often more important than memory safety, if we are totally honest...). Personally, I hate bloated software just as much as slow software. It's crazy what you can do with 64 kilobytes, let the demoscene blow your mind: https://www.…

In fairness, this is just doing something automatically that you could have done manually anyway. It's a good change because defaults matter, but it's always been possible to strip debug symbols from Rustc-generated binaries, and all the guides I've seen to reducing binary stuff have mentioned this already. It's also important to remember that in embedded software, you're probably working in a no_std environment anyw…

Stripping debug stuff has always been possible, yes, but that doesn't entirely address the problem of the stdlib being included piecemeal. I want a compiler who throws away everything that's not used in the final binary.

If that means that 90% of the stdlib is unused (which is likely true for many small projects) then it should not be included in the binary.

Re: Making Rust binaries smaller by default

#155

Post by weinzierl »

kobzol wrote: post #149
weinzierl wrote: post #86

I 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.

You can't really use dead code elimination on debug symbols, because you don't know which symbols will you need. You would need to know where and how will your program crash or if the user will want to use a debugger on it.

I don't understand. If a function isn't in the binary I will never need its name, so it does never have to be in the debug information. Likewise for variables.

Re: Making Rust binaries smaller by default

#156

Post by pdimitar »

oblio wrote: post #130
gred wrote: post #124

Earlier quoted context omitted.

I don't have a horse in this race, but a programming language that prides itself on "zero-cost abstractions" and then generates a Hello World program that is 90% wasted space doesn't leave a great impression.

> "zero-cost abstractions" Zero cost in terms of CPU and RAM usage during execution time.

I don't disagree with your premise but bigger binaries lead to significantly more CPU cache churn. (EDIT: or not, see elsewhere in this thread for clarifications)

Re: Making Rust binaries smaller by default

#157

Post by pdimitar »

gred wrote: post #124
lifthrasiir wrote: post #103

Earlier quoted context omitted.

But why? I mean, I'm also obsessed of the byte size from time to time and I do often optimize for the size when it's doable, but in practice anything below 1 MB seems small enough that you don't need to optimize further. There are so many low-hanging fruits when it comes to the Rust binary size...

I don't have a horse in this race, but a programming language that prides itself on "zero-cost abstractions" and then generates a Hello World program that is 90% wasted space doesn't leave a great impression.

I don't judge by this but I have met programmers who do (as mentioned upthread) so yeah, I agree. It's a signal that is useful to many, and that signal should start being optimized sooner rather than later.

Re: Making Rust binaries smaller by default

#158

Post by pdimitar »

lifthrasiir wrote: post #117
zer00eyz wrote: post #113

Earlier quoted context omitted.

Out in javascript land no one cares about file size or wire time any more (but should) -- Over in C, plenty of people work on things where file size matters. It is a big deal. System constraints (embedded) wire constraints (far away systems where internet is slow and ephemeral), legacy systems where everything is going to be slow even moving that fat file around and you have to be present to update (ATM, ticket, vend…

I do have a lower threshold for JS apps, which is about 200 KB. This difference accounts for the fact that websites can be streamed while executables can't. I'm not saying that we shouldn't optimize for the size---rather I'm saying the size optimization is not worthwhile under some threshold.

I agree with the threshold argument but I guess it differs for all of us. To me 4MB Hello World program is hilariously bad. I want Rust to compete with C. Not be better or even equal to C when it comes to binary sizes, but I want it to be close.

Re: Making Rust binaries smaller by default

#159

Post by kobzol »

eviks wrote: post #33
kobzol wrote: post #27

Earlier quoted context omitted.

I have implemented the fix and got it approved in the span of about 3 weeks (and that was over the Christmas!). Doesn't seem that bad to me, given that it's a change that will affect pretty much any Rust user by default.

Even if just focused on time alone, that's 3 weeks and all the years when you kept rediscovering it Then there is the fact that it required establishing the whole working group All for a simple fix that positively affects pretty much any Rust user

It didn't really require establishing a working group :) That is just an effort to improve Rust binary sizes in general.

In the end, changes in Rust can take a very long time (years) sometimes. It's maintained and developed by volunteers, and it has been growing exponentially these past few years, so not everything can move forward as fast as we would like.

Re: Making Rust binaries smaller by default

#160

Post by nindalf »

sestep wrote: post #152
nindalf wrote: post #108

Earlier quoted context omitted.

> so I guess I'll have to wait several more years A feature that's landed in Rust nightly will be part of the next beta release (at most 6 weeks away) and then the following full release (exactly 6 weeks away). For this feature in particular, rustbot added a tag of 1.77.0, which is releasing on 21st March 2024, less than 2 months away. It's possible you've confused this with more complex features that stay on nightly…

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30 Are you saying that the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"? Th…

Yes, I am sure this is going to be a part of Rust 1.77.0 and it will release on 21st March. I say that because of the tag in the PR (https://github.com/rust-lang/cargo/pull/13257#event-11505613...).

I'm no expert on Rust compiler development, but my understanding is that all code that is merged into master is available on nightly. If they're not behind a feature flag (this one isn't), they'll be available in a full release within 12 weeks of being merged. Larger features that need a lot more testing remain behind feature flags. Once they are merged into master, they remain on nightly until they're sufficiently tested. The multi-threaded frontend (https://blog.rust-lang.org/2023/11/09/parallel-rustc.html) is an example of such a feature. It'll remain nightly only for several months.

Again, I'm not an expert. This is based on what I've observed of Rust development.

Post reply on HN