5 ms·
Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the sa
by api 1y ago
Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off.
It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded.
I get the sense devs just don’t put a lot of effort into stripping dead code and data since “storage is cheap” but it shows next to C or even C++ programs that are a fraction of the size.
I see nothing about Rust’s safety or type system that should result in chonky binaries. All that gets turned into LLVM IR just like C or C++.
Go ships a runtime so that explains some, but not all, of its bloat.
- kranke155 1y agoWhat binaries are a good example of this?
- AlexeyBrin 1y agoMostly because of static linking. C and C++ don't put every library they need in the binary by default. The advantage is that a pure Go or Rust binary just works (most of the time) when copied from one machine to another, you don't have to care about installing other libraries.
- Onavo 1y agoGo especially, on some platforms they go straight to syscalls and bypass libc entirely. They even bring their own network stack. It's the maximalist plan 9 philosophy in action.
- self_awareness 1y agoI don't really like Go as a language, but this decision to skip libc and go directly with syscalls is genius. I wish Rust could do the same. More languages should skip libc. Glibc is the main reason Linux software is binary non-portable between distros (of course not the only reason, but most of the problems come from glibc).
- steveklabnik 1y agoYou can only skip libc on Linux. Other unices and Windows don’t let you.
- immibis 1y agoYou can skip libc on Windows - you can't skip the system DLLs like kernel32. (In fact, Microsoft provided several mutually incompatible libcs in the past.) Well, you can non-portably skip kernel32, and use ntdll, but then your program won't work in the next Windows version (same as on any platform really - you can include the topmost API layers in your code, but they won't match the layers underneath of the next version). But system DLLs are DLLs, so also don't cause your .exe to get bloated.
- steveklabnik 1y agoYes, it's not literally libc on windows, but the point is that directly calling syscalls is not supported, you have to call through the platform's library for doing so. On some systems, this is just not a supported configuration (like what you're talking about with Windows) and on some, they go further, and actually try and prevent you from doing so, even in assembly.)
- immibis 1y agoThere's still something on the platform that you can call without extra indirection in the way on your side of the handoff. That is true on all platforms; whether it's an INT or SYSCALL instruction or a CALL or JMP instruction is irrelevant.
- int_19h 1y agoIf it's a CALL instruction into a user-space DLL, that's still an extra indirection.
- 1y ago
- api 1y agoThat’s a great point. Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible. The only other kinds of systems that can optimize this way are higher level JIT runtimes like the JVM and CLR. These can treat all code in the VM as a unit and optimize across everything.
- aleph_minus_one 1y ago> Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible. I get why this might lead to big intermediate files, but why do the final binaries get so big?
- 3836293648 1y agoRust binaries + all their dynamic libraries are the same size as C++ binaries + their linked libraries (when stripped, this isn't default in Rust) The main issue is that Rust binaries typically only link to libc whereas C++ binaries link to everthing under the sun, making the actual executable look tiny because that's not where most of the code lives.
- uecker 1y agoBoth C++ and Rust are based on monomorphization, which means generic programming is based on a expansion of code for each combination of types. This makes compilation slow and causes code bloat. One then needs whole program optimization to get this under control to some degree.
- TinkersW 1y agoC++ has had whole program optimization since forever. And you can use static linking if you want, the same as Rust.
- maccard 1y agoRust doesn’t strip debug info by default.
- jeroenhd 1y agoThe vast amount of debug info does make the problem worse, but it doesn't take long before a moderately complex Rust programs grows to 100MB even after stripping. When I tried to compare Rust programs to their C(++) equivalents by adding the sizes of linked libraries recursively (at least on Linux, that's impossible for Windows), I still found Rust programs to have a rather large footprint. Especially considering Rust still links to glibc which is a significant chunk of any other program as well. I believe many of Rust's statically linked libraries do more than their equivalents in other languages, so I think some more optimisation in stripping unused code paths could significantly reduce the size of some Rust applications.
- deleted 1y ago[deleted]
- throawayonthe 1y agohttps://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust explains some of it and https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-binaries-smaller-by-default.html https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-b...
- deleted 1y ago[deleted]
- Sharlin 1y agoA good article on minifying Rust binaries: https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
- deleted 1y ago[deleted]