Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#221

Post by efficax » Sat, Mar 13, 2021, 2:32 PM UTC

brink wrote: post #166

phkahler wrote: post #153

Earlier quoted context omitted.

>> 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?

The simplest (and often best) option is to use the Arc > pattern. The Arc is an async reference counter that allows multiple ownership. And the nested Mutex enforces only one mutable borrow at a time.

I think you mean that Arc is an atomic reference counter (it uses atomic cpu instructions to prevent race conditions when incrementing and decrementing the ref count)

Re: Speed of Rust vs. C

#222

Post by ReactiveJelly » Sat, Mar 13, 2021, 2:32 PM UTC

alerighi wrote: post #144

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…

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

Deadlocks are unique to Rust, eh?

Re: Speed of Rust vs. C

#223

Post by burntsushi » Sat, Mar 13, 2021, 2:35 PM UTC

alerighi wrote: post #144

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…

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

This is a bad take. ripgrep, to my knowledge, cannot be written in a higher level language without becoming a lot slower.[1] And yet, if I removed its use of parallelism by default, there will be a significantly degraded user experience by virtue of it being a lot slower.

This isn't an "obsession." It's engineering.

[1] - I make this claim loosely. Absence of evidence isn't evidence of absence and all that. But if I saw ripgrep implemented in, say, Python and it matched speed in the majority of cases, I would learn something.

Re: Speed of Rust vs. C

#224

Post by burntsushi » Sat, Mar 13, 2021, 2:38 PM UTC

ben0x539 wrote: post #184

eru wrote: post #180

Earlier quoted context omitted.

> In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simplicity and solidity using a single thread is really fine. Depends on which of the classic utilities you are talking about. Many of them are typically IO bound. You might not get much out of throwing more CPU at them.

ripgrep? :)

Indeed. Many of the optimizations ripgrep (and the underlying regex engine) does only show benefits if the data you're searching is already in memory.[1] The same is true of GNU grep. This is because searching data that's in your OS's file cache is an exceptionally common case.

[1] - I'm assuming commodity SSD in the range of a few hundred MB/s read speed. This will likely become less true as the prevalence of faster SSDs increases (low single digit GB/s).

Re: Speed of Rust vs. C

#225

Post by ReactiveJelly » Sat, Mar 13, 2021, 2:39 PM UTC

I'm a Rust evangelist, but the article is titled "Speed of Rust vs. C" and doesn't seem to contain even one benchmark.

For fuck's sake.

Re: Speed of Rust vs. C

#226

Post by mariusor » Sat, Mar 13, 2021, 2:40 PM UTC

CJefferson wrote: post #51

memco wrote: post #19

Earlier quoted context omitted.

I was really struck by a comment Jonathan Blow made on stream recently: he said he’s never written a parallel for loop in his whole career. I seem to recall the implication being that they’re often not really necessary for performant code. There’s also been some discussion lately about issues with asynchronous code both in Rust and Python. Point being that parallelism still had a ways to go before it’s proven it’s us…

The world is full of highly parallel programs getting useful work done. Most graphics, AI and compression libraries (picking 3 easy examples I've worked on) parallelize well, and can usually make use of all the cores you can throw at them. Jonathan Blow makes good games, but chooses not to make particularly CPU intensive ones. That's fine, but that's also his choice.

He's also currently building one of the fastest compilers around. It's unreasonable to consider that he never encountered use cases where parallelism makes sense.

Re: Speed of Rust vs. C

#227

Post by ragnese » Sat, Mar 13, 2021, 2:42 PM UTC

TazeTSchnitzel wrote: post #195

scorpion95 wrote: post #90

Earlier quoted context omitted.

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…

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it. Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing. A very simple example: void foobar(struct foo *f) { f->a += 2; foo(); f->a += 2; b…

> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can.

Can it, though? I keep hearing/reading FUD around both unsafe and Pin making it unlikely to ever be able to ubiquitously enable the noalias stuff.

Re: Speed of Rust vs. C

#228

Post by tazjin » Sat, Mar 13, 2021, 2:42 PM UTC

ReactiveJelly wrote: post #225

I'm a Rust evangelist, but the article is titled "Speed of Rust vs. C" and doesn't seem to contain even one benchmark. For fuck's sake.

In my opinion, the level of detail in this article is much more useful than small benchmarks of code that doesn't resemble real applications anyways.

Re: Speed of Rust vs. C

#229

Post by orf » Sat, Mar 13, 2021, 2:42 PM UTC

pjmlp wrote: post #125

gridspy wrote: post #98

Earlier quoted context omitted.

The very short version: There are many things which cause both frequent and rare strange crashes in multi-threaded code. In C, all these things will compile OK. In safe Rust, practically none of them will compile. It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.

Accessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.

What a silly point to make. The code you’re writing in rust could launch a nuke that destroys the world and it will also compile just fine.

Re: Speed of Rust vs. C

#230

Post by teleforce » Sat, Mar 13, 2021, 2:43 PM UTC

nindalf wrote: post #70

_a1_ wrote: post #57

I appreciate the article, but it would be really nice if the author could add a timestamp to his blog posts. Without timestamps, it's impossible to know if any issue described in the article body still exists. I didn't read it, because it might present outdated knowledge.

I read it. Didn’t find any outdated information in it.

Please check reply by dig1, it does contains some mis-information. It even incorrectly refer to the Heartbleed problem.