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

241–250 of 546 posts

Re: Speed of Rust vs. C

#241

Post by [deleted] »

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.

[deleted]

Re: Speed of Rust vs. C

#242

Post by nyc_pizzadev »

benreesman wrote: post #52

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.

Agreed, came here to say the same thing. Would be interesting to see how they stack up against each other. Both are highly evolved modern languages that make pretty much the same claims.

Re: Speed of Rust vs. C

#243

Post by zesterer »

Tuna-Fish wrote: post #156
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 brillia…

> As a minimum to make the properly usable, we need a way of passing one object with multiple different traits.

Supertraits?

Re: Speed of Rust vs. C

#244

Post by brink »

efficax wrote: post #221
brink wrote: post #166

Earlier quoted context omitted.

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)

Ah yes, sorry. I remember it in my head with "async", but you're right. :)

Re: Speed of Rust vs. C

#245

Post by burntsushi »

amelius wrote: post #240
burntsushi wrote: post #218

Earlier quoted context omitted.

No you don't. I've written multiple programs that load things instantly off the file system via memory maps. See the fst crate[1], for example, which is designed to work with memory maps. imdb-rename[2] is a program I wrote that builds a simple IR index on your file system that can then instantly search it by virtue of memory maps. Rust "works badly with memory mapped files" doesn't mean, "Rust can't use memory mappe…

I didn't read your code but one problem I suspect you ran into is that you had to re-invent your container data structures to make them work in a mmapped context.

No, I didn't. An fst is a compressed data structure, which means you use it in its compressed form without decompressing it first. If you ported the fst crate to C, it would use the same technique.

And in C, you have to design your data structures to be mmap friendly anyway. Same deal in Rust.

But this is moving the goal posts. This thread started with "you can't do this." But you can. And I have. Multiple times. And I showed you how.

Re: Speed of Rust vs. C

#246

Post by steveklabnik »

bakatubas wrote: post #239
bluejekyll wrote: post #198

Earlier quoted context omitted.

It doesn’t say it “works badly” it says the borrow checker can’t protect against external modifications to the file while memory-mapped, which has a host of issues in C as well. You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.

I don’t get this obsession with “dangerous.” Honestly, what does that even mean? I think a better word is “error-prone.” Danger is more like, “oh my god a crocodile!”

> Honestly, what does that even mean?

It has a very specific meaning in Rust: the user can cause memory unsafety if they make a mistake.

> I think a better word is “error-prone.”

The issue with the connotation there is that it's not about the rate of problems, it's about them going from "impossible" to "possible."

Re: Speed of Rust vs. C

#247

Post by burntsushi »

tsegratis wrote: post #236
ben0x539 wrote: post #184

Earlier quoted context omitted.

ripgrep? :)

ripgrep is based on re2, a c library I would guess it contains more c than rust code... But what I love about this article is its lack of hype. It makes clear arguments both ways and all of them I can get behind Hype doesn't help Edit: To all my downvoters; I anticipated you :) With love and best wishes

No it's not. Its regex library is written in Rust, but was inspired by RE2. It shares no code with RE2. (And RE2 is a C++ library, not C.)

Off the top of my head, the only C code in ripgrep is optional integration with PCRE2. In addition to whatever libc is being used on POSIX platforms. Everything else is pure Rust.

Re: Speed of Rust vs. C

#248

Post by amelius »

burntsushi wrote: post #245
amelius wrote: post #240

Earlier quoted context omitted.

I didn't read your code but one problem I suspect you ran into is that you had to re-invent your container data structures to make them work in a mmapped context.

No, I didn't. An fst is a compressed data structure, which means you use it in its compressed form without decompressing it first. If you ported the fst crate to C, it would use the same technique. And in C, you have to design your data structures to be mmap friendly anyway. Same deal in Rust. But this is moving the goal posts. This thread started with "you can't do this." But you can. And I have. Multiple times. And…

> which means you use it in its compressed form without decompressing it first.

So your code operates directly on a block of raw bytes? I can see how that can work with mmap without much problems.

My argument was more about structured data (created using the type system), which is a level higher than raw bytes.

Re: Speed of Rust vs. C

#249

Post by fractionalhare »

amelius wrote: post #240
burntsushi wrote: post #218

Earlier quoted context omitted.

No you don't. I've written multiple programs that load things instantly off the file system via memory maps. See the fst crate[1], for example, which is designed to work with memory maps. imdb-rename[2] is a program I wrote that builds a simple IR index on your file system that can then instantly search it by virtue of memory maps. Rust "works badly with memory mapped files" doesn't mean, "Rust can't use memory mappe…

I didn't read your code but one problem I suspect you ran into is that you had to re-invent your container data structures to make them work in a mmapped context.

It's very tedious to debate with someone who explicitly makes assumptions about something (like code) without having read it, and puts the burden of refuting those assumptions on you...

Re: Speed of Rust vs. C

#250

Post by gameswithgo »

jandrewrogers wrote: post #3

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. Given this, it is not clear to me that Rust actually buys much when it comes to parallel programming for the purposes of performance. Is there another reason to focus on parallelism aside from performance? This reminds me of when I use to…

>As an observation, performance optimized code is almost always effectively single-threaded these days

I do not accept this premise. Things are increasingly multithreaded.

Post reply on HN