Rust UEFI Firmware Targets Promoted To Tier-2 Status

[archkde]

It's not a matter of tuning, it's because Rust implements generics by monomorphisation (like C++ templates), not by elision like Go (which is basically a glorified form of the C hack that consists in casting everything to void*). The moment you use Option, Result, any kind of container or iterator - that means all the time - the compiler must generate code for your particular type instantiation. It's great for both performance and safety, but it leads to binaries that contain lots of case-specific code. That's one reason why Rust can't be well suited for those use cases. But on the other hand, as even the lowest of the lowest systems get more RAM, the need for using C will diminish.

Result, Option and iterators are actually not that bad, since they mostly get turned into code much like you would write in C by inlining. Containers are by far the worst offender, and if you are using anync but aren't careful, then you can add futures too.

[soulsource]

Result, Option and iterators are actually not that bad, since they mostly get turned into code much like you would write in C by inlining. Containers are by far the worst offender, and if you are using anync but aren't careful, then you can add futures too.

Yep. I've been playing around with rust.godbolt.org a bit for a spare time project, where I want really good performance, and all methods I tried on those sum types and on iterators just get inlined (and optimized to the same assembly you get for imperative code). At least for reasonably sized data types.
Binary size is indeed a concern with Rust, but if cargo bloat is to be trusted, the by far biggest offender is actually hardcoded text...

[mmstick]

Rust can't be well suited for those use cases. But on the other hand, as even the lowest of the lowest systems get more RAM, the need for using C will diminish.

Actually, Jeremy Soller just today has a Rust project running on a Thinkpad 365ED with Windows 95 and 8M RAM. The problem of low RAM is solved by using an embedded scripting language tightly integrated with Rust: Rhai. He's calling this new DOS-like shell "ReDOS".

• https://mastodon.online/@jeremy_soll...85614840981375
• https://rhai.rs/

[archkde]

Yep. I've been playing around with rust.godbolt.org a bit for a spare time project, where I want really good performance, and all methods I tried on those sum types and on iterators just get inlined (and optimized to the same assembly you get for imperative code). At least for reasonably sized data types.
Binary size is indeed a concern with Rust, but if cargo bloat is to be trusted, the by far biggest offender is actually hardcoded text...

Hardcoded text indeed also contributes to binary size (how do you get this using cargo bloat btw?), mostly in the form of panic messages, which are mostly relevant for small binaries (they won't get much more as the amount of code increases).

[soulsource]

Hardcoded text indeed also contributes to binary size (how do you get this using cargo bloat btw?), mostly in the form of panic messages, which are mostly relevant for small binaries (they won't get much more as the amount of code increases).

Yeah, I misread the output of cargo bloat... The .text section contains the assembly. Now I'm feeling dumb...

[archkde]

Yeah, I misread the output of cargo bloat... The .text section contains the assembly. Now I'm feeling dumb...

No problem, you're not the first to make this mistake. It's not a cargo bloat thing, the ELF section containing the machine code is usually called .text and cargo bloat just reuses that. Hardcoded strings live in .rodata, which you will also see being proportionally large in smaller binaries.

[jacob]

Actually, Jeremy Soller just today has a Rust project running on a Thinkpad 365ED with Windows 95 and 8M RAM. The problem of low RAM is solved by using an embedded scripting language tightly integrated with Rust: Rhai. He's calling this new DOS-like shell "ReDOS".

• https://mastodon.online/@jeremy_soll...85614840981375
• https://rhai.rs/

Interesting, Thanks for sharing the links!