4 ms·

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 i

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 https://www.youtube.com/watch?v=ZfuierUvx1A Would be awesome if compilers could do the same :)

MrJohz 3y ago
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.
- 0x000xca0xfe 3y ago
  I'm not criticizing Rust, I'm criticizing statements that doubt whether the effort to reduce the binary size is worth it. We currently have some nasty C++/boost monstrosities, if Rust can deliver a better development experience AND reliable stack traces AND smaller binaries, it would be HUGE for embedded.
- pdimitar 3y ago
  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.
  - stefs 3y ago
    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?
    - pdimitar 3y ago
      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.
timeon 3y ago
> I work in embedded software But embedded Rust usually does not use stdlib. This thread started with: > It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary. Which is not case for embedded.
- 0x000xca0xfe 3y ago
  We are shipping a full blown custom Linux distribution, embedded software is more than just microcontrollers. Binary size is still just as relevant.
- LoganDark 3y ago
  Are you confusing "embedded" for "microcontrollers without an operating system"? There are plenty of embedded CPUs that can run Linux. Buildroot even exists to make it easier to create distributions for these types of devices. For example, I would consider the reMarkable 2 to be an embedded device, but it runs full-blown Linux (to the point of having a bloated Qt stack). That's probably an extreme case though, as nobody in their right mind would actually try to run Qt on an embedded device with any reasonable limit on resources. I'm sure rM only does it because they can afford to be wasteful - they have hundreds of megabytes of space for the operating system, and all the latency-sensitive stuff is definitely not built on Qt. Reason I know this is because they offer SSH access to the device and an SDK.
lifthrasiir 3y ago
While I'm not a demoscener, I know enough about how they are generally made and have my own share of award-winning small programs. So I'm confident that they don't make a good example of non-bloated software. Every demo is really amazing when you encounter them for the first time, but AFAIK 64K demos were hottest around 2000 when Farbrausch revolutionalized the scene with .fr-08: .the .product [1]. Since then, 64K turned out to be too large because most 64K demos can be divided into multiple parts---engine, data and compressor---and each part can be individually developed. There are many 64K demos but far less engines and only a handful number of compressors in this level. It also means that there are only a handful number of people that can actually make engines and compressors. It's not a fit software, it's rather an unhealthily thin software. They are still awesome but they can't be a model. [1] http://www.theproduct.de/ http://www.theproduct.de/
deschutes 3y ago
You can't be everything to everyone. Packaging considerations for niche use cases rightfully take a back seat to debuggability and packaging considerations in modern web deployments and consumer devices.
Aissen 3y ago
You can always do a multi-call binary (busybox-style) so that you only get one copy of the stdlib. Coupled with build-std (and other min-size things), it should bring rust code size to a manageable level.

MrJohz 3y ago

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.

0x000xca0xfe 3y ago
I'm not criticizing Rust, I'm criticizing statements that doubt whether the effort to reduce the binary size is worth it. We currently have some nasty C++/boost monstrosities, if Rust can deliver a better development experience AND reliable stack traces AND smaller binaries, it would be HUGE for embedded.
pdimitar 3y ago
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.
- stefs 3y ago
  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?
  - pdimitar 3y ago
    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.

timeon 3y ago

> I work in embedded software But embedded Rust usually does not use stdlib. This thread started with: > It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary. Which is not case for embedded.

0x000xca0xfe 3y ago
We are shipping a full blown custom Linux distribution, embedded software is more than just microcontrollers. Binary size is still just as relevant.
LoganDark 3y ago
Are you confusing "embedded" for "microcontrollers without an operating system"? There are plenty of embedded CPUs that can run Linux. Buildroot even exists to make it easier to create distributions for these types of devices. For example, I would consider the reMarkable 2 to be an embedded device, but it runs full-blown Linux (to the point of having a bloated Qt stack). That's probably an extreme case though, as nobody in their right mind would actually try to run Qt on an embedded device with any reasonable limit on resources. I'm sure rM only does it because they can afford to be wasteful - they have hundreds of megabytes of space for the operating system, and all the latency-sensitive stuff is definitely not built on Qt. Reason I know this is because they offer SSH access to the device and an SDK.

lifthrasiir 3y ago

While I'm not a demoscener, I know enough about how they are generally made and have my own share of award-winning small programs. So I'm confident that they don't make a good example of non-bloated software. Every demo is really amazing when you encounter them for the first time, but AFAIK 64K demos were hottest around 2000 when Farbrausch revolutionalized the scene with .fr-08: .the .product [1]. Since then, 64K turned out to be too large because most 64K demos can be divided into multiple parts---engine, data and compressor---and each part can be individually developed. There are many 64K demos but far less engines and only a handful number of compressors in this level. It also means that there are only a handful number of people that can actually make engines and compressors. It's not a fit software, it's rather an unhealthily thin software. They are still awesome but they can't be a model. [1] http://www.theproduct.de/ http://www.theproduct.de/

deschutes 3y ago

You can't be everything to everyone. Packaging considerations for niche use cases rightfully take a back seat to debuggability and packaging considerations in modern web deployments and consumer devices.

Aissen 3y ago

You can always do a multi-call binary (busybox-style) so that you only get one copy of the stdlib. Coupled with build-std (and other min-size things), it should bring rust code size to a manageable level.