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.

[–] Blaster_M@lemmy.world 15 points 1 day ago (2 children)

They'll fix it... sounds like a skill issue, if base64 got fixed and performs better than c

[–] sga@piefed.social 9 points 1 day ago

a pull request has been made, and already merged.

[–] chocrates@piefed.world -1 points 1 day ago (2 children)

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

[–] trevor@lemmy.blahaj.zone 15 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] PlexSheep@infosec.pub 3 points 13 hours ago (1 children)

I have read papers for my bachelor's thesis that compared rust and c on x86-64 in terms of performance. It showed that C is a little or significantly faster, depending on the type of workload.

This is likely due to some runtime checks the rust compiler adds, and modified rust compilers that added less runtime checks led to about the same performance.

However, the performance is still very good for both languages (native machine code being executed), and in the same order of magnitude.

My own measurements for the armv6m architecture with an STM-32 showed that rust may even be faster in some cases, since the optimizing of the rust compiler was better, at least for that setup and for the CRC-32 algorithm.

[–] trevor@lemmy.blahaj.zone 1 points 8 hours ago* (last edited 6 hours ago)

Unless you're talking about some sort of reference counting, which has to be explicitly added by the programmer in cases where doing so is required for memory safety, I'm not sure what runtime checks you're referring to?

From what I've seen, the performance of programs written in C and Rust are generally the same, more or less, with C or Rust coming out on top with roughly coinflip odds in a handful of cases. This feels like the primary differentiator in performance really comes down to the implementation of the person writing it, and less to do with any performance differences inherent to either language.

[–] ulterno@programming.dev 6 points 1 day ago

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 named mongoc_client_select_server and the pointer it returns requires destruction using mongoc_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.

[+] Luci@lemmy.ca -23 points 1 day ago* (last edited 10 hours ago) (2 children)

Rust running slower than C?

Never would have guessed……

Edit: LMAO

[–] trevor@lemmy.blahaj.zone 37 points 1 day ago* (last edited 1 day ago) (2 children)

The ill-informed Rust hatred goes in the Phoronix comments. Rust isn't inherently slower than C. This was a bug.

[–] BatmanAoD@programming.dev 15 points 1 day ago (1 children)

Looks like it wasn't even a bug, just a missed opportunity to use SIMD.

[–] Sxan@piefed.zip -5 points 1 day ago (1 children)

Did þe C version get þe same SIMD TLC?

[–] BatmanAoD@programming.dev 17 points 1 day ago (1 children)

Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ'ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.

[–] echindod@programming.dev 9 points 1 day ago (2 children)

Has someone who can mostly read Greek and English. I hate this. I hate this so much.

[–] prettybunnys@sh.itjust.works 8 points 1 day ago

I feel like it’s the best response to that user though. Amazing

[–] BatmanAoD@programming.dev 3 points 1 day ago (1 children)

It's actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.

[–] echindod@programming.dev 1 points 15 hours ago (1 children)

Yeah. I know. And I could tell, but it drives me batty. But also: thorn is an English character!!

[–] BatmanAoD@programming.dev 1 points 14 hours ago

Sure, Old English. But the commenter isn't writing in old or even middle English.

[–] chocrates@piefed.world 0 points 1 day ago (4 children)

I think it's fair to say performance rust is hard to write

[–] trevor@lemmy.blahaj.zone 10 points 1 day ago (1 children)

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.

[–] possiblylinux127@lemmy.zip -1 points 1 day ago (4 children)

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.

[–] trevor@lemmy.blahaj.zone 6 points 1 day ago* (last edited 1 day ago) (1 children)

"Thing I say is good, is better than thing I say is mediocre."

Indeed.

[–] ulterno@programming.dev -4 points 1 day ago

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?

[–] BatmanAoD@programming.dev 5 points 1 day ago* (last edited 1 day ago) (2 children)

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.

[–] Samueru_sama@programming.dev 1 points 23 hours ago (1 children)

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.

[–] BatmanAoD@programming.dev 2 points 14 hours ago (1 children)

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.

[–] Samueru_sama@programming.dev -2 points 13 hours ago* (last edited 13 hours ago) (1 children)

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

Such as? busybox provides a nice interactive shell, awk, bc, wget and much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.

busybox also implements [[ from bash, none of this is provided by uutils or coreutils.

EDIT: busybox also provides grep while the uutils/coreutils don't.

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.

I'm assuming this uses -Os which means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.

[–] BatmanAoD@programming.dev 2 points 13 hours ago (1 children)

From the busybox "about" page:

The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts.... BusyBox has been written with size-optimization and limited resources in mind.

Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don't think there is a comparable Rust project for minimized utilities.

[–] Samueru_sama@programming.dev 0 points 13 hours ago (1 children)

The utilities in BusyBox generally have fewer options than their full-featured GNU cousins

Note: GNU cousins, not GNU coreutils.

GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.

If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.

[–] BatmanAoD@programming.dev 2 points 12 hours ago (1 children)

Busybox ls has 26 flags. GNU ls has 60.

[–] Samueru_sama@programming.dev 0 points 12 hours ago (1 children)

fair, in that case the comparison is even since busybox provides a shell, awk, grep, wget among other 395 utils, uutils it is 115.

[–] BatmanAoD@programming.dev 3 points 11 hours ago

I really don't think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.

[–] possiblylinux127@lemmy.zip -3 points 1 day ago (3 children)

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.

[–] BatmanAoD@programming.dev 5 points 1 day ago (1 children)

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.

[–] possiblylinux127@lemmy.zip 0 points 16 hours ago (1 children)

I find it way easier just to use C

It is simple and clean

[–] BatmanAoD@programming.dev 3 points 14 hours ago

That's fine, just please don't spread misinformation about a language you don't use.

[–] zygo_histo_morpheus@programming.dev 4 points 23 hours ago

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"

[–] ulterno@programming.dev -1 points 1 day ago

Wasn't Rust originally made for embedded systems to reduce the time taken debugging runtime errors by shifting those to compile time?

[–] calcopiritus@lemmy.world 4 points 11 hours ago

"good code is better than mediocre code" definitely one of the statements of all time.

[–] chocrates@piefed.world 1 points 6 hours ago

Was a typo, meant "performant"

[–] LeFantome@programming.dev 4 points 14 hours ago* (last edited 13 hours ago) (1 children)

think it's fair to say performance rust is hard to write

This situation proved exactly the opposite.

They wrote a utility to pass functional tests. It did. Then people said it was too slow. So, in just a few days or hours, they dramatically sped it up while still passing the tests.

Seems like it was pretty easy to write fast Rust code in this case.

[–] chocrates@piefed.world 1 points 6 hours ago

Fair point. I am mostly going on what I have seen others do on streams when comparing rust and go. Go seemed faster to get good performance and rust sometimes had to write a ton of code to get the same performance.

I don't know if you can selectively not use Go's garbage collector, but that seems to be the only reason Go might be theoretically slower than rust.

[–] BatmanAoD@programming.dev 1 points 1 day ago (1 children)

Harder than C?

[–] chocrates@piefed.world 2 points 6 hours ago (1 children)

I think I am conflating "harder" and "have to write more code"

[–] BatmanAoD@programming.dev 1 points 4 hours ago

Fair!

[–] zygo_histo_morpheus@programming.dev 1 points 23 hours ago

What makes you say that?

[–] LeFantome@programming.dev 6 points 14 hours ago* (last edited 14 hours ago) (1 children)

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.

[–] Samueru_sama@programming.dev 0 points 10 hours ago

The overall uutils suite is faster then GNU Coreutils already and will only get better

just did a quick benchmark.

collapsed inline media

uutils cat is 2x slower.

This is the unknown-linux-gnu release, the musl one is likely slower but didn't check.