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

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

401–410 of 546 posts

Re: Speed of Rust vs. C

#401

Post by roca »

snovv_crash wrote: post #397
roca wrote: post #113

Earlier quoted context omitted.

I never wrote a parallel for-loop in 15 years working on Firefox, because it's hard in C++, it's risky and difficult to maintain the thread-safety invariants, and it's not all that useful in most parts of the browser. I write them quite often in Rust, because Rayon makes it super easy, there is almost no risk because the compiler checks the relevant thread-safety invariants, and I'm working on different problems wher…

I've used them extensively in C++. Doing it manually by managing your own threads is a pain, but simple OpenMP based parallel loops work really well, and also supports tasks like building vectors and simple reductions.

When your loop body uses complex library APIs over complex data it's still hard to be confident in C++ that everything's threadsafe and you're avoiding data races.

Maybe it's not so hard if you're in a domain like HPC where the libraries you use are designed specifically to be used with data parallelism. But when you're pulling together code from different sources that may or may not have been used in an aggressively parallel application before...

Re: Speed of Rust vs. C

#402

Post by igouy »

pornel wrote: post #285
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.

There's already The Benchmarks Game and ixy-languages if you want hard numbers. Maximum speeds are already explored. I wanted to discuss an aspect that's not typically covered by pure benchmarks: what can you expect from normal day-to-day use of these languages. Not fine-tuned hot loops, but a "median" you can expect when you just need to get shit done. If I tried to write a benchmark code to represent average, pract…

> Maximum speeds are already explored.

Also sub-maximum speeds — start at the bottom of the measurements and work up from the 5.37s g++ program to the 0.72s g++ program :-)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Speed of Rust vs. C

#403

Post by cb321 »

burntsushi wrote: post #369
cb321 wrote: post #361

Earlier quoted context omitted.

I am not trying to contradict anyone here, but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD. Cython/Nim/SBCL can all do that..probably Haskell..Not so sure about Go or Swift. Anyway, many languages can respond well to optimization effort. I doubt anyone disagrees. At the point of realizing the above no ceiling bit, the argument devolves…

You're missing the context I think. Look at what I was responding to in my initial message in this thread: > If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. My response is, "no you can't, and here's an example." > but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD If you port…

Ok. "Afford parallelism => afford high level" with the implication of HL=slow does sound pretty off base. So, fair enough.

FWIW, as per your subtle claim, it all seems pretty hot spot optimizable to me, at least if you include the memchr/utf8-regex engine in "hot spot". I do think the entire framing has much measurement vagueness ("hot", "vast majority", "levelness", and others) & is unlikely to be helpful, as explained. In terms of "evidence", I do not know of a competitor who has put the care into such a tool to even try to measure, though. { And I love rg. Many thanks and no offense at all was intended! }

Re: Speed of Rust vs. C

#404

Post by nyanpasu64 »

eqvinox wrote: post #282

Is it possible to do RCU in Rust? Without unsafe blocks?

@steveklabnik, RCU is different from RwLock in that the single writer and all readers never block each other.

Given that RCU is a complex wait-free data structure (though I don't fully understand it), I suspect it may not necessarily be possible to implement it without unsafe blocks, purely in terms of the standard library concurrency types (atomics and Arc can be used without unsafe, but themselves contain unsafe blocks). The general goal is to create an abstraction which encapsulates unsafe blocks such that it's impossible for outside users calling safe functions to violate memory safety. Of course, libraries sometimes have bugs that need to be fixed.

Re: Speed of Rust vs. C

#405

Post by howinteresting »

hctaw wrote: post #398
howinteresting wrote: post #371

Earlier quoted context omitted.

* You have to remember to do that. * I was thinking return values. * Also you can't use that style in an enum definition if you want to return a custom enum.

If you need api flexibility you use generics, and that is the way to be generic over types that refer to strs. I'm pretty sure this is in the book, and it's common enough that even someone who doesn't use rust full time (myself) knows it off the top of their head You can use impl Trait in returns, this is actually one of the reasons why that feature exists. And yes, you can use generics in an enum.

You have to expose the generic in the enum though. Rust doesn't have existential types at the moment.

Re: Speed of Rust vs. C

#406

Post by Animats »

gridspy wrote: post #400
Animats wrote: post #390

Earlier quoted context omitted.

Since this got so many upvotes, I'll say a bit more. I'm writing a viewer for a virtual world. Think of this as a general-purpose MMO game client. It has no built-in game assets. Those are downloaded as needed. It's a big world, so as you move through the world, more assets are constantly being downloaded and faraway objects are being removed. The existing viewers are mostly single thread, in C++, and they run out of…

Wonderful! Thanks for sharing. This sounds like the exact sort of work that Rust is perfect for. I'm making a game in Rust and Godot (engine) and since it's a factory game the simulation performance is important. Rust means I worry far less about stability and performance. I bet if you wrote a good blog entry with screenshots and explanation of how your code loads and renders I imagine it would do well on HN.

Too soon. Someday perhaps a Game Developers Conference paper/talk. I was considering one, but live GDC has been cancelled for 2021. My real interest in this is how do we build a big, seamless metaverse that goes fast. I'm far enough along to see that it's possible, but not far enough along that people can use the client.

Rust is good for this sort of thing. It's overkill for most web back end stuff. That's where Go is more useful. Go has all those well-used libraries for web back end tasks. Parallelism in web back ends tends to be about waiting for network events, not juggling heavy compute loads of coordinated disparate tasks. Hence all the interest in "async" for web servers. As I've said before, use the right tool for the job.

Re: Speed of Rust vs. C

#407

Post by gridspy »

Animats wrote: post #406
gridspy wrote: post #400

Earlier quoted context omitted.

Wonderful! Thanks for sharing. This sounds like the exact sort of work that Rust is perfect for. I'm making a game in Rust and Godot (engine) and since it's a factory game the simulation performance is important. Rust means I worry far less about stability and performance. I bet if you wrote a good blog entry with screenshots and explanation of how your code loads and renders I imagine it would do well on HN.

Too soon. Someday perhaps a Game Developers Conference paper/talk. I was considering one, but live GDC has been cancelled for 2021. My real interest in this is how do we build a big, seamless metaverse that goes fast. I'm far enough along to see that it's possible, but not far enough along that people can use the client. Rust is good for this sort of thing. It's overkill for most web back end stuff. That's where Go i…

One idea I liked was ...

You have an authoritive world simulation server, as usual.

You then have several servers whose chief job is to keep clients in sync with the authoritive server.

Most network games combine these two roles, but there is a lot of processing and network traffic required to keep clients in sync. For massive multiplayer there is a benefit to scale the "client-interaction" servers.

Re: Speed of Rust vs. C

#408

Post by jblow »

burntsushi wrote: post #345
jblow wrote: post #339

Earlier quoted context omitted.

> This alone, to me, says "to a first approximation, the speed of your program in 2021 is determined by the number of cores it uses" would be better than your statement. But I wouldn't even say that. You chose an embarrassingly parallel problem, which most programs are not. So you cannot generalize this example across most software. When you try to parallelize a structurally complicated algorithm, the biggest issue i…

> You chose an embarrassingly parallel problem Well, I mean, you chose an embarrassingly general statement to make? Play stupid games, win stupid prizes. > which most programs are not Programs? Or problems? Who says? It's not at all obvious to me that it's true. And even if it were true, "embarrassingly parallel" problems are nowhere close to uncommon. > When you try to parallelize a structurally complicated algorith…

If you do not understand that "embarrassingly parallel" is a technical term and that it's generally understood that most programs are not easily parallelizable, there is not a discussion we can have here.

Re: Speed of Rust vs. C

#409

Post by burntsushi »

cb321 wrote: post #403
burntsushi wrote: post #369

Earlier quoted context omitted.

You're missing the context I think. Look at what I was responding to in my initial message in this thread: > If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. My response is, "no you can't, and here's an example." > but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD If you port…

Ok. "Afford parallelism => afford high level" with the implication of HL=slow does sound pretty off base. So, fair enough. FWIW, as per your subtle claim, it all seems pretty hot spot optimizable to me, at least if you include the memchr/utf8-regex engine in "hot spot". I do think the entire framing has much measurement vagueness ("hot", "vast majority", "levelness", and others) & is unlikely to be helpful, as explai…

ack might be an example. It's Perl, not Python, and its author is on record as saying that performance isn't his goal. So it's a bit of a strained one. But yes, it's true, I don't know any other serious grep clone in a language like Python. This is why I hedged everything initially by saying that I know that absence of evidence isn't evidence of absence. :-) And in particular, I framed this as, "I would learn something," rather than, "this is objective fact." So long as my standard is my own experience, the hand wavy aspect of this works a bit better IMO.

> I do not know of a competitor who has put the care into such a tool to even try to measure, though.

Right. Like for example, I am certain enough about my claim that I would never even attempt to do it in the first place. I would guess that others think the same. With that said, people have written grep's in Python and the like, and last time I checked, they were very slow. But yeah, the "development effort" angle of this likely makes such tools inappropriate for a serious comparison to support my claim. But then again, if I'm right, the development effort required to make a Python grep be as fast as ripgrep is insurmountable.

> it all seems pretty hot spot optimizable to me

As long as we're okay with being hand wavy, then I would say that it's unlikely. Many of the optimizations in ripgrep have to do with amortizing allocation, and that kind of optimization is just nearly completely absent in a language like Python unless you drop down into C. This amortization principle is pervasive and applies as deep as regex internals to the code the simply prints ripgrep's output (which is in and of itself a complex beast and quite performance sensitive in workloads with lots of matches), and oodles of stuff inbetween.

> { And I love rg. Many thanks and no offense at all was intended! }

:-) No offense taken. This is by far the best convo I'm having in this HN post. Lol.

Note that I've made similar claims before. In the last one, there is a lot more data: https://news.ycombinator.com/item?id=17943509

Re: Speed of Rust vs. C

#410

Post by up2isomorphism »

gattr wrote: post #104

To practise Rust, I rewrote my small C99 library in it [1]. Performance is more or less the same, I only had to use unchecked array access in one small hot loop (details in README.md). I haven't ported multithreading yet, but I expect Rust's Rayon parallel iterators will likewise be comparable to OpenMP. [1] https://github.com/GreatAttractor/libskry_r

Your C library does not check malloc returns and also malloc and free everywhere inside library functions are not the best way to write a C library.
Post reply on HN