Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust for Low-Level Linux Programming?

groveronline.com

Post reply on HN
Print view View original

121–130 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#121

Post by scythe »

Animats wrote: post #118

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch…

QNX is proprietary. Also, the NetBSD anykernel is where I think the sweetspot is.

Re: Why Rust for Low-Level Linux Programming?

#122

Post by bjourne »

Manishearth wrote: post #66
bjourne wrote: post #47

Earlier quoted context omitted.

From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.

So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C. The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using i…

I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier.

I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust.

> rust code shouldn't have any more overhead.

But it appears that it have.

> We also use llvm, so we get mostly the same compiler optimizations.

That is not a guarantee for efficient code. For example, in my testing, g++ is over 50% faster than clang++ in certain template-heavy scenarios.

Re: Why Rust for Low-Level Linux Programming?

#123

Post by pjmlp »

jdeeny wrote: post #88
pjmlp wrote: post #20

Earlier quoted context omitted.

A developer evangelist. Think someone doing a talk about new Java 9 features at a Java conference. C++ gurus and C magicians already have invested too deep into their languages to throw everything away and start from zero. For example I love Rust and play occasionally with it, but for the time being C++ is my native language on the job when I need to use a native language outside .NET or JVM. I know it since the C++A…

As a C magician, rust provides too many clear improvements over C to ignore it. I certainly don't feel like I am 'throwing everything away and starting from zero,' as much of my C (and other language) knowledge transfers over to rust. I'm not a C++ guru, but I think modern C++ is powerful enough that it doesn't feel lacking in features compared to rust, like C does. There is less of a draw for seasoned C++ programmer…

For me C was already lacking when I got to learn it in 1992 , because by then I was quite comfortable with Turbo Pascal 6.0.

Just check the feature list and type safety differences. The only advantage from C was being less fragmented than Pascal dialects.

So I became a C++ hipster (if that would be a thing in the 90's).

We used to have the same heat from C guys that C# and other language users nowadays have from systems languages.

Hence why I am always supportive of new programming languages that target the same use cases.

Re: Why Rust for Low-Level Linux Programming?

#124

Post by valarauca1 »

bjourne wrote: post #110
valarauca1 wrote: post #43

Earlier quoted context omitted.

This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html You're just cherry picking benchmarks. In the cases you care about raw number crunching power you'll likely be using a GPU not SIMD instructions as CPU's are roughly 3-4 orde…

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

>In 5 of 10 benchmarks, C is twice as fast as Rust

fannkuch-redux why? SIMD

fasta-redux why? SIMD

spectral-norm why? SIMD

reverse-complement why? SIMD

N-Body why? Oh you guessed it SIMD

Seriously read the source code. Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why. All 5 of these tests boil down to raw FLOPS. Which C/C++ having access to SIMD instructions wins at.

The fact that Rust/C performance difference works out to just the ability to emit vector instructions says a lot about everything else in Rust. The fact that Rust can dereference, pass variables on the stack, call functions, and make decisions as fast as C renders your core point completely moot.

You are just being incredibly pedantic for no reason. And your argument holds no water. Everything Rust does is identical to C except one barely used corner case. They use the exact same model for computation, they both live in the Cee-LangVM. Post compilation they are functionally identical (except Rust makes stack manipulation easier).

Does any of that make sense to you?

:.:.:

Also Rust/C both calling the GMP without a time difference is a good thing. The Rust->C FFI is literally non-existent in practice. Dipping into C code from Rust (and vice versa) has no penalty. The same can't be said for HUNDREDS of languages.

Re: Why Rust for Low-Level Linux Programming?

#125

Post by M2Ys4U »

pcwalton wrote: post #101
M2Ys4U wrote: post #89

Earlier quoted context omitted.

There are still plenty of crates that say "you need to be using nightly!". That put me off starting to develop something in Rust right now, unfortunately, because I'm a huge fan of the way Rust was developed and its core ideals.

We can't force people to use the stable version of Rust. But it does exist. And we're working on bringing the most popular nightly features to stable as soon as possible. In any case, even if you're using nightly your code won't break nearly as much as it did pre-1.0. We use nightly in Servo and we've been through dozens of Rust upgrades that sailed through without a hitch--and we have 150+ dependencies.

Oh absolutely - people are inevitably going to want to play with the new shiny (for various reasons, improved functionality and novelty being the two biggest), and Rust is still relatively young so the crate ecosystem is, while not small, not yet comprehensive.

This means that while Rust-the-language is stable, the ecosystem around it isn't quite yet. That's perfectly fine and it's nobody's fault, least of all the people developing the language. But it is one of the barriers to me picking it up right now, though.

Re: Why Rust for Low-Level Linux Programming?

#126

Post by Rusky »

bjourne wrote: post #110
valarauca1 wrote: post #43

Earlier quoted context omitted.

This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html You're just cherry picking benchmarks. In the cases you care about raw number crunching power you'll likely be using a GPU not SIMD instructions as CPU's are roughly 3-4 orde…

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

Nightly Rust is also "currently released and available," and a significant part of the ecosystem can take advantage of it.

Besides, the vast majority of the work to close the gap between C and Rust in the benchmark game was from people optimizing the benchmarked programs, not from any language or compiler changes. There is no inherent 2x slowdown in any meaningful sense.

Re: Why Rust for Low-Level Linux Programming?

#127

Post by Rusky »

bjourne wrote: post #122
Manishearth wrote: post #66

Earlier quoted context omitted.

So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C. The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using i…

I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier. I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. > rust code shouldn't have any more overhead. But it appears that it have. > We…

No, it does not appear that Rust has any overhead over C, except in cases that use SIMD. That is not a generally applicable result.

Re: Why Rust for Low-Level Linux Programming?

#128

Post by nemothekid »

bjourne wrote: post #122
Manishearth wrote: post #66

Earlier quoted context omitted.

So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C. The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using i…

I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier. I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. > rust code shouldn't have any more overhead. But it appears that it have. > We…

>I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust.

Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me.

In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM?

Don't back up your claim with flawed benchmarks.

Re: Why Rust for Low-Level Linux Programming?

#129

Post by valarauca1 »

Rusky wrote: post #126
bjourne wrote: post #110

Earlier quoted context omitted.

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

Nightly Rust is also "currently released and available," and a significant part of the ecosystem can take advantage of it. Besides, the vast majority of the work to close the gap between C and Rust in the benchmark game was from people optimizing the benchmarked programs, not from any language or compiler changes. There is no inherent 2x slowdown in any meaningful sense.

The inherent 2x slow down just works out to `__m128` vs `f64`. C can double Rust's FLOP thought-put.

The fact function calls, if statements, passing variables to functions is identical speed to C is lost on the parent poster. These core points prove the Rust/C are equal speed.

Re: Why Rust for Low-Level Linux Programming?

#130

Post by cpeterso »

scythe wrote: post #121
Animats wrote: post #118

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch…

QNX is proprietary. Also, the NetBSD anykernel is where I think the sweetspot is.

Or MINIX. You could rewrite MINIX's microkernel servers one by one. You have a working kernel and userspace on day one and the end result is a robust microkernel design written in a safe language.
Post reply on HN