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

111–120 of 199 posts

Re: Making Rust binaries smaller by default

#111

Post by josephg »

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…

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

Re: Making Rust binaries smaller by default

#112

Post by rkangel »

cybrox wrote: post #29
1vuio0pswjnm7 wrote: post #23

"Rust tries to appeal to programmers coming from many different backgrounds, and not everyone knows that something like stripping binaries even exists."

It's not ideally written but it's safe to assume if someone compiles a quick test program for that purpose and it ends up being 4MB, they might just move on to other options instead of starting to think about how they can manually reduce the binary size. When evaluating languages, you rarely look foor good enough results to work around.

Yes. The statement I agree the most with in the blog post is "defaults matter".

Re: Making Rust binaries smaller by default

#113

Post by zer00eyz »

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

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.

Re: Making Rust binaries smaller by default

#114

Post by lifthrasiir »

josephg wrote: post #111
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…

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

Re: Making Rust binaries smaller by default

#115

Post by formerly_proven »

josephg wrote: post #101
robinsonrc wrote: post #78

Earlier quoted context omitted.

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

Oh no, I didn't know this. I'm adding panic = "abort" to all my projects. If I wanted exceptions I wouldn't be using rust.

You can catch them locally (https://doc.rust-lang.org/std/panic/fn.catch_unwind.html) or with a global exception handler (https://doc.rust-lang.org/std/panic/fn.set_hook.html)

Re: Making Rust binaries smaller by default

#116

Post by weinzierl »

nindalf wrote: post #45
lionkor wrote: post #4

Initial binary size, like of a hello world, is a great indicator of how much abstraction the language has that youre also paying for. For example, java has to set up a constants pool, parse it from the classfile, run init and cinit, resolve references, allocatea a frame, and so on, just to get to the entrypoint. Compared to C without stdlib which needs to basically just run a few bytes to syscall write(). There are o…

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.

Re: Making Rust binaries smaller by default

#117

Post by lifthrasiir »

zer00eyz wrote: post #113
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...

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.

Re: Making Rust binaries smaller by default

#118

Post by lifthrasiir »

bipson wrote: post #107
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...

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.

Re: Making Rust binaries smaller by default

#119

Post by flohofwoe »

edflsafoiewq wrote: post #83
flohofwoe wrote: post #70

Earlier quoted context omitted.

IMHO when a piece of code decides to panic it should only happen when execution cannot continue under any circumstances, and in such cases all bets are off whether any cleanup code would actually still work. A hard abort might indeed be the best option.

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 things worse (e.g. trying to flush data from memory back to disk, but that data might have been corrupted too).

Re: Making Rust binaries smaller by default

#120

Post by josephg »

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.

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