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

311–320 of 546 posts

Re: Speed of Rust vs. C

#311

Post by howinteresting »

cygx wrote: post #214
TazeTSchnitzel wrote: post #195

Earlier quoted context omitted.

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…

That's what restrict is for: void foobar(struct foo *restrict f) { ... }

But restrict is very hard to reason about correctly, and the consequences for making a mistake are potentially catastrophic.

There's a very real difference between what's possible in theory and what humans do in practice. I wish Hacker News people engaged more with the practice.

Re: Speed of Rust vs. C

#312

Post by steveklabnik »

up2isomorphism wrote: post #299
burntsushi wrote: post #297

Earlier quoted context omitted.

That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn…

There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish. This is as same as some one tell you that you will never loose any money by investing a certain asset.

How well do you know Rust, and how it works, and what it guarantees?

Like, do you have a specific objection to the way Rust accomplishes this?

Re: Speed of Rust vs. C

#313

Post by masklinn »

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.

> Accessing […] database content from multiple threads without proper locking, or transactions, in place will compile just fine.

All the rust db interfaces I've seen so far forbid unlocked sharing of connections, statically (the connections are !Sync, in Rust speak).

Re: Speed of Rust vs. C

#314

Post by howinteresting »

skohan wrote: post #259
jdright wrote: post #185

Earlier quoted context omitted.

There are crates for hot reloading in Rust, and they use dynamic linking.

Do you have to stick to a C-FFI like interface, or can they handle rust-native features like closures and traits?

Some stick to C FFI, some enforce that the Rust compiler version is the same which makes ABI issues irrelevant.

Re: Speed of Rust vs. C

#315

Post by pjmlp »

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

Earlier quoted context omitted.

Not until it reaches the same level as Visual Studio, Android Studio, QtCreator, XCode, CUDA and SYSCL tooling for graphical applications and GPGPU. For anything else managed languages are a much more productive option, other than writing kernel and drivers.

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.

Re: Speed of Rust vs. C

#316

Post by pjmlp »

masklinn wrote: post #313
pjmlp wrote: post #125

Earlier quoted context omitted.

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

> Accessing […] database content from multiple threads without proper locking, or transactions, in place will compile just fine. All the rust db interfaces I've seen so far forbid unlocked sharing of connections, statically (the connections are !Sync, in Rust speak).

They don't enforce the use of transactions, nor exclusive access to database tables.

Re: Speed of Rust vs. C

#317

Post by pjmlp »

hderms wrote: post #200
ben0x539 wrote: post #172

Earlier quoted context omitted.

The fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).

Yeah it would be a grave misinterpretation of "fearless concurrency" to think Rust somehow validates that access to some shared resource with it's own semantics is also safe. I'm not educated on the subject but that problem seems pretty intractable for a language to solve in a general sense.

Indeed, yet that is not how many Rust advocacy blog posts sell it.

Re: Speed of Rust vs. C

#319

Post by burntsushi »

tsegratis wrote: post #309
burntsushi wrote: post #287

Earlier quoted context omitted.

To be clear, ripgrep has no runtime dependency on any LLVM or C++ library. rustc does.

The interesting thing here is that rust has good threading and fantastic crates I played with making a regex library in rust. Which, as per RE2 design involves constructing graphs and glueing them together as the regex is traversed This requires a cycle catching gc, or, just a preallocated arena... It was my first foray into rust and felt I would need to be hitting into unsafe, which I wasn't ready for. Array indexin…

You're overcomplicating it. When it comes to finite state machines at least, it's very easy to use an ID index instead of the raw pointer itself. That's exactly what the regex crate does.

For reference, I am also the author of the regex crate. The only unsafe it uses specific to finite automata is to do explicit elimination of bounds checks in the core hybrid NFA/DFA loop.

Re: Speed of Rust vs. C

#320

Post by howinteresting »

up2isomorphism wrote: post #299
burntsushi wrote: post #297

Earlier quoted context omitted.

That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn…

There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish. This is as same as some one tell you that you will never loose any money by investing a certain asset.

Rust is a constructive proof that your assertion is simply false. It comes at the cost of some complexity—every Rust type carries thread-safety information with it—but the benefit is that writing correct parallel Rust code becomes very easy.

What you cannot easily do in Rust is dynamically switch thread safety on or off.

Post reply on HN