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

131–140 of 199 posts

Re: Making Rust binaries smaller by default

#131

Post by kibwen »

flohofwoe wrote: post #67
chrismorgan wrote: post #62

Earlier quoted context omitted.

opt-level z would not be a reasonable default: you should normally optimise for speed, not binary size. lto and codegen-units=1 have a huge compile time cost. For release for general distribution you should tend to favour them, but the release profile isn’t just about that activity (especially because debug/opt-level Abort on panic changes runtime behaviour by stopping you from catching panics, which will completely…

> you should normally optimise for speed, not binary size IME optimize for speed vs size usually isn't as clear cut as the name says though, sometimes smaller code does indeed run faster, but in most cases I've seen there's not much of a difference between -O3, -O2, -Os and -Oz.

Weirdly, most of the time I find that -O3 produces smaller binaries than -Oz.

Re: Making Rust binaries smaller by default

#132

Post by lifthrasiir »

flohofwoe wrote: post #119
edflsafoiewq wrote: post #83

Earlier quoted context omitted.

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.

For me the difference would be: if the write past the array has been detected before it happens (via a range check) it would be a regular error which which can be handled, while a panic would be "oops somebody else has written past the end of the array" (e.g. a hitting a canary check), which should abort immediately because at that point it's no longer guaranteed that any recovery code would even work or just make th…

You have a good point and lock poisoning had the same reasoning, but wasn't really popular [1]. (In hindsight the poisoning itself was a great idea but should have been decoupled from locks.) Compared to other languages with similar constructs, Rust panic is probably regarded as less fatal because an incorrect but safe Rust code tends to have a limited reach.

Ah, and it should be also noted that some non-fatal signals were also delivered only via panic. The best-known example is a memory allocation failure, which is recoverable in Rust but needed unwinding for a long time. Nowadays you have an unsafe but non-unwinding alternative.

[1] https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey....

Re: Making Rust binaries smaller by default

#133

Post by jenadine »

Humphrey wrote: post #2

> I can imagine a situation where a seasoned C or C++ programmer wants to try Rust, compiles a small program in release mode, notices the resulting binary size, and then immediately gives up on the language and goes to make fun of it on the forums. While I'm not a seasoned C or C++ programmer I have definitely done this to a few new languages when playing around with them. My thought was "If helloworld.rust is this l…

That's ignoring the difference between fixed costs and marginal costs.

When the program grows, the fix costs stop to matter.

Re: Making Rust binaries smaller by default

#134

Post by 0x000xca0xfe »

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

Re: Making Rust binaries smaller by default

#135

Post by nsteel »

lifthrasiir wrote: post #37
temac wrote: post #35

Earlier quoted context omitted.

Why does it need to parse elf ?

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

Re: Making Rust binaries smaller by default

#136

Post by lieks »

bombela wrote: post #98
lieks wrote: post #91

Earlier quoted context omitted.

Yes, we do, in some contexts. Because despite its complexity, slow compile times, lack of a specification or more than one viable implementation and bloated binary size, people still tout it as a C replacement. For application programming, Rust is fine, but for embedded and systems programming, nearly any of those on its own can be enough to eliminate Rust as an option, depending on the situation. Except for complexi…

For what it's worth, I was able to write Rust for the 8bit AVR microcontroller platform. 256 bytes of RAM and 1024 CPU instructions FLASH. In this comment I describe what I did to remove the bloat: https://news.ycombinator.com/item?id=36394426 It's not the default and it took me some searching and reading to get there. I wonder if Cargo could have some vastly different default per target. As everybody said in this th…

1024 instructions? At that point I'd probably just use assembly. At that size, it would still be manageable.

Hmm, maybe that's the fundamental difference in thinking; the people I'm thinking of would reach for the simplest tool that can feasibly handle the job, even if it's somewhat harder to use.

Re: Making Rust binaries smaller by default

#137

Post by 0x000xca0xfe »

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.

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.

Re: Making Rust binaries smaller by default

#138

Post by bombela »

lieks wrote: post #136
bombela wrote: post #98

Earlier quoted context omitted.

For what it's worth, I was able to write Rust for the 8bit AVR microcontroller platform. 256 bytes of RAM and 1024 CPU instructions FLASH. In this comment I describe what I did to remove the bloat: https://news.ycombinator.com/item?id=36394426 It's not the default and it took me some searching and reading to get there. I wonder if Cargo could have some vastly different default per target. As everybody said in this th…

1024 instructions? At that point I'd probably just use assembly. At that size, it would still be manageable. Hmm, maybe that's the fundamental difference in thinking; the people I'm thinking of would reach for the simplest tool that can feasibly handle the job, even if it's somewhat harder to use.

In those 1024 instructions I was able to fit a decoder for standard 433Mhz remotes control, with learning of remotes (stored in EPROM), a button, a rotary encoder input, and a dozen led outputs through a 16 bit shift register. It also controls a digital potentiometer. Used to adjust a power supply output voltage driving a 20 meter LEDs string.

I am sure a pure assembly implementation would have saved some room in the FLASH, but the generated machine code wasn't that bad for what I can tell with my limited experience anyways. And it sure was nice to write it in Rust. Except a codegen bug in the version of Rust at the time ;) That one was painful!

Re: Making Rust binaries smaller by default

#139

Post by MrJohz »

0x000xca0xfe wrote: post #134
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 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 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.

Re: Making Rust binaries smaller by default

#140

Post by MrJohz »

gred wrote: post #127
lifthrasiir wrote: post #126

Earlier quoted context omitted.

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

That's true, which is why it's now being stripped.
Post reply on HN