Making Rust binaries smaller by default • Hacker News Board

Re: Making Rust binaries smaller by default

#161

Post by sestep » Wed, Jan 24, 2024, 1:54 PM UTC

nindalf wrote: post #160

sestep wrote: post #152

Earlier quoted context omitted.

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…

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!

Re: Making Rust binaries smaller by default

#162

Post by IshKebab » Wed, Jan 24, 2024, 1:55 PM UTC

robinsonrc wrote: post #78

flohofwoe wrote: post #72

Earlier quoted context omitted.

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…

I remember my disappointment when I found out panics could be “caught” and that I was still living in the world of exceptions

You aren't. They're only caught in special cases, e.g. if a thread panics and you want to propagate that to other threads, to catch panics in unit tests, to avoid unwinding across FFI, etc.

You shouldn't use them as a general exception mechanism. They aren't the same, even if under the hood they both use stack unwinding.

Re: Making Rust binaries smaller by default

#163

Post by lifthrasiir » Wed, Jan 24, 2024, 1:56 PM UTC

pdimitar wrote: post #158

lifthrasiir wrote: post #117

Earlier quoted context omitted.

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.

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.

Re: Making Rust binaries smaller by default

#164

Post by nindalf » Wed, Jan 24, 2024, 1:58 PM UTC

pdimitar wrote: post #153

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

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.

Re: Making Rust binaries smaller by default

#165

Post by pdimitar » Wed, Jan 24, 2024, 1:59 PM UTC

lifthrasiir wrote: post #163

pdimitar wrote: post #158

Earlier quoted context omitted.

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 eff…

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

Re: Making Rust binaries smaller by default

#166

Post by pdimitar » Wed, Jan 24, 2024, 2:02 PM UTC

nindalf wrote: post #164

pdimitar wrote: post #153

Earlier quoted context omitted.

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…

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.

Re: Making Rust binaries smaller by default

#167

Post by pdimitar » Wed, Jan 24, 2024, 2:04 PM UTC

nindalf wrote: post #160

sestep wrote: post #152

Earlier quoted context omitted.

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…

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

Re: Making Rust binaries smaller by default

#168

Post by pdimitar » Wed, Jan 24, 2024, 2:09 PM UTC

lifthrasiir wrote: post #114

josephg wrote: post #111

Earlier quoted context omitted.

> (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?

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.

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.

Re: Making Rust binaries smaller by default

#169

Post by stefs » Wed, Jan 24, 2024, 2:17 PM UTC

pdimitar wrote: post #154

MrJohz wrote: post #139

Earlier quoted context omitted.

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.

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?

Re: Making Rust binaries smaller by default

#170

Post by pdimitar » Wed, Jan 24, 2024, 2:18 PM UTC

stefs wrote: post #169

pdimitar wrote: post #154

Earlier quoted context omitted.

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.