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

121–130 of 199 posts

Re: Making Rust binaries smaller by default

#121

Post by lifthrasiir »

weinzierl wrote: post #116
nindalf wrote: post #45

Earlier quoted context omitted.

It’s funny, because your claim that it’s a great indicator is contradicted by the article we’re discussing. Rust was widely considered to be “only pay for what you use” despite having 4MB hello world programs. And now that it’s 400KB that continues to be true. So in this case, 4MB wasn’t a good indicator was it?

It's funny that it was already considered be “only pay for what you use” when the binaries contained half of H. P. Lovecraft's œuvre. See issue #13871 https://github.com/rust-lang/rust/issues/13871 I exaggerate, point is that we've come a long way and are still getting better. Different people look at different metrics and the more popular the language becomes the bigger the variety of metrics the come into focus.

Should've used that as a ballast instead [1].

[1] https://web.archive.org/web/20230708052006/https://www.gamed... (search for "The Programming Antihero")

Re: Making Rust binaries smaller by default

#122

Post by flohofwoe »

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.

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

Re: Making Rust binaries smaller by default

#123

Post by lifthrasiir »

flohofwoe wrote: post #122
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.

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.

Re: Making Rust binaries smaller by default

#124

Post by gred »

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

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.

Re: Making Rust binaries smaller by default

#125

Post by zozbot234 »

Vogtinator wrote: post #65
zozbot234 wrote: post #22

Earlier quoted context omitted.

Rust can't do this very well because it doesn't build std as part of the project, that's still an unstable option. It's linking object code.

C doesn't either, but statically linking still pulls only the object files which are actually needed into the executable.

A Rust crate is a single translation unit. It's the precise equivalent of a C source or object file.

Re: Making Rust binaries smaller by default

#126

Post by lifthrasiir »

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.

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!

Re: Making Rust binaries smaller by default

#127

Post by gred »

lifthrasiir wrote: post #126
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.

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

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

Re: Making Rust binaries smaller by default

#128

Post by zozbot234 »

flohofwoe wrote: post #47
zozbot234 wrote: post #38

Earlier quoted context omitted.

> but then nobody took the time to actually do it That happens all the time, it's called prioritizing. If you don't let people prioritize, they will burn out and leave the project. That's not what you want.

If people only pick "interesting" problems to work on and ignore fundamental (but boring) issues like this, then those issues will just pile up and frustration and burnout will grow even more in the long run. At some point you'll have to stop feature development for a while and put all hands on cleaning up the accumulated cruft.

This is not a fundamental issue, it's just a kind of boring papercut that Rust has many examples of. If you need to do a whole lot of "foundational" yak shaving to ultimately accomplish something else that's clearly worthwhile, the Rust folks are quite comfortable with that: it's what the WG's and initiatives are for.

Re: Making Rust binaries smaller by default

#129

Post by kibwen »

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

Panics have to be catchable because it's undefined behavior for Rust to unwind through C code, so a Rust library that exposes a C API has to stop panics at the FFI boundary and propagate errors in a C-compatible way. It's not "catching" in the Java sense; nobody is using catch_panic to implement resumable error-handling.

Re: Making Rust binaries smaller by default

#130

Post by oblio »

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.

> "zero-cost abstractions"

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

Post reply on HN