Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Kernel Prepares for Rust 1.77 Upgrade

phoronix.com

Post reply on HN
Print view View original

31–40 of 107 posts

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#31

Post by pornel »

habibur wrote: post #26
mcqueenjordan wrote: post #16

Earlier quoted context omitted.

Another thing just to mention here is `strip`, which IIRC `cargo build --release` doesn't do by default. I think `stripping` binaries can reduce binary size by up to 80-85% in some cases (but certainly not all; just tried it locally on a 1M rust binary and got 40% reduction). FWIW, you can configure this in Cargo.toml: [profile.release] strip = true

You can strip C compiled binaries too. And that halves the binary size. The point is for example a hello world Rust binaries is 300kb after striping while C compiled one is 15kb. A difference of 20 times.

Such comparison exaggerates the difference, because it’s a one-time constant overhead, not a multiplicative overhead.

i.e. all programs are larger by 275KB, not larger by 20x.

Rust doesn’t have the privilege of having a system-wide shared stdlib to make hello world executables equally small.

The overhead comes from Rust having more complex type-safe printf, and error handling code for when the print fails. C doesn’t handle the print error, and C doesn’t print stack traces on error. Most of that 200KB Rust overhead is a parser for dwarf debug info to print the stack trace.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#32

Post by nequo »

Aurornis wrote: post #11
kramerger wrote: post #4

The LKM post mentions binary size improvements. One issues I have had with Rust applications is the huge binary size (yes, I know this has improved a bit lately). Is there a good comparison between kernel C and kernel Rust code in this regard?

> One issues I have had with Rust applications is the huge binary size Turn off the standard library and your binaries can be incredibly small. This is how it’s used in microcontrollers and the Linux Kernel doesn’t use the full standard library either.

Due to dead code elimination, the compiler already omits all of that part of stdlib that your code doesn’t use.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#33

Post by Narishma »

habibur wrote: post #26
mcqueenjordan wrote: post #16

Earlier quoted context omitted.

Another thing just to mention here is `strip`, which IIRC `cargo build --release` doesn't do by default. I think `stripping` binaries can reduce binary size by up to 80-85% in some cases (but certainly not all; just tried it locally on a 1M rust binary and got 40% reduction). FWIW, you can configure this in Cargo.toml: [profile.release] strip = true

You can strip C compiled binaries too. And that halves the binary size. The point is for example a hello world Rust binaries is 300kb after striping while C compiled one is 15kb. A difference of 20 times.

But C doesn't statically link the standard library by default like Rust does.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#34

Post by steveklabnik »

SushiHippie wrote: post #2

Do I understand it correctly that upgrading to a new rust version is mostly implementing new best practices and new features, instead of needing to "fix" your code, as rust is backwards compatible? I've only used rust nightly for my own projects and didn't give too much thought about rust versions

Yes, generally. For example, recently David Tolnay shared the amount of burden Meta has when upgrading the compiler: https://old.reddit.com/r/rust/comments/19dtz5b/freebsd_discu...

> I estimate it's about ½ hour per 1 million lines, on average.

That being said, Rust for Linux isn't using stable Rust, so they have a higher burden than projects that do.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#35

Post by wongarsu »

surajrmal wrote: post #8
kramerger wrote: post #4

The LKM post mentions binary size improvements. One issues I have had with Rust applications is the huge binary size (yes, I know this has improved a bit lately). Is there a good comparison between kernel C and kernel Rust code in this regard?

Most size issues come from not using release builds, using too many dependencies, or overuse of generics. The rust std lib being linked in statically also contributes.The kernel shouldn't suffer from any of these problems. Plenty of embedded use is able to use rust in highly constrained environments without size issues compared to C.

If you do release builds, strip debug symbols and turn LTO from thin to full, do dependencies and the static stdlib still matter? You should be only paying for code that's called at that point.

At that point I suspect the biggest culprits are overuse of monomorphisation, and often just more stuff happening compared to equivalent C++ code because the language makes larger code bases more maintainable. I'd also count some niceties in that category like better string formatting or panic handling, which is an insignificant cost in any larger software but appears big in tiny hello-world type programs.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#36

Post by pornel »

nequo wrote: post #32
Aurornis wrote: post #11

Earlier quoted context omitted.

> One issues I have had with Rust applications is the huge binary size Turn off the standard library and your binaries can be incredibly small. This is how it’s used in microcontrollers and the Linux Kernel doesn’t use the full standard library either.

Due to dead code elimination, the compiler already omits all of that part of stdlib that your code doesn’t use.

Not quite. Every Rust program will have some code path that may panic, and the default panic handler uses debug formatting, which uses dynamic dispatch, which prevents elimination of the rest of the printing machinery.

There’s panic_immediate_abort unstable setting that makes Rust panics crash as hard as a C segfault, and only then you can get rid of a good chunk of stdlib.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#37

Post by surajrmal »

wongarsu wrote: post #35
surajrmal wrote: post #8

Earlier quoted context omitted.

Most size issues come from not using release builds, using too many dependencies, or overuse of generics. The rust std lib being linked in statically also contributes.The kernel shouldn't suffer from any of these problems. Plenty of embedded use is able to use rust in highly constrained environments without size issues compared to C.

If you do release builds, strip debug symbols and turn LTO from thin to full, do dependencies and the static stdlib still matter? You should be only paying for code that's called at that point. At that point I suspect the biggest culprits are overuse of monomorphisation, and often just more stuff happening compared to equivalent C++ code because the language makes larger code bases more maintainable. I'd also count s…

Overuse of monorphisation by the community is typically the right choice given the average use case for them is servers where this need not make a meaningful difference. As with any ecosystem, choices folks make may not be suitable for everyone. Those differing requirements require fracturing into smaller ecosystems which share common requirements. Ultimately, that's what's happening with rust and it's very healthy to see in my opinion. You can't force the overall ecosystem to optimize for a minority of users.

This is also true for everything in general. Having the one best thing for foo isn't as helpful as an array of choices, each with different tradeoffs. You simply choose the one best for your needs. Whether it's cheese at the supermarket, an webserver framework, operating system intrinsics, or command line argument handling. Some things can be standardized and serve as a common base for everyone, but it's challenging to do that without at least one person's requirements. Standards also always feature creep until someone tries to reset it with a new standard which is less complex, but I guess that's a different topic.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#38

Post by geertj »

rwmj wrote: post #20
amelius wrote: post #18

How many % of the kernel is Rust now, in terms of LoC?

Rust: 20,887 lines C: 33,351,596 lines (That's just doing 'wc -l' rather than using any proper code metrics tool)

How much of those 20K lines are Rust infrastructure, versus drivers written in Rust?

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#39

Post by surajrmal »

CUViper wrote: post #27
SushiHippie wrote: post #2

Do I understand it correctly that upgrading to a new rust version is mostly implementing new best practices and new features, instead of needing to "fix" your code, as rust is backwards compatible? I've only used rust nightly for my own projects and didn't give too much thought about rust versions

Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes. https://github.com/Rust-for-Linux/linux/issues/2

It seems prudent to limit rust usage in the kernel until that list can be burned down to zero. It makes sense that you need to at least get rust in the kernel to find out what missing features you need to have implemented and stabilized, but excessive use will make folks lives painful as they try to track upstream rust releases.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#40

Post by bonzini »

pornel wrote: post #29
SushiHippie wrote: post #2

Do I understand it correctly that upgrading to a new rust version is mostly implementing new best practices and new features, instead of needing to "fix" your code, as rust is backwards compatible? I've only used rust nightly for my own projects and didn't give too much thought about rust versions

Rust-for-Linux made it more complicated for themselves, because they chose to enable unstable/experimental features of the compiler without waiting until they’re released, so they don’t get the stability and compatibility guarantees that normal Rust projects get.

The alternative was to do the same and also not merge what they had. Stuff like custom allocator support is not optional.
Post reply on HN