Notes on coreutils in Rust
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
-
System shared this topic on
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
I don't think anyone is relying on performance of coreutils. If you're concerned about performance, you're already writing a program directly, not using a shell script.
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
Why do you think it would affect performance?
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
I think your question is relevant as there are unfortunately plenty of shell scripts out there doing critical batch work. But it won't change the momentum of the Rust push happening right now.
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
Rust has some big binaries due to static linkage, and the Rust coreutils gets around this Busybox-style, compiling everything into one binary that you hard link to. Pretty neat. The project is easy to build and mess with without installing if you're curious about it. And you could add the build dir to the front of your path if you want to try it out with low risk.
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
It is faster, optimization is one of the uutils project's stated goals.
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
The performance you're dealing with here is in the tens of milliseconds possibly hundreds if you're lucky. Anyone seriously pursuing this issue from the angle of performance genuinely doesn't understand the deep rooted issues here.
If you're so incredibly hard up for compute time that it's critical for you to squeeze out the extra 1/10 of a second from your system utilities then you need to shut your fucking computer down and go touch grass.
-
I don't think anyone is relying on performance of coreutils. If you're concerned about performance, you're already writing a program directly, not using a shell script.
Relying on is perhaps too strong, but I enjoy operations like sort getting faster and I don't know how they've written cp but there's a cp alternative using async IO with io_uring that's almost twice as fast, I'm sure it'd interest people if such optimizations made it into coreutils.
-
The performance you're dealing with here is in the tens of milliseconds possibly hundreds if you're lucky. Anyone seriously pursuing this issue from the angle of performance genuinely doesn't understand the deep rooted issues here.
If you're so incredibly hard up for compute time that it's critical for you to squeeze out the extra 1/10 of a second from your system utilities then you need to shut your fucking computer down and go touch grass.
this was me watching some of the cheering when neofetch got archived, people complaining “good, neofetch is too slow” – WTF were you doing with neofetch where speed was a factor?!
-
this was me watching some of the cheering when neofetch got archived, people complaining “good, neofetch is too slow” – WTF were you doing with neofetch where speed was a factor?!
.bashrcgreeter? ;-;Not saying that neofetch going away was a good thing tho
-
.bashrcgreeter? ;-;Not saying that neofetch going away was a good thing tho
when the last message was “Have taken up farming.”, kinda hard to hold anything against them …
-
With Ubuntu changing to the Rust implementation of coreutils, what does that mean for performance?
Im more concerned about the stupid license
-
this was me watching some of the cheering when neofetch got archived, people complaining “good, neofetch is too slow” – WTF were you doing with neofetch where speed was a factor?!
On some systems neofetch would actually run quite slow. Even on my fast system it would occasionally take a second because it hung on one step.
-
The performance you're dealing with here is in the tens of milliseconds possibly hundreds if you're lucky. Anyone seriously pursuing this issue from the angle of performance genuinely doesn't understand the deep rooted issues here.
If you're so incredibly hard up for compute time that it's critical for you to squeeze out the extra 1/10 of a second from your system utilities then you need to shut your fucking computer down and go touch grass.
I’d take those tens of milliseconds. That shit scales and I’ve seen infra in the scale of millions more-or-less glued together by shell scripts and coreutils/busybox.
-
System shared this topic on
