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

391–400 of 546 posts

Re: Speed of Rust vs. C

#391

Post by dr-ando »

gspr wrote: post #197
rectang wrote: post #18

Earlier quoted context omitted.

> ABI compatibility Rust provides ABI compatibility against its C ABI, and if you want you can dynamically link against that. What Rust eschews is the insane fragile ABI compatibility of C++, which is a huge pain to deal with as a user: https://community.kde.org/Policies/Binary_Compatibility_Issu... I don't think we'll ever see as comprehensive an ABI out of Rust as we get out of C++, because exposing that much incid…

Rust seems great to me, but aren't we losing a lot by giving up on C's dynamic linking and shared libraries?

I am sympathetic to the point you make but to be accurate, one can consume and create C and C compatible dynamic libraries with rust. So, one is not “losing” something because what you (and me) want - dynamic linking and shared libraries with a stable and safe rust ABI - was not there to begin with.

Re: Speed of Rust vs. C

#392

Post by howinteresting »

pjmlp wrote: post #385
howinteresting wrote: post #333

Earlier quoted context omitted.

Have you ever had to deal with tail latency due to memory pressure on web or backend services? Command-line tools are also ideal for Rust because startup performance matters a lot there.

Yes, writing distributed systems since 1999. What was done in C, C++ and Tcl, I nowadays use Java and .NET languages. If we really need something low level that either Java or .NET cannot offer, a native library for a specific component will do, no need to throw the whole thing away and do one of those rewrite blog posts.

Tail latency due to memory pressure tends to be inherent to the nature of garbage collected languages with mutable state. This is not an issue if you have more RAM then the system needs, but often RAM is extremely scarce.

Re: Speed of Rust vs. C

#393

Post by hsaliak »

howinteresting wrote: post #328
hsaliak wrote: post #296

For parallelism, Modern tooling like TSAN can close the gap somewhat. If you are planning to introduce threads, not testing it with TSAN is silly at best.

If you're writing safe, parallel Rust code, you don't really need to use TSAN. You may hit a deadlock sometimes, but those tend to be easy to figure out in my experience. The people implementing the libraries you use (e.g. Rayon) may have to use TSAN, of course.

For sure - I was mentioning TSAN in the context of threaded C code

Re: Speed of Rust vs. C

#394

Post by pornel »

nyc_pizzadev wrote: post #219

Shouldn’t this be Rust vs C++? C++ has a lot more parallels to Rust. Both are big, complex, and safe languages that can tuned for high performance. Infact, I would like to see more comparisons of Rust and C++ in the future.

Author here: I'm a C programmer, who's replacing C with Rust. I've never liked C++ and never felt I fully get it. I've managed to fully grasp Rust though. I don't see that much similarity between Rust and C++ other than both use angle brackets for generic code and aspire to have zero-cost abstractions.

C programming patterns have more-or-less equivalents in Rust. OTOH non-trivial C++ OOP or template usage is alien and hard to adapt to Rust.

Rust has 1 (one) way to initialize an object. No constructors, initializer lists, or rules-of-. Move semantics are built-in, without move/copy constructors/NRVO/moved-out-of state. No inheritance. No object truncation. Methods are regular function pointers. No SFINAE (generics are equivalent to concepts, and dumber, e.g. no variadic). Iterators require only implementing a single method. Operator overloading is all done in the style of the spaceship operator.

It's not the same kind of complexity.

Re: Speed of Rust vs. C

#395

Post by jsjohnst »

bsder wrote: post #110
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…

> Code converted from C to Rust seems much more voluminous. This is a fairly odd claim. If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose. If you need a data structure more complex than an array of something, C is stupidly verbose. If you want to deal with pattern matching/regexen, C is ridiculously verbose. Do I agree that Rust is far more verbose for an embedded "blinky" (the embedd…

I mostly agree with your post but:

> If you need a data structure more complex than an array of something, C is stupidly verbose.

What’s stupidly verbose about Structs to you?

Re: Speed of Rust vs. C

#396

Post by mariusor »

memco wrote: post #266
mariusor wrote: post #226

Earlier quoted context omitted.

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.

Indeed, he wasn’t saying parallelism is not useful, just that the specific construct of a parallel for loop was not in his wheelhouse for certain reasons.

My impression of Jon's work is that he requires low enough level access to his hardware so he's the one that makes decisions about where and what runs. Language level parallel for is definitely not that. :D

Re: Speed of Rust vs. C

#397

Post by snovv_crash »

roca wrote: post #113
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…

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.

Re: Speed of Rust vs. C

#398

Post by hctaw »

howinteresting wrote: post #371
hctaw wrote: post #362

Earlier quoted context omitted.

fn func (slice: &[impl AsRef ]) { // ... }

* 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.

Re: Speed of Rust vs. C

#399

Post by gridspy »

pjmlp wrote: post #315
c-cube wrote: post #292

Earlier quoted context omitted.

We get that you don't like rust. But it seems like a lot of people currently using C or C++ while like to use rust at work, and might disagree about the benefits of the language and tooling. I personally know a few friends in distinct domains who work on established C++ codebases and are in this situation. There are also a lot of people who do not use C or C++, but use a bit of rust because it's so much easier to wri…

Quite on the contrary, Rust is the ideal language to replace C and C++ where automaric memory option is a no go, like MISRA-C, kernel and device drivers. Liking a programing language doesn't make me blind to what use cases it actually makes sense to use it, I don't see nails everywhere.

I agree.

I think you'll find that most rational advocates for any language agree that their favorite language is only strong in its subdomain.

Any compiled language is more painful than a quick scripting one for quick projects where the project complexity is low and the language overhead doesn't matter.

Rust is substantially more painful to get compiling (due to the borrow checker) and harder to debug (due to tool maturity) than C# or C++. It's much harder to use than Python. Every language has its place.

But when you are investing the time to make an efficient, high performance program... or you have limited requirements like you said -- Rust becomes a great choice.

Every langauge has its place. I'm just dreadfully excited that we have a new choice now to trade a bit more time interacting with compiler errors for high performance and stability -- when that makes sense.

Re: Speed of Rust vs. C

#400

Post by gridspy »

Animats wrote: post #390
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?

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.

Post reply on HN