Rust Coreutils 0.0.28 Delivers Better Performance & Increased Compatibility

[phoronix]

Phoronix: Rust Coreutils 0.0.28 Delivers Better Performance & Increased Compatibility

Rust Coreutils 0.0.28 "uutils" has been released for this implementation of the GNU Coreutils utilities within the Rust programming language for better memory safety and greater robustness. With the Rust Coreutils 0.0.28 there is increased GNU compatibility as well as better performance...

https://www.phoronix.com/news/Rust-Coreutils-uutils-0.0.28

[Quackdoc]

really hope one day they expand uutils to cover most of the busybox suite and wrap all the uutils into one binary. It would be cool to see how a real rust busybox would look like.

[Gamer1227]

really hope one day they expand uutils to cover most of the busybox suite and wrap all the uutils into one binary. It would be cool to see how a real rust busybox would look like.

The point of busybox is to have small binary size, uutils need heavy optimizations to compete with coreutils, wich will bloat the binary.

You cant have both in 1 binary, at best the developers could use conditional compilation to remove optimized paths in the final binary, to create a light version.

[rmfx]

How does uutils coreutils compares
to gnu coreutils in terms of perfs?
are there reliable benchmarks available?

[Quackdoc]

The point of busybox is to have small binary size, uutils need heavy optimizations to compete with coreutils, wich will bloat the binary.

You cant have both in 1 binary, at best the developers could use conditional compilation to remove optimized paths in the final binary, to create a light version.

This all depends on your needs. when compiling you can compile for size or for performance which has a large impact on binary size, likewise using something like fat lto can significantly lower the file size, will it compete 1:1 with busybox? probably not, but there is a good chance of it getting small enough to still be usable.

for instance, coreutils as it stands sits at 9.2M (8.4M with strip) with release-fast and 5.7 with release-small when compiled with mold, but that's without doing any additional mucking about like compiling std. After using UPX (which is more then fine for my needs) coreutils sits at 2.4M for release-fast and 1.7M for release-small. both of these are still bigger then busybox obviously as you said, but this is still more then good enough for my needs.

[ahrs]

The point of busybox is to have small binary size, uutils need heavy optimizations to compete with coreutils, wich will bloat the binary.

You cant have both in 1 binary, at best the developers could use conditional compilation to remove optimized paths in the final binary, to create a light version.

At least rust has feature flags, in theory you could compile out a lot of the features you don't need, as is common with Busybox (it's rare to see a Busybox with all of the applets compiled in and enabled in my experience).

[F.Ultra]

How does uutils coreutils compares
to gnu coreutils in terms of perfs?
are there reliable benchmarks available?

perhaps we should wait until the remaining 94 tests are not failing before we even think about performance

[rmfx]

perhaps we should wait until the remaining 94 tests are not failing before we even think about performance

Ok then first perf comparisons in 5 years then.

You don’t need full compliance to start a benchmark. The failing cases are for peculiar cases.

[Nth_man]

"The non-GPL licensing makes this a disaster. Please don't contribute to this project"
-- Upvoted 44 times at least: https://www.phoronix.com/forums/foru...74#post1398174

[F.Ultra]

Ok then first perf comparisons in 5 years then.

You don’t need full compliance to start a benchmark. The failing cases are for peculiar cases.

ofc you need that, or else you are benchmarking code with different feature sets. And 94 failed tests does not sound like fringe cases, but then I have not looked further into it than that so you could be right.