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

201–210 of 402 posts

Re: Is Rust faster than C?

#201

Post by sfink »

steveklabnik wrote: post #55
torben-friis wrote: post #48

Earlier quoted context omitted.

Doesn’t rust have incremental builds to speed up debug compilation? How slow are we talking here?

Rust does have incremental rebuilds, yes. Folks have worked tirelessly to improve the speed of the Rust compiler, and it's gotten significantly faster over time. However, there are also language-level reasons why it can take longer to compile than other languages, though the initial guess of "because of the safety checks" is not one of them, those are quite fast. > How slow are we talking here? It really depends on a…

My initial guess would be "because of the zero-cost abstractions", since I read "zero-cost" as "zero runtime cost" which implies shifting cost from runtime to compile time—as would happen with eg generics or any sort of global properties.

(Uh oh, there's an em-dash, I must be an AI. I don't think I am, but that's what an AI would think.)

Re: Is Rust faster than C?

#202

Post by steveklabnik »

sfink wrote: post #201
steveklabnik wrote: post #55

Earlier quoted context omitted.

Rust does have incremental rebuilds, yes. Folks have worked tirelessly to improve the speed of the Rust compiler, and it's gotten significantly faster over time. However, there are also language-level reasons why it can take longer to compile than other languages, though the initial guess of "because of the safety checks" is not one of them, those are quite fast. > How slow are we talking here? It really depends on a…

My initial guess would be "because of the zero-cost abstractions", since I read "zero-cost" as "zero runtime cost" which implies shifting cost from runtime to compile time—as would happen with eg generics or any sort of global properties. (Uh oh, there's an em-dash, I must be an AI. I don't think I am, but that's what an AI would think.)

I used em dashes before AI, and won't stop now :)

That's sort of part of it, but it's also specific language design choices that if they were decided differently, might make things faster.

Re: Is Rust faster than C?

#203

Post by steveklabnik »

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.

Rust doesn't call into libc for sort, it has its own implementation in the standard library.

Re: Is Rust faster than C?

#204

Post by randomNumber7 »

OptionOfT wrote: post #88
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…

Apart from multi threading, there is more information in the Rust type system. Would that would allow more optimizations?

In C there is the "restrict" keyword to tell the compiler that there is no other pointer to the values accessed over a certain pointer.

If you do not use that the generated code can be quite suboptimal in certain cases.

Re: Is Rust faster than C?

#205

Post by gf000 »

groundzeros2015 wrote: post #195
gf000 wrote: post #136

Earlier quoted context omitted.

Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?

Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haph…

> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.

This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.

Re: Is Rust faster than C?

#206

Post by OptionOfT »

tcfhgj wrote: post #122
OptionOfT wrote: post #88

Earlier quoted context omitted.

Apart from multi threading, there is more information in the Rust type system. Would that would allow more optimizations?

what about generics (equivalent to templates in C++), which allow compile time optimizations all the way down which may not possible if the implementation is hidden behind a void*?

Unless you use `dyn`, all code is monomorphized, and that code on its own will get optimized.

This does come with code-bloat. So the Rust std sometimes exposes a generic function (which gets monomorphized), but internally passes it off to a non-generic function.

This to avoid that the underlying code gets monomorphized.

https://github.com/rust-lang/rust/blob/8c52f735abd1af9a73941...

Re: Is Rust faster than C?

#207

Post by groundzeros2015 »

gf000 wrote: post #205
groundzeros2015 wrote: post #195

Earlier quoted context omitted.

Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haph…

> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.

And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style.

What’s better? Rust? Haskell? Swift?

It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.

Re: Is Rust faster than C?

#209

Post by sfink »

kibwen wrote: post #140
bluGill wrote: post #46

Earlier quoted context omitted.

Is Javascript significantly slower? It is extremely common in the real world and so a lot of effort has gone into optimizing it - v8 is very good. Yes C and Rust enable more optimizations: they will be slightly faster, but javascript has had a lot of effort put into making it run fast.

Yes. V8 (and other Javascript JIT engines) are very good, with a lot of effort put into them by talented engineers. But there's a floor on performance imposed by the language's own semantics. Of course, if your program is I/O bound rather than CPU bound (especially at network-scale latencies), this may never be noticeable. But a Javascript program will use significantly more CPU, significantly more memory, and both C…

It's complicated, though mostly that complication doesn't change the overall conclusion.

Much of the language's semantics can be boiled away before JIT compilation, because that flexibility isn't in use at that time, which can be proven by a quick check before entering the hot code. (Or in the extreme, the JIT code doesn't check it at all, and the runtime invalidates that code lazily when an operation is performed that violates those preconditions.) Which thwarts people who do simple-minded comparisons of "what language is fastest at `for (i = 0; i Still: you have to spend time JIT compiling. You have to do some dynamic checks in all but the innermost hot code. You have to materialize data in memory, even if just as a fallback, and you have to garbage collect periodically.

So I agree with your conclusion, except for perhaps un-nuanced use of the term "performance floor" -- there's really no elevated JS floor, at least not a global one; simple JS can generate the same or nearly the same machine code as equivalent C/C++/Rust, will use no more memory, and will never GC. But that floor only applies to a small subset of code (which can be the bulk of the runtime!), and the higher floor does kick in for everything else. So generally speaking, JS can only "be as fast" as non-managed languages for simple programs.

(I'll ignore the situations where the JIT can depend on stricter constraints at runtime than AOT-compiled languages, because I've never seen a real-world situation where it helps enough to counterbalance everything else.)

Re: Is Rust faster than C?

#210

Post by sfink »

farnulfo wrote: post #103

Is there a common pattern for "Is language X faster than language Y" ? Like what is your definition of faster : faster to developer, to start, to execute, to handle different workload with the same binaries (like JIT).

Yes. "Is language X faster than language Y?" means "Is language X better than language Y?", which means "Do you like language X more than you like language Y?", which means "Do you have more experience with language X than language Y?" (well, good experiences, I guess).

So "Is language X faster than language Y?" is totally answerable, but the answer depends on the answerer.

Post reply on HN