Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#151

Post by zesterer » Sat, Mar 13, 2021, 12:19 PM UTC

scorpion95 wrote: post #90

Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

> My overall feeling is that if I could spend infinite time and effort, my C programs would be as fast or faster than Rust, because theoretically there's nothing C can't do that Rust can.

The exact same argument applies to assembly code. There are very good reasons that it's not used nowadays except in incredibly rare circumstances or in the embedded world.

It doesn't matter in the slightest how fast your language is in theory. Not one iota.

The only thing that matters is how fast the programs you write with it are in practice. The evidence is clear: it is significantly easier to write faster programs in Rust than it is in C, and this applies to even the most skilled developers.

Re: Speed of Rust vs. C

#152

Post by zesterer » Sat, Mar 13, 2021, 12:23 PM UTC

Code 'bloat' is a bizarre metric to use for anything unless you're on a platform with incredibly constrained executable memory like an embedded device.

The fact that Rust specialises its generic code according to the type it's used with it not some inherent disadvantage of generics. That's what they're supposed to do. By choosing to not specialise, you're actively making the decision to make your code slower. Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brilliantly.

When you use void* in your data structures in C, you're not winning anything when compared to Rust. You're just producing slower code that mimics the behaviour of Rust's trait objects, but more dangerously.

Code 'bloat' (otherwise known as 'specialising your code correctly to make it run faster') is not a reason to not use Rust in 2021, so please stop pretending that it is.

Re: Speed of Rust vs. C

#153

Post by phkahler » Sat, Mar 13, 2021, 12:25 PM UTC

Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene.

How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?

Re: Speed of Rust vs. C

#154

Post by bluejekyll » Sat, Mar 13, 2021, 12:25 PM UTC

pjmlp wrote: post #147

bluejekyll wrote: post #141

Earlier quoted context omitted.

You have made this claim multiple times. Why do you see this as a language issue and not an OS issue? It becomes an even bigger problem when we talk about distributed systems and distributed resources. Is there a language that handles this? These issues about multiple processes and distributed systems are framework and OS level concerns. Rust helps you build fast concurrent solutions to those problems, but you’re cor…

Fearless concurrency sales pitch. Yes languages like Erlang and runtimes like Coyote and Orleans.

Erlang has a great concurrency model with higher overhead than Rust, but similar cross thread safety, doesn’t do anything about exterior resources to the application.

I’ve not worked with Coyote, but if it is the system for .net, it describes itself as a framework, “Coyote provides developers a programming framework for confidently building reliable asynchronous software on the .NET platform”.

Orleans similarly describes itself as a framework, “Orleans is a cross-platform software framework for building scalable and robust distributed interactive applications based on the .NET Framework.”

Rust is a language, similar frameworks are being built with it, the point your making does not appear to be about the language.

Re: Speed of Rust vs. C

#155

Post by zesterer » Sat, Mar 13, 2021, 12:30 PM UTC

mratsim wrote: post #150

> There are other kinds of concurrency bugs, such as poor use of locking primitives causing higher-level logical race conditions or deadlocks, and Rust can't eliminate them, but they're usually easier to diagnose and fix. Which is why so many people are creating formal verification languages and spending years in research to fix those ... That just isn't true. It's a very complex problem that is an issue in both hard…

You've just taken the word 'fearless', a word that's clearly subjective, and said that the definition the author gives of it "couldn't be more wrong". That's... a choice.

Re: Speed of Rust vs. C

#156

Post by Tuna-Fish » Sat, Mar 13, 2021, 12:30 PM UTC

zesterer wrote: post #152

Code 'bloat' is a bizarre metric to use for anything unless you're on a platform with incredibly constrained executable memory like an embedded device. The fact that Rust specialises its generic code according to the type it's used with it not some inherent disadvantage of generics. That's what they're supposed to do. By choosing to not specialise, you're actively making the decision to make your code slower . Rust h…

It's not that simple. While fully specializing everything wins microbenchmarks, as C++ has shown time and time again, it can easily lose performance in large applications. If fully specializing code saves a few branches in the hot loop, but also blows through all the L1i, it can easily be a huge net negative.

> Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brilliantly.

As someone who uses a lot of rust, they are sort of the red-headed stepchild. As a minimum to make the properly usable, we need a way of passing one object with multiple different traits.

Re: Speed of Rust vs. C

#157

Post by fulafel » Sat, Mar 13, 2021, 12:32 PM UTC

bluejekyll wrote: post #141

pjmlp wrote: post #124

Earlier quoted context omitted.

While it works great for some cases, one should not forget it doesn't cover external resources, specially those shared across processes.

You have made this claim multiple times. Why do you see this as a language issue and not an OS issue? It becomes an even bigger problem when we talk about distributed systems and distributed resources. Is there a language that handles this? These issues about multiple processes and distributed systems are framework and OS level concerns. Rust helps you build fast concurrent solutions to those problems, but you’re cor…

How could an OS adapt its processes functionality to help Rust here?

Re: Speed of Rust vs. C

#158

Post by sullyj3 » Sat, Mar 13, 2021, 12:33 PM UTC

brwell wrote: post #91

> "Clever" memory use is frowned upon in Rust. In C, anything goes. No, it does not. If Rust programmers don't have discipline in C, other people have. And don't drag out some random CVE numbers again. These are about a fraction of existing C projects, many of them were started 1980-2000. It is an entirely different story if a project is started with sanitizers, Valgrind and best practices. I'm not against Rust, exce…

C programmers like to talk about discipline, but no human is more disciplined than a compiler.

Re: Speed of Rust vs. C

#159

Post by varajelle » Sat, Mar 13, 2021, 12:33 PM UTC

12thwonder wrote: post #134

I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size. am I a minority having this opinion?

C with generics and destructors and containers in the standard library. We could call that language C++.

Re: Speed of Rust vs. C

#160

Post by fulafel » Sat, Mar 13, 2021, 12:35 PM UTC

riquito wrote: post #92

pmarin wrote: post #89

Earlier quoted context omitted.

Without real world data "fearlessly parallelizing all the things!" is an awful idea due to all the overhead involved. The most important design decision while writing a parallel algorithm is to decide for what amount of data is not worth it.

He tried with few effort and noticed that for his use case the code is faster, I fail to understand this rebuttal of the parent's comment

As a general thought about parallelizing all the things it's true though. When looking for speedups, parallelization granularity has to be tuned and iterated with benchmarking, else your speedups will be poor or negative.

I think the example case in this subthread was about making some long app operations asynchronous and overlapping, which is a more forgiving use case than trying to make a piece of code faster by utilizing multiple cores.