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

Why is Rust slightly slower than C?

github.com

Post reply on HN
Print view View original

81–90 of 251 posts

Re: Why is Rust slightly slower than C?

#81

Post by monocasa »

freejulian85 wrote: post #77
ncmncm wrote: post #75

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides. Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume an…

I didn’t realize it was possible to be so wrong.

I love C, and have written tons of C++:

What the parent is saying is essentially right. C++'s compile time polymorphism and lamdas can allow faster than C given the right subset of language chosen. For instance std::sort regularly outperforms qsort(3).

Re: Why is Rust slightly slower than C?

#82

Post by monocasa »

graycat wrote: post #68
glangdale wrote: post #60

Earlier quoted context omitted.

How current is this impression? There continue to be first-rate Fortran compilers that probably win on numerics for exactly the reasons you state, but I would be surprised that PL/I has a toolchain that's kept up with modern architecture. String handling, on most modern toolchains, mostly goes to inline functions or builtins that the compiler has been (rather pragmatically, if a big disgustingly) made aware of. It's…

My experience is old, but my summary point remains: Language defined and compiler supported functionality usually is faster than libraries of external functions. The relevance here: C isn't the fastest thing around and can be beaten. Maybe similarly for Rust. For PL/I and strings, for the IBM versions on S/360 and S/370, the compiler might have used some of the hardware instructions for string handling. I'd be surpri…

The compiler (off the top of my head this applies to GCC, clang, and MSVC, dont know about ICC) generally understands the C string functions at a fundamental level and will emit optimized code instead of a function call that will use hardware instructions and might know the size of the buffer at compile time. For instance on GCC you have to specify -fno-builtin to say "you don't know what you think you know about c library, actually emit those function calls instead of trying to optimize the idea of those calls."

Re: Why is Rust slightly slower than C?

#83

Post by andrepd »

Newbie to rust, but surely there must be a way to disable bounds checking in rust, right?? Like C++ std::vector has operator() (bounds checked) and operator[] (pointer dereference, unsafe), or other languages have get/unsafe_get (ocaml), surely rust has a way to disable bounds checking as well (or disables it for optimised builds)

Re: Why is Rust slightly slower than C?

#84

Post by graycat »

monocasa wrote: post #82
graycat wrote: post #68

Earlier quoted context omitted.

My experience is old, but my summary point remains: Language defined and compiler supported functionality usually is faster than libraries of external functions. The relevance here: C isn't the fastest thing around and can be beaten. Maybe similarly for Rust. For PL/I and strings, for the IBM versions on S/360 and S/370, the compiler might have used some of the hardware instructions for string handling. I'd be surpri…

The compiler (off the top of my head this applies to GCC, clang, and MSVC, dont know about ICC) generally understands the C string functions at a fundamental level and will emit optimized code instead of a function call that will use hardware instructions and might know the size of the buffer at compile time. For instance on GCC you have to specify -fno-builtin to say "you don't know what you think you know about c l…

Soooo, those C compilers cheat on the language as defined in K&R etc.!!! WOW!!

With that cheating, C gets to catch up with, say, what PL/I was doing with string manipulations in, say, 1969!!!

So, this is the 50th anniversary!! C string handling is right up to date as of 50 years ago!!!

There is still the issue of a C programmer having to calculate array indices that Fortran and PL/I can do back, way back there, 50+ years ago!!!! What was it, Fortran 66 or some such???

Re: Why is Rust slightly slower than C?

#85

Post by m0zg »

fluffything wrote: post #24

Because C is slower than C. That is, they are compiling C with GCC, but Rust uses LLVM as a backend. Compiling their C code with clang reveals that it is also slightly slower than the C code compiled by GCC, but not faster than Rust. The actual conclusion here is that the GCC toolchain is slightly faster than the LLVM toolchain for this particular use case, but that isn't really news - it happens all the time. If one…

That actually depends. I'm some cases I've seen Clang pull off superhuman feats of vectorization, especially on ARM64. You paste code in Godbolt Compiler Explorer and GCC produces fairly readable assembly, and Clang uses every trick in the book to vectorize. In those cases Clang can be substantially faster. But code needs to be written with vectorization in mind for that to happen (short loops of known size, and a few other restrictions like that). Most of the time it's a few percent behind GCC.

Re: Why is Rust slightly slower than C?

#86

Post by mlindner »

maxk42 wrote: post #44

The two biggest factors involved are (1) Runtime. Even though C has "no" runtime, there is some runtime overhead: Variable allocation / de-allocation and alignment. Function invocation / call stack setup. Et cetera. I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. (Rust is strongly-typed, is it not? Does it do run-time type-checking?) Exception handli…

Please don't answer the question if you don't know enough to answer it. Rust doesn't have exception handling. Rust doesn't have a runtime.

Re: Why is Rust slightly slower than C?

#87

Post by ShorsHammer »

The_rationalist wrote: post #12
holy_city wrote: post #4

Earlier quoted context omitted.

>I wonder if some of the bounds checks could be eliminated by using iterators instead of loops It can and often is. Don't use [] to index into data if you can afford not to. Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++, but that depends largely on what you're doing.

Source?

Anyone asking for "source" should be able to prove that they've not searched first. Because it's right there. As noted in the other comment it's in the literal documentation for rust.

Low effort commenting is usually shunned here, yet the ever prevalent "source?" seems to get a free pass all the time.

Really people should say: "source? Because I tried https://www.google.com/search?q=rustc+is+also+much+better+at... and found no sources whatsoever about this issue that has been discussed to death on dozens of forums yet I was somehow incapable of finding a single thing on the matter"

Why should someone spend time typing out easily searchable content for you? In fact, why should forums with a focus on high quality content even answer you?

Anyone who asks for sources should be required to do the same on demand. Whenever, wherever.

Re: Why is Rust slightly slower than C?

#88

Post by steveklabnik »

andrepd wrote: post #83

Newbie to rust, but surely there must be a way to disable bounds checking in rust, right?? Like C++ std::vector has operator() (bounds checked) and operator[] (pointer dereference, unsafe), or other languages have get/unsafe_get (ocaml), surely rust has a way to disable bounds checking as well (or disables it for optimised builds)

Yes, you use .get_unchecked instead of [].

Re: Why is Rust slightly slower than C?

#89

Post by lmkg »

andrepd wrote: post #83

Newbie to rust, but surely there must be a way to disable bounds checking in rust, right?? Like C++ std::vector has operator() (bounds checked) and operator[] (pointer dereference, unsafe), or other languages have get/unsafe_get (ocaml), surely rust has a way to disable bounds checking as well (or disables it for optimised builds)

As a design choice, Rust prefers not to change the semantics of methods depending on the context, but instead to expose different methods. Arrays offer get_unchecked and get_unchecked_mut methods, which can only be called inside unsafe blocks.

The one exception I'm aware of is that integer overflow panics in debug builds, and silently wraps in release builds. But in most other cases, there will be different separate methods with different semantics, requiring an unsafe context as appropriate.

Re: Why is Rust slightly slower than C?

#90

Post by jamessteel »

physicsyogi wrote: post #32

There are a few numerical computing benchmarks for which Rust is sometimes faster than C: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

For what it worth, it is more accurate to bench on your own machine, you may find a different or interesting outcomes such as error and slower in Rust.
Post reply on HN