Why Rust for Low-Level Linux Programming? • Hacker News Board

Re: Why Rust for Low-Level Linux Programming?

#61

Post by tatterdemalion » Fri, Jun 10, 2016, 7:07 PM UTC

bjourne wrote: post #47

frankmcsherry wrote: post #37

Earlier quoted context omitted.

Or it is faster than C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ). Depends which link you click on.

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.

You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.

Re: Why Rust for Low-Level Linux Programming?

#62

Post by frankmcsherry » Fri, Jun 10, 2016, 7:09 PM UTC

bjourne wrote: post #47

frankmcsherry wrote: post #37

Earlier quoted context omitted.

Or it is faster than C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ). Depends which link you click on.

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.

Yeah, given that the CPU load for the C lines are listed as

    100% 95% 95% 95%

on a quadcore, I'm going to say "not one thread".

Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.

Re: Why Rust for Low-Level Linux Programming?

#63

Post by kbenson » Fri, Jun 10, 2016, 7:10 PM UTC

bjourne wrote: post #47

frankmcsherry wrote: post #37

Earlier quoted context omitted.

Or it is faster than C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ). Depends which link you click on.

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.

Well, if you are familiar enough with the languages in question, you can look for what appear to be submissions that appear to use mostly idiomatic expressions of the language. Alternatively, if you are more interested in maximum possible performance, you can confirm both are making use of advanced techniques for quicker execution, but that's probably much harder to judge.

Re: Why Rust for Low-Level Linux Programming?

#64

Post by tatterdemalion » Fri, Jun 10, 2016, 7:10 PM UTC

epoch1970 wrote: post #52

steveklabnik wrote: post #40

Earlier quoted context omitted.

I will certainly concede the second, but we put a _lot_ of effort into ensuring that Rust is stable. Things have changed a lot since the pre-1.0 days.

> Things have changed a lot since the pre-1.0 days. The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?

The Rust project has been vocal about its stability guarantees; all that's left is to correct people when they claim the language isn't stable.

http://blog.rust-lang.org/2014/10/30/Stability.html

EDIT: As you can see from the number of responses you got, this matters a lot to the Rust community :-)

Re: Why Rust for Low-Level Linux Programming?

#65

Post by valarauca1 » Fri, Jun 10, 2016, 7:11 PM UTC

quickben wrote: post #55

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…

GPUs aren't panacea. Such generalizations are wrong and will have you rearchitecture approaches after GPU io bottlenecks.

>GPUs aren't panacea. Such generalizations are wrong

This is true. But if you are doing hard number crunching you are using a GPU once you exhaust what a CPU can do. And most the time before you even touch SIMD as it's only a 4-8x speed up, while a GPU is 1000-10,000x.

>will have you rearchitecture approaches after GPU io bottlenecks.

90% of these are caused by bad software. Either using legacy API's. Or by writing code that forces GPU's to talk to processor more often then is necessary.

PCIe bandwidth is ~7.88GB/s [1] on modern Intel Chips (post 3xxx series). Compute GPU's often offer >10GB of on-board RAM. With last generations flag ships over a staggering 32GB of on-board RAM.

And if you are hitting a wall with GPU compute/IO limits, CPU SIMD instructions aren't going to help you in the slightest.

[1] http://www.tested.com/tech/457440-theoretical-vs-actual-band...

Re: Why Rust for Low-Level Linux Programming?

#66

Post by Manishearth » Fri, Jun 10, 2016, 7:11 PM UTC

bjourne wrote: post #47

frankmcsherry wrote: post #37

Earlier quoted context omitted.

Or it is faster than C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ). Depends which link you click on.

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 it (cherry-picked!) to back up a claim that Rust is 2x slower than C is disingenuous. "but what can you do" -- don't make absolute arguments about something using imprecise data.

Actual rust in real world programs may actually end up being faster than C (see Yehuda Katz's talk on fast_blank in rust). C often needs to be hand-optimized. Rust, with its zero cost abstractions, often doesn't need to be; a naive program in rust would probably be faster than the same in C.

Remember that fundamentally rust compiles the same way c does, and your rust code shouldn't have any more overhead. (except drop flags -- a minor cost -- which are something you might hand-implement in c anyway). We also use llvm, so we get mostly the same compiler optimizations.

Re: Why Rust for Low-Level Linux Programming?

#67

Post by dikaiosune » Fri, Jun 10, 2016, 7:11 PM UTC

bjourne wrote: post #47

frankmcsherry wrote: post #37

Earlier quoted context omitted.

Or it is faster than C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ). Depends which link you click on.

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.

Both examples are cherry-picked, is the point. Neither is particularly helpful in representing the whole story.

That said, Rust makes it ridiculously easy to use parallelism if a task can support it, which is a strong advantage in its favor.

Re: Why Rust for Low-Level Linux Programming?

#68

Post by gue5t » Fri, Jun 10, 2016, 7:11 PM UTC

jjnoakes wrote: post #27

gue5t wrote: post #19

Earlier quoted context omitted.

As a C magician, I haven't written a new C project since the Rust 0.8 era. The only reason you would is ease of updating dependencies through distro package managers (because Rust has no stable ABI and performs extensive cross-library inlining). There's no need to market to C people because those who understand the language well will immediately get why Rust is better. For C++ people, Rust's generics remain less powe…

> The only reason you would is ease of updating dependencies Or if Rust doesn't support your OS yet. I am working on porting LLVM and writing a MIR to C++ translator in parallel. We'll see which one I get further on. Because I'd love nothing more than to use Rust.

Is the problem the OS, or the architecture/ABI? I wouldn't expect porting to a new OS to be terribly difficult, though it is a time sink since there's a fair bit of API surface to cover to get Rust's libstd ported, and you'd want to work with upstream so they know your platform matters.

If your OS doesn't look at all like UNIX, then you'll have to give up on libstd (which talks about "file"s and "processes" and such nonsense), but libcore (which presents data-structures and other logic, rather than IO, code) should be fine.

Re: Why Rust for Low-Level Linux Programming?

#69

Post by steveklabnik » Fri, Jun 10, 2016, 7:12 PM UTC

epoch1970 wrote: post #52

steveklabnik wrote: post #40

Earlier quoted context omitted.

I will certainly concede the second, but we put a _lot_ of effort into ensuring that Rust is stable. Things have changed a lot since the pre-1.0 days.

> Things have changed a lot since the pre-1.0 days. The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?

Well before 1.0 itself, we were already trying to telegraph our intentions here. October 2014! http://blog.rust-lang.org/2014/10/30/Stability.html

We try to be fairly vocal about the things we're doing here, but of course, it can be tough to get the word out. While some people may not know things have changed, a lot of people also do.

Some examples of things we do to ensure stability:

* The RFC process requires lots of discussion before major change happens, to ensure we can do things in a compatible way.

* We run a tool, "crater", both on PRs that we are worried might cause issues, and just in general. This tool compiles all of the open source Rust code on crates.io with the new revision, and reports problems. It's not perfect, but it helps a lot.

* For that matter, we don't merge any code ourselves; bors manages a fleet of 30ish machines that test every commit with our full test suite.

* We recently added three significant crates (and their dependencies, which last I checked was around 80ish crates in total?) to be part of our test suite, so we know that they build properly on every commit.

Re: Why Rust for Low-Level Linux Programming?

#70

Post by pcwalton » Fri, Jun 10, 2016, 7:13 PM UTC

epoch1970 wrote: post #52

steveklabnik wrote: post #40

Earlier quoted context omitted.

I will certainly concede the second, but we put a _lot_ of effort into ensuring that Rust is stable. Things have changed a lot since the pre-1.0 days.

> Things have changed a lot since the pre-1.0 days. The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?

> What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?

A lot? For example, "Stability as a Deliverable", which was here on HN: http://blog.rust-lang.org/2014/10/30/Stability.html

I'm not sorry for opening up the language during its early development. The alternatives would have been to produce a deeply flawed language or to keep the language secret. Both of these are far worse than a few ignorant comments.