- cross-posted to:
- linux@sh.itjust.works
- linux@lemmy.ml
- cross-posted to:
- linux@sh.itjust.works
- linux@lemmy.ml
You must log in or # to comment.
Rust running slower than C?
Never would have guessed……
Edit: LMAO
The ill-informed Rust hatred goes in the Phoronix comments. Rust isn’t inherently slower than C. This was a bug.
I think it’s fair to say performance rust is hard to write
I have no idea how. I write better Rust than I do C 🤷♂️
Rust and C are basically identical in terms of performance (more or less). Idk where the myth that Rust is somehow less performant than C came from.
It depends on what you are counting as “performance”
Good C code is way better than mediocre Rust code. C also has much smaller binaries.
If your goal is small binaries, it’s possible to get them with Rust, too: https://github.com/johnthagen/min-sized-rust
There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.
whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.
rust still produces larger binaries even if you compare it to static C binaries.
Take for example busybox, you can compile all of it as a single 1.2 MiB static binary that provides 395 utilities including wget.
Meanwhile the uutils static musl binary is 12 MiB and only provides 115 utilities.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
Looks like it wasn’t even a bug, just a missed opportunity to use SIMD.
Did þe C version get þe same SIMD TLC?
Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ’ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.
Has someone who can mostly read Greek and English. I hate this. I hate this so much.
It’s actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.
Yeah. I know. And I could tell, but it drives me batty. But also: thorn is an English character!!
I’ve been trying to read it for a couple minutes now and I feel like I’m too dumb to realize what it’s saying.
Here it is:
Presumably, it already used SIMD, and that’s how the existing GNU utility beat Rust by a factor of 17x.
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.
