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

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

231–240 of 402 posts

Re: Is Rust faster than C?

#231

Post by pornel »

arghwhat wrote: post #112
pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`. Despite benefits, I don't actually think the memory safety really plays a role in the usage ra…

Go is weirdly careless about thread-safety of its built-in data structures, but GC, channels, and the race detector seem to be enough?

Re: Is Rust faster than C?

#232

Post by adgjlsfhk1 »

jarjoura wrote: post #200
foldr wrote: post #99

Earlier quoted context omitted.

>in Rust and C++, the standard library sorting functions are templated on the comparison function. This means it's much easier for the compiler to specialize the sorting function, inline the comparisons and optimize around it. I think this is something of a myth. Typically, a C compiler can't inline the comparison function passed to qsort because libc is dynamically linked (so the code for qsort isn't available). But…

Wouldn't C++ and Rust eventually call down into those same libc functions? I guess for your example, qsort() it is optional, and you can chose another implementation of that. Though I tend to find that both standard libraries tend to just delegate those lowest level calls to the posix API.

Many of the libc functions are bad apis with traditionally bad implementations.

Re: Is Rust faster than C?

#233

Post by adgjlsfhk1 »

gf000 wrote: post #154
jillesvangurp wrote: post #58

Earlier quoted context omitted.

It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more co…

> It's compilers and compiler optimizations that make code run fast Well, then in many cases we are talking about LLVM vs LLVM. > Ultimately, producing fast/optimal code in C kind of is the whole point of C Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressi…

Compilers are only as good as the semantics you give them. C and C++ both have some pretty bad semantics in many places that heavily encourage inefficient coding patterns.

Re: Is Rust faster than C?

#234

Post by marcosdumay »

steveklabnik wrote: post #220
Maxatar wrote: post #218

Earlier quoted context omitted.

If you need to store the value then you have no choice but to take in a dyn trait.

Depending on exactly what you mean, this isn't correct. This syntax is the same as , and you can store that T in any other generic struct that's parametrized by BarTrait, for example.

> you can store that T in any other generic struct that's parametrized by BarTrait, for example

Not really. You can store it on any struct that specializes to the same type of the value you received. If you get a pre-built struct from somewhere and try to store it there, your code won't compile.

Re: Is Rust faster than C?

#235

Post by marcosdumay »

OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

> On the other hand, signed integer overflow being UB would count for C/C++

Rust defaults to the platform treatment of overflows. So it should only make any difference if the compiler is using it to optimize your code, what will most likely lead to unintended behavior.

Re: Is Rust faster than C?

#236

Post by pornel »

jasonjmcghee wrote: post #158
pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

> Rust programmers may as well sprinkle threads all over the place regardless whether that's a 16x improvement or 1.5x improvement What about energy use and contention?

Usually it's a benefit for energy usage anyway.

CPUs are most energy efficient sitting idle doing nothing, so finishing work sooner in wall-clock time usually helps despite overheads.

Energy usage is most affected by high clock frequencies, and CPUs will boost clocks for single-threaded code.

Threads waiting on cache misses let CPU use hyperthreading, which is actually energy efficient (you get context switching in hardware).

You can waste energy in pathological cases if you overuse spinlocks or spawn so many threads that bookkeeping takes more work than what the threads do, but helper libraries for multithreading all have thread pools, queues, and dynamic work splitting to avoid extreme cases.

Most of the time low speed up is merely Amdahl's law – even if you can distribute work across threads, there's not enough work to do.

Re: Is Rust faster than C?

#237

Post by astrange »

marcosdumay wrote: post #235
OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

> On the other hand, signed integer overflow being UB would count for C/C++ Rust defaults to the platform treatment of overflows. So it should only make any difference if the compiler is using it to optimize your code, what will most likely lead to unintended behavior.

Writing a function with UB for overflows doesn't cause unintended behavior if you're doing it to signal there aren't any overflows. And it's very important because it's needed to do basically any loop rewriting.

On the other hand, writing a function that recovers from overflows in an incorrect/useless way still isn't helpful if there are overflows.

Re: Is Rust faster than C?

#238

Post by vitaut »

It's easier to write faster code in a language with compile-time facilities such as C++ or Rust than in C. For example, doing this sort of platform-specific optimization in C is a nightmare https://github.com/vitaut/zmij/blob/91f07497a3f6e2fb3a9f999a... (likely impossible without an external pass to generate multiple lookup tables).

Re: Is Rust faster than C?

#239

Post by majormajor »

arghwhat wrote: post #112
pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`. Despite benefits, I don't actually think the memory safety really plays a role in the usage ra…

> (As a personal anecdote, I've probably run into more concurrency-related heisenbugs in Go than I ever did in C, with C heisenbugs more commonly being memory mismanagement in single-threaded code with complex object lifetimes/ownership structures...)

Is that beyond just "concurrency is tricky and a language that makes it easier to add concurrency will make it easier to add sneaky bugs"? I've definitely run into that, but have never written concurrent C to compare the ease of heisenbug-writing.

Re: Is Rust faster than C?

#240

Post by vitaut »

vitaut wrote: post #238

It's easier to write faster code in a language with compile-time facilities such as C++ or Rust than in C. For example, doing this sort of platform-specific optimization in C is a nightmare https://github.com/vitaut/zmij/blob/91f07497a3f6e2fb3a9f999a... (likely impossible without an external pass to generate multiple lookup tables).

Other examples are CTRE (https://github.com/hanickadot/compile-time-regular-expressio...) and format string compilation (https://fmt.dev/12.0/api/#compile-api). The closest C counterpart is re2c which also requires external tooling.
Post reply on HN