Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
52 comments
-
I too fixed performance problems in that repo a few years back and did a write up on it - https://jackson.dev/post/rust-coreutils-dd/
I'm glad this project is getting some more attention, maybe even getting funding from Ubuntu since they're using it? Last time I touched it most of the code was still pretty clearly written by Rust beginners and non-systems programmers so it likely had/has many such issues to uncover. Ubuntu putting it into their distro should hopefully get more experienced (and actually paid!) devs taking a closer look.
-
They'll fix it... sounds like a skill issue, if base64 got fixed and performs better than c
-
a pull request has been made, and already merged.
-
I've heard that while Rust has the ability to be faster than Go and maybe C, it is a lot harder to write rust code to do it
-
Well, you need to type more and you need to learn more things with Rust, before you can start making stuff.
But the additional work is to make it easier for you to make changes later, when you come back to it after a while.So you might need to do more before hello world, but say if you have a complex library and want to use some function of it after learning Rust, it will be easier to not make some common mistakes.
A pretty good recent example of something that will cause a common mistake would be:
In the mongoc library, there is a function namedmongoc_client_select_serverand the pointer it returns requires destruction usingmongoc_server_description_destroy. But it doesn't say so in the function's comments/documentation. So, I had to go into the function called by the function called by the function called by it, to find the function making said pointer and having a comment stating that the pointer made by it would require destruction by the user.
And the only reason I found that out was my obsession, but I had already made the mistake.
-
-
Rust running slower than C?
Never would have guessed……
Edit: LMAO
-
The best thing about all the C smugness here is how quickly it backfired.
Out of dozens of utilities in uutils, two were slower than the GNU equivalents. In case the logic escapes some, that means that the others were already as fast or faster. Some are multiples faster. The overall uutils suite is faster then GNU Coreutils already and will only get better. There was nothing for C fans to be smug about to begin with.
Of the two that were slower, it seems to have only taken a few days to make them faster. The article only tells us about one which is now 50% faster than the GNU version.
But the promise of Rust is not that Rust is faster anyway. It is that it is easier and safer to refactor. The actual promise of Rust is that you can address issues like performance without as much fear that you will break everything.
After the reported slowness, both of the two uutils implementations were dramatically sped up in just a couple of days or even hours. They are tested against the GNU test suite and so we know these tests are still passing. That is the promise of Rust. This example proves the Rust claims real. The C smugness did not age well.
The C versions (GNU) can clearly be sped up as well. The question is who will do that and when. Because speeding up old C code is not nearly as easy or fun. My guess is that it is going to be more than a couple days before we see headlines bragging that GNU has caught up.
The GNU Coreutils are maintained by Red Hat if we look at who contributes the code and who maintains the dev servers. They are professionally maintained. It is not a rag tag bunch of amateurs. So if uutils is already faster, it does not bode well for the C implementation.
-
The overall uutils suite is faster then GNU Coreutils already and will only get better
just did a quick benchmark.
uutils
catis 2x slower.This is the unknown-linux-gnu release, the musl one is likely slower but didn't check.
-
52 comments