Hacker News Reader

Comment by pdimitar | Hacker News Reader

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 that basis alone (so the author is quite right to call this out as a factor).

Looking at the https://github.com/johnthagen/min-sized-rust repo, final binary size of 51 KB when compilation / linking / stripping takes stdlib into account (and not just blindly copy-pasting the 4MB binary blob) is acceptable and much more reasonable. I wouldn't care for further micro-optimizations e.g. going to 20KB or even 5KB (further down the README file).

I also don't use nightly in my Rust work so I guess I'll have to wait several more years. :(

View on HN

> 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 for a long while they are tested. This is not one of those features.

Some features remain in nightly for years.

A very relevant example is `build-std`, which builds the standard library (and does LTO) instead of copying a pre-built one. This feature has been on nightly for at least a couple of years.

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

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.

Ah I see, I misunderstood: you were talking about `strip = "debuginfo"`, while I thought you were talking about `build-std`. Thank you for the link/clarification!

Oof, here I have mistaken the simple strip debug stuff default flag with the `build-std` work which is much more complex. Sorry.

I indeed am confusing it with those features that seem to be in nightly forever. Thank you, compiling with beta is much more acceptable for me. (EDIT: or simply waiting for stable 1.77)

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.

Most debugging informations are "useless" until they are desparately needed, and this "wasted space" was no exception. So as always, it's another trade-off: will you "waste" some bytes to ease yourself in the future? Cargo already has decided that uninformed people don't want them for the release mode, but it was found that this decision was not uniformly enforced and some debuginfo was still left there. So a new option was added and the default was changed. Happy ending!

True, but it sounds (nearly?) "useless" based on the description provided by the author:

> For example, one thing that was noted is that if we strip the debug symbols by default, then backtraces of release builds will... not contain any debug info, such as line numbers. That is indeed true, but my claim is that these have not been useful anyway. If you have a binary that only has debug symbols for the standard library, but not for your own code, then even though the backtrace will contain some line numbers from stdlib, it will not really give you any useful context [...]

That's true, which is why it's now being stripped.

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.

I don’t see how zero cost abstraction has anything to do with binary size. It’s about runtime efficiency of language features.

Optimizing binary size is a worthy and important goal because some people have uses cases where it matters. If you are not one of those people why fret about it?

> I don’t see how zero cost abstraction has anything to do with binary size.

But binary size is absolutely a cost. Whether or not it's a cost that matters to you is a different question, but it's still a cost.

> "zero-cost abstractions"

Zero cost in terms of CPU and RAM usage during execution time.

Program size affects disk/file system load time, relocation time, cache utilization, zram speed, and probably many things more.

Nothing is zero-cost if you look closely enough.

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)

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.youtube.com/watch?v=ZfuierUvx1A

Would be awesome if compilers could do the same :)

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 anyway, which means that the Rust standard library doesn't need to be included in the binary, which will already significantly reduce the size of your binary.

A lot of this is about tradeoffs, and I think the article does a good job of explaining what tradeoffs are relevant here. Yes, binaries should be as small as possible, but shipping multiple compiled standard libraries is also not ideal. The Rust team seem to have gone for a good default for people who are beginning, with lots of ways to tailor the build process for people who don't need debugging information, or who are willing to accept longer install/compile times in exchange for smaller, more optimised binaries.

I'm not criticizing Rust, I'm criticizing statements that doubt whether the effort to reduce the binary size is worth it.

We currently have some nasty C++/boost monstrosities, if Rust can deliver a better development experience AND reliable stack traces AND smaller binaries, it would be HUGE for embedded.

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.

Isn't that the linkers job? To throw away unused functions?

I remember this being the standard decades ago. It might not make sense in certain situations (i.e. with reflection), but that shouldn't be the default case anyway. What happened?

Yes, but I was left with the impression that including the stdlib in its entirety prevents proper tree-shaking / dead code elimination. Could be wrong.

While I'm not a demoscener, I know enough about how they are generally made and have my own share of award-winning small programs. So I'm confident that they don't make a good example of non-bloated software.

Every demo is really amazing when you encounter them for the first time, but AFAIK 64K demos were hottest around 2000 when Farbrausch revolutionalized the scene with .fr-08: .the .product [1]. Since then, 64K turned out to be too large because most 64K demos can be divided into multiple parts---engine, data and compressor---and each part can be individually developed. There are many 64K demos but far less engines and only a handful number of compressors in this level. It also means that there are only a handful number of people that can actually make engines and compressors. It's not a fit software, it's rather an unhealthily thin software. They are still awesome but they can't be a model.

[1] http://www.theproduct.de/

> I work in embedded software

But embedded Rust usually does not use stdlib. This thread started with:

> It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary.

Which is not case for embedded.

We are shipping a full blown custom Linux distribution, embedded software is more than just microcontrollers. Binary size is still just as relevant.

Are you confusing "embedded" for "microcontrollers without an operating system"? There are plenty of embedded CPUs that can run Linux. Buildroot even exists to make it easier to create distributions for these types of devices. For example, I would consider the reMarkable 2 to be an embedded device, but it runs full-blown Linux (to the point of having a bloated Qt stack).

That's probably an extreme case though, as nobody in their right mind would actually try to run Qt on an embedded device with any reasonable limit on resources. I'm sure rM only does it because they can afford to be wasteful - they have hundreds of megabytes of space for the operating system, and all the latency-sensitive stuff is definitely not built on Qt.

Reason I know this is because they offer SSH access to the device and an SDK.

You can't be everything to everyone. Packaging considerations for niche use cases rightfully take a back seat to debuggability and packaging considerations in modern web deployments and consumer devices.

You can always do a multi-call binary (busybox-style) so that you only get one copy of the stdlib. Coupled with build-std (and other min-size things), it should bring rust code size to a manageable level.

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, vending machines)... The list goes on.

So it may NOT matter for the desk top, or mobile or servers, but that's a tiny fraction of the computing out there.

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.

Many MMOs do actually download updated client executables on the fly in the launcher, and that shouldn't make the player wait more than necessary. Even the Steam client has such an automatic update process (and at 200 MBytes this is already in "very annoying" territory IMHO).

I mean, yes! Games are on the opposite end of the spectrum, where uncompressed assets fly around and 100 MB sounds like very small. These are what I refer to "low-hanging fruits"---I expect a moderate effort can halve the total size for most cases. (I did work on asset file formats back when I was a gamedev.) 400 KB executable is not really a big deal compared to that.

I dont have a hard limit for JS...

What I have is a wall for functionality.

Loading 700kb react blob (compressed mind you) so I can read a web page is a hard no. You want to give me a rich GUI to do data editing in a browser, bring it on, I'll take the down load.

I know that rust and tiny go swap code here and there, binary sizes getting smaller on rust might make me give it a poke for some of the more "cute" embedded/iot things I like to play with... (another place where small matters!)

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.

I agree that 4 MB is bad, but I felt 400 KB is fine given all circumstances.

If Rust really wants to minimize any overhead in spite of the necessity of backtrace supports, there are indeed many ways to minimize the cold section of executable. Even a simple compression will work---especially given that we already have a copy of miniz-oxide there! So try that if you are motivated, and I would more than welcome that effort, but Rust has way, way more important things to do than that.

I am 100% sure there are much important issues right now and I sympathize with the lack of bandwidth. The one thing I am claiming is that some lower-hanging fruit (if it is indeed that; might be super complex in fact) carries a significant positive public relations / image potential which should IMO be picked / harvested.

(EDIT: I am talking about the `build-std` work here, not the default strip debug info flag.)

> Out in javascript land no one cares about file size or wire time any more

Which is one of the reasons why I tend to leave JS disabled in my browser. Too many web devs have no care or concern for these sorts of things, which often makes JS a real resource drain.

What? JS is the only ecosystem I know of that really cares about file size, to the point that it's expected to see the size of a library in release form (minified, gzipped) on its homepage. That's vanishing rare with any other language, including C.

Depends on what you're aiming for.

If we talk about ultra-low-power platforms, e.g. energy-harvesting IoT devices, 1MB is still quite a lot.

If we are going to argue that Rust can compete with C/C++, it needs to have similar performance, also regarding binary size.

C/C++ standard library doesn't work in that environment anyway---you typically need a freestanding mode. Rust equvialent is `#[no_std]` which works well for popular boards.

To be technical, Rust deliberately splits out three elements: core (which is necessary for the Rust language and is always provided) alloc (which needs a heap allocator, not applicable if you don't have or don't want one) and then std (which expects an operating system, with features like files and sockets and threads and knowing what the time is)

C++ just labels a few specific features as available in a "freestanding" C++ standard library if you have one (on an embedded platform presumably you do).

This makes it very easy to know what you're getting in Rust's stdlib in #[no_std] because it's all of core, so e.g.

https://doc.rust-lang.org/core/primitive.slice.html#method.s... vs. https://doc.rust-lang.org/std/primitive.slice.html#method.so...

At first glance those are identical, but no, std is re-exporting every feature core had, but it also gains features, for example the stable sort function family only exist in std because they're using a temporary allocation whereas the unstable (ie equivalent items may be re-ordered) sort provided even in core doesn't do that.

Figuring out what you get in your stdlib with C++ often comes down to suck it and see.

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.

Would debug symbols ever be loaded into CPU cache? They'd be in RAM, sure. But why would the CPU ever load them into cache? The way I'm imagining this, and I could be wrong, is that the debug symbols are to one end of the binary. They wouldn't be loaded into cache unless they're going to be used imminently.

Another way of saying this is that the change to strip automatically is a small win for for disk space and RAM consumption, but I don't think it's going to improve performance dramatically? I could be wrong about this though.

No, it's more likely that you are correct because it has been a long time since I worked that close to the metal and my info is outdated or downright wrong at this point.

Thanks for the nuance. If debug symbols indeed never go into the CPU cache then my remark is completely irrelevant.

I think most debug info is in its own section. On a real OS the pages are loaded lazily so no (significant) performance hit.

Still, I hate big Rust binaries as much as the next guy.

That won't fit into a ESP32, Arduino or embedded hardware with similar restrictions, leaving the space for C and C++, or the Basic, Pascal compiler vendors still enjoying that space like Mikroe.

> in practice anything below 1 MB seems small enough that you don't need to optimize further.

I think that it depends on what sort of machine you're aiming for the binary to run on. I develop for a few platforms where a 1MB executable size would be completely unacceptable.

Adds up with larger applications using a bunch of distinct binaries or many libraries.

> (and not just blindly copy-pasting the 4MB binary blob)

Where is this 4mb claim coming from? I just built a hello world on macos in release mode, with no special flags and the result was 400kb. Thats absolutely larger that it should be, but its a lot smaller than 4mb.

Is it really that much worse on linux?

Macho executables don't contain debug info. Just references to .o files.

You are looking at the aftermath. Also, you could have manually put `strip = "debuginfo"` to avoid the 4 MB binary even before that; the issue is about the default when no `strip` option was given.

No, this is using stable rust 1.75. The binary is not stripped at all, and its still 400kb, not 4mb.

Actually my issue is with including the stdlib in its entirety, sorry for not clarifying.

Indeed we could always strip the binaries and I've done so on every Rust project I worked on.

You are aware that the stdlib is linked with --as-needed which tells the linker to not include unused code, right? The entire stdlib is not included in Rust binaries unless you use the entire stdlib. However, as this article shows, that does not apply to debug info.

Actually I was not aware, thanks for clarifying!

Hrm, I read the comments of another user who contributes to Rust and it seems there is various formatting / panic / abort / symbol and location translation code that contributes to the size and currently there is not much that can be done about it.

Oh well.

Reply on news.ycombinator.com