Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#51

Post by CJefferson » Sat, Mar 13, 2021, 6:50 AM UTC

memco wrote: post #19

oivey wrote: post #8

Earlier quoted context omitted.

> As an observation, performance optimized code is almost always effectively single-threaded these days, even when using all the cores on a CPU to very efficiently process workloads. Not my experience at all. One big problem is that most languages in 2021 have very, very poor support for thread-based parallelism. It’s crazy how many languages make it hard to do basic data parallel tasks. That steers people toward wri…

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.

Re: Speed of Rust vs. C

#52

Post by benreesman » Sat, Mar 13, 2021, 6:53 AM UTC

A comparison between Rust and modern C++ would be more interesting in my opinion. It seems that those languages are closer in the design goal space than either is to C.

Re: Speed of Rust vs. C

#53

Post by [deleted] » Sat, Mar 13, 2021, 6:53 AM UTC

kelnos wrote: post #50

moonchild wrote: post #33

Earlier quoted context omitted.

Swift has a stable ABI. It makes different tradeoffs than rust, but I don't think complexity is the cliff. There is a good overview at https://gankra.github.io/blah/swift-abi/

Swift has a stable ABI at the cost of what amounts to runtime reflection, which is expensive. That doesn't really fit with the goals of Rust, I don't think.

[deleted]

Re: Speed of Rust vs. C

#54

Post by dnautics » Sat, Mar 13, 2021, 6:55 AM UTC

physicsguy wrote: post #40

jandrewrogers wrote: post #23

Earlier quoted context omitted.

FWIW, most supercomputing looks nothing like map-reduce; only the most trivial problems look like that. In a data model sense, a lot of supercomputing is join operation intensive, hence why they spend big bucks on high-bandwidth low-latency interconnects. STREAM benchmarks were more predictive of real-world supercomputing code performance than LAPACK in the majority of case 15+ years ago and it became more biased tow…

This is similar to my experience too. If people can write out a single Python function and apply it to all of a large amount of data then great, but that isn’t the majority of supercomputing programming.

I've done this across 10,000 cores, and helped people do similar tasks as well, I guess my experience is not normal. But IIRC even for things that, say use MPI to coordinate cores in the small you want to repeat across many cores, limit the spread across cores, limit your blocking coordination, lest you wind up with the old joke that "HPC is the art of turning a CPU-bound job into an I/O bound job".

Re: Speed of Rust vs. C

#55

Post by jandrewrogers » Sat, Mar 13, 2021, 7:05 AM UTC

CJefferson wrote: post #48

jandrewrogers wrote: post #29

Earlier quoted context omitted.

Parallelism in 2021 should not be tightly coupled across threads if performance matters, the limitations of that model are well-understood. There is no way to make that comparatively efficient; the CPU cache waste alone ensures that. Nothing you can do with thread support in a programming language will be competitive with e.g. a purpose-built scheduler + native coroutines. That’s right up against the theoretical limi…

I don't understand -- isn't what you are suggesting single threaded async code? That might be useful for servers, where you are mostly waiting for other things (like databases and networks), but in ithe places the point of parallel is to get all your CPUs doing useful work, and then (in my experience, happy to be shown counterexamples), coroutines aren't very useful. You just want to blast a bunch of threads (or righ…

Yes, roughly single-threaded async, with each core running a disjoint subset of the workload on data private to that core. You can’t beat the operation throughput. The software architecture challenge is shedding load between cores, since this will hotspot under real workloads with a naive design. Fortunately, smoothly and dynamically shedding load across cores with minimal overhead and latency is a solved design problem.

It works pretty well for ordinary heavy crunch code too. I originally designed code like this on supercomputers. You do need a practical mechanism for efficiently decomposing loads at a fine granularity but you rarely see applications that don’t have this property that are also compute bound.

Re: Speed of Rust vs. C

#56

Post by howinteresting » Sat, Mar 13, 2021, 7:09 AM UTC

memco wrote: post #19

oivey wrote: post #8

Earlier quoted context omitted.

> As an observation, performance optimized code is almost always effectively single-threaded these days, even when using all the cores on a CPU to very efficiently process workloads. Not my experience at all. One big problem is that most languages in 2021 have very, very poor support for thread-based parallelism. It’s crazy how many languages make it hard to do basic data parallel tasks. That steers people toward wri…

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…

I wrote a parallel iteration (map-reduce) last week in some CPU-heavy code, took 5 minutes with Rayon. Sped my code up by around 10x on a 12-core machine, example benchmark going from 7 seconds to 700 milliseconds. It's serious business.

Re: Speed of Rust vs. C

#57

Post by _a1_ » Sat, Mar 13, 2021, 7:20 AM UTC

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.

Re: Speed of Rust vs. C

#58

Post by eps » Sat, Mar 13, 2021, 7:21 AM UTC

viraptor wrote: post #6

vlmutolo wrote: post #4

> "Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). This made me laugh

It's not trivial to write a funny and clever burn, but this just hits the spot...

That's not a good burn though.

Re: Speed of Rust vs. C

#59

Post by CJefferson » Sat, Mar 13, 2021, 7:21 AM UTC

jandrewrogers wrote: post #55

CJefferson wrote: post #48

Earlier quoted context omitted.

I don't understand -- isn't what you are suggesting single threaded async code? That might be useful for servers, where you are mostly waiting for other things (like databases and networks), but in ithe places the point of parallel is to get all your CPUs doing useful work, and then (in my experience, happy to be shown counterexamples), coroutines aren't very useful. You just want to blast a bunch of threads (or righ…

Yes, roughly single-threaded async, with each core running a disjoint subset of the workload on data private to that core. You can’t beat the operation throughput. The software architecture challenge is shedding load between cores, since this will hotspot under real workloads with a naive design. Fortunately, smoothly and dynamically shedding load across cores with minimal overhead and latency is a solved design prob…

Ah, I understand now. I misinterpreted "no thread overhead" as meaning "I'm not running things in multiple threads", like the current node.js/javascript obsession, where we just run code in one thread and use a bunch of async to "parallelise". Sorry!

I've (badly) written code like you describe -- usually by abusing fork to do my initial data structure setup, then using C pipes to pass jobs around. I suspect there are much better ways of doing it, but that parallelised well enough for the stuff I was doing. I'd be interested to know if there are good libraries (or best practices) for doing this kind of parallelism.

Re: Speed of Rust vs. C

#60

Post by not_knuth » Sat, Mar 13, 2021, 7:22 AM UTC

What a well-written and interesting piece that gets to the point!

Compared to all the religious texts I've read about Rust, this is a huge breath of fresh air.

Thanks for sharing! Bookmarking this.