4 ms·

Unless rust can link to its stdlib dynamically by default, its size is the biggest problem for any mid-range embedded boards(there are lots of them) due to the

Unless rust can link to its stdlib dynamically by default, its size is the biggest problem for any mid-range embedded boards(there are lots of them) due to the static link with rust's stdlib. Nowadays a few simple rust binaries will be close to 50MB when there are only 16MB or 64MB storage(if using c/c++, 1MB will suffice, rust is 40x larger). writing a busybox-like all-in-one rust binary could be a workaround but it is hard to do in practice.

throwaway894345 4y ago
For embedded, don’t you typically use no_std? Presumably that means you don’t link the stdlib?
- synergy20 4y ago
  mid range boards needs stdlib
pjmlp 4y ago
Just like with using C and C++ on such scenarios, the standard library doesn't come for the party.
newpavlov 4y ago
Are you talking about binaries compiled for bare-metal embedded? In such cases you usually simply do not have `std`. And how do you think dynamic linking would help here? If anything, it will make total size bigger since compiler will not be able to perform dead code elimination. When people talk about big Rust binaries they often forget to strip debug information. Doing it can easily shed half of the binary size. And there are other relatively well known ways of reducing binary size (such as strategically using dynamic dispatch instead of monomorphization, using abort for panics, compiling with opt-level=z/s, etc.).
- synergy20 4y ago
  no,i specifically said mid range boards,no-std is for bare metal mcu boards
cesarb 4y ago
If you are building for an embedded board, you don't need to follow the defaults; you can enable the flag to dynamically link to Rust's standard library, and the main disadvantage of doing so (that Rust's standard library doesn't have yet a stable ABI) is not an issue when you're always rebuilding everything.
- synergy20 4y ago
  it is more than that,in short,rust is not really designed for shared stdlib,yes you can hack it but it is untested and u are on your own
  - cesarb 4y ago
    It's hard to say "it's untested" when the rustc compiler itself is usually compiled with shared stdlib: $ ldd `which rustc` linux-vdso.so.1 librustc_driver-1ca4abb0311ec689.so => /lib64/librustc_driver-1ca4abb0311ec689.so libstd-f1d4d1a0beb2c43e.so => /lib64/libstd-f1d4d1a0beb2c43e.so libc.so.6 => /lib64/libc.so.6 [...]
steveklabnik 4y ago
We have Rust embedded programs at work that are in the hundreds or thousands of bytes.
- synergy20 4y ago
  using stdlib? i am not talking about bare metal mcu boards here though
  - steveklabnik 4y ago
    Even with stdlib, the concept is the same: if you want small binaries, you have to work on it, you don't just get the smallest ones out of the box. Seems like sibling commentors have already explained the biggest tips so I'll just leave it at that. While you may be talking about larger boards, the fact that Rust code can fit into even smaller ones means Rust isn't the issue here.
zRedShift 4y ago
You typically use build-std and possibly abort on panics or immediate-abort to disable the string formatting code in stdlib, and you do fat LTO. after stripping the binary, it’s pretty damn small. If you want even further savings on std, you can use an utility that LZMA compresses the different ELF sections of your binary and unpacks them to memory at runtime. That’s language agnostic though… Regarding multiple rust binaries each bundling a copy of stdlib and inflating the space, this approach would only link the bits of the stdlib each binary uses, but still it’s not ideal. Three approaches I can think of are: 1. Use a file system that compresses its contents like btrfs or zfs or their embedded variant. It should reduce the redundancies. 2. Go the busybox way, as you said. This requires work but it’s definitely doable. 3. Link stdlib dynamically. There is a way, I believe. Rust maintains a “stable” ABI as long as you use the same rustc version if I’m not mistaken. 4. This is ridiculous, so I don’t even count this as a way, but what if you just stored the .a static libs and did the linking on demand into a temporary file that would then be executed? I personally have never encountered 50MiB optimized stripped and LT optimized rust binaries, only ‘materialized’ which was like 138MiB but it contained debug symbols, no LTO and is quite a large database application.

throwaway894345 4y ago

For embedded, don’t you typically use no_std? Presumably that means you don’t link the stdlib?

synergy20 4y ago
mid range boards needs stdlib

pjmlp 4y ago

Just like with using C and C++ on such scenarios, the standard library doesn't come for the party.

newpavlov 4y ago

Are you talking about binaries compiled for bare-metal embedded? In such cases you usually simply do not have `std`. And how do you think dynamic linking would help here? If anything, it will make total size bigger since compiler will not be able to perform dead code elimination. When people talk about big Rust binaries they often forget to strip debug information. Doing it can easily shed half of the binary size. And there are other relatively well known ways of reducing binary size (such as strategically using dynamic dispatch instead of monomorphization, using abort for panics, compiling with opt-level=z/s, etc.).

synergy20 4y ago
no,i specifically said mid range boards,no-std is for bare metal mcu boards

cesarb 4y ago

If you are building for an embedded board, you don't need to follow the defaults; you can enable the flag to dynamically link to Rust's standard library, and the main disadvantage of doing so (that Rust's standard library doesn't have yet a stable ABI) is not an issue when you're always rebuilding everything.

synergy20 4y ago
it is more than that,in short,rust is not really designed for shared stdlib,yes you can hack it but it is untested and u are on your own
- cesarb 4y ago
  It's hard to say "it's untested" when the rustc compiler itself is usually compiled with shared stdlib: $ ldd `which rustc` linux-vdso.so.1 librustc_driver-1ca4abb0311ec689.so => /lib64/librustc_driver-1ca4abb0311ec689.so libstd-f1d4d1a0beb2c43e.so => /lib64/libstd-f1d4d1a0beb2c43e.so libc.so.6 => /lib64/libc.so.6 [...]

steveklabnik 4y ago

We have Rust embedded programs at work that are in the hundreds or thousands of bytes.

synergy20 4y ago
using stdlib? i am not talking about bare metal mcu boards here though
- steveklabnik 4y ago
  Even with stdlib, the concept is the same: if you want small binaries, you have to work on it, you don't just get the smallest ones out of the box. Seems like sibling commentors have already explained the biggest tips so I'll just leave it at that. While you may be talking about larger boards, the fact that Rust code can fit into even smaller ones means Rust isn't the issue here.

zRedShift 4y ago

You typically use build-std and possibly abort on panics or immediate-abort to disable the string formatting code in stdlib, and you do fat LTO. after stripping the binary, it’s pretty damn small. If you want even further savings on std, you can use an utility that LZMA compresses the different ELF sections of your binary and unpacks them to memory at runtime. That’s language agnostic though… Regarding multiple rust binaries each bundling a copy of stdlib and inflating the space, this approach would only link the bits of the stdlib each binary uses, but still it’s not ideal. Three approaches I can think of are: 1. Use a file system that compresses its contents like btrfs or zfs or their embedded variant. It should reduce the redundancies. 2. Go the busybox way, as you said. This requires work but it’s definitely doable. 3. Link stdlib dynamically. There is a way, I believe. Rust maintains a “stable” ABI as long as you use the same rustc version if I’m not mistaken. 4. This is ridiculous, so I don’t even count this as a way, but what if you just stored the .a static libs and did the linking on demand into a temporary file that would then be executed? I personally have never encountered 50MiB optimized stripped and LT optimized rust binaries, only ‘materialized’ which was like 138MiB but it contained debug symbols, no LTO and is quite a large database application.