- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
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.This is not true. If you know Rust and C equally well, you’re likely going to write equally performant Rust.
You could say that Rust is harder to learn than C. I’d disagree based on my personal experience, but you wouldn’t be wrong.
Rust running slower than C?
Never would have guessed……
The ill-informed Rust hatred goes in the Phoronix comments. Rust isn’t inherently slower than C. This was a bug.
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.
I feel like it’s the best response to that user though. Amazing
It’s actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.
I think it’s fair to say performance rust is hard to write
What makes you say that?
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.
“Thing I say is good, is better than thing I say is mediocre.”
Indeed.
But will a good hello world program, made in JS, run on Firefox on an Embedded Windows 11 OS, running on a CPU emulator running on WASM on Edge be more performant than a mediocre hello world program in C, running on Linux on the same hardware that Edge run on?
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.
C is still better for the embedded world
If you have gigabytes of storage and memory Rust makes more sense. C shines as it allows fine control over memory. The fact that you can tie into The system libraries makes it very resource friendly since you don’t need redundant code.
You can tailor the rust standard library to be more embedded friendly in several way, like if you don’t have dynamic memory allocation or a filesystem, you can get the standard library sans those features.
Rust also gives you a very fine grained level of control of memory, I think equivalent to C (maybe there’s some gotcha that I’m not aware of but if not equivalent very close).
It really doesn’t sound like you know that much about Rust here and are just making things up, you certainly don’t need “gigabytes of storage and memory”
I think you’re making some poorly-researched assumptions.
In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print
Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.
Wasn’t Rust originally made for embedded systems to reduce the time taken debugging runtime errors by shifting those to compile time?
Harder than C?
