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

181–190 of 251 posts

Re: Why is Rust slightly slower than C?

#181

Post by glangdale »

graycat wrote: post #159
monocasa wrote: post #82

Earlier quoted context omitted.

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…

I get it now: My view of HN just went down to the sewer: We're into the old, bitter, go out back and fight it out, religious computer language wars. And there C is one of the grand sacred subjects: C is the greatest. The greatest, best ever. The greatest, fastest of all time, never to be improved on. Pure genius. Pure gold. And C programmers are like people who climb Mount Everest barefoot with no tools and the only…

You appear to be making your points in a way in which no developments from the part 10-20 or so years are intruding. Can you point to a extant PL/I compiler that produces good code on modern architectures? How sure are you that the issues that separated C, Fortran and PL/I historically are even remotely relevant now?

I would imagine inlined functions (and for the brave, interprocedural analysis) renders many of your points moot. Fortran still has an edge on numerics as I understand it, but I don't think it's all that decisive.

The other reason that baking functionality into the language is problematic is that you wind up having a few things that go fast, while you neglect to build facilities that optimize other people's data structures. So you get the world's fastest dense array (say) but your sparse array is resolutely mediocre. Instead of a language packed with special-cases, I would much rather a minimal language with good analyses (many of which can be supported by language design; I think Rust has a good future here to support good analyses by how carefully it tracks lifetimes and how it doesn't fling aliases around with the abandon of C).

Re: Why is Rust slightly slower than C?

#182

Post by fluffything »

tom_mellior wrote: post #15

Looking at performance counter data is good, but I would have liked to see a real validation of the hypothesis that bounds checking is to blame for the extra branches and instructions. That is, modify the Rust compiler to not emit bounds checks (or maybe there is even a flag for this?) and look at performance and counters. I would imagine that this would bring the data for Rust to pretty much the same as C. But other…

They can just profile to find out which functions in their program are consuming the most CPU. Finding if these functions do have any bound checks, and if so, writing the single line of code required to tell the compiler "trust me, it is impossible for this index to ever be out-of-bounds, a bound check is not necessary".

If they are right, and bound checks are the issue, doing this should recover the performance difference.

Re: Why is Rust slightly slower than C?

#183

Post by fluffything »

unrealhoang wrote: post #180
fluffything wrote: post #179

Earlier quoted context omitted.

> C code would also have to do. Well that's the point: C does not have to do it. RAII protects you from, e.g., leaking memory. But C can just leak memory, and there isn't really anything substantially wrong with that (you can't get UB from leaking memory). Checking error values, releasing all resources, doing bound checks, and all the other things that both C++ and Rust do by default are more expensive than doing not…

You can write zero ops destructor as well. So yes, RAII is zero-cost abstraction.

I literally said so.

Re: Why is Rust slightly slower than C?

#184

Post by fluffything »

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…

> 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.

It is.

> Rust is strongly-typed, is it not?

Yes.

> Does it do run-time type-checking?

No.

> Exception handling in particular requires a non-negligible amount of run-time overhead and may account for a significant proportion of the difference between the performance of Rust and C.

Rust does not have exceptions, it has panics (fatal errors). It is correct for a panic to abort the program. You can provide an user-defined panic run-time that does whatever you want (unwinding, aborting, looping forever, `ud2`, etc.).

Re: Why is Rust slightly slower than C?

#185

Post by fnord123 »

hermitdev wrote: post #113
harry8 wrote: post #112

Earlier quoted context omitted.

> In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. This has not been my experience and I'm greatly relieved that I haven't been subjected to such a hostile and destructive working environment in finance as yourself. The correct response is always: "Show the benchmark numbers and make your case that the trade off is worth it." Then there is discussion on how c…

Having spent 15 years in finance, I've never seen C used for perfomance critical code. It's always been C++. Some shops use Java or C# with GC effectively disabled, but those are rare. If you can preallocate all of the memory you need, this may be fine, but not all trading systems have that luxury.

I've also worked in finance and nobody I've known reaches for C++ for performance over C - only convenience/comfort. For performance, one examines the compiled output, analyze the instructions, try to prevent pipeline stalls, etc. And if the compiler is generating dissastisfactory code, use assembly for those parts.

Re: Why is Rust slightly slower than C?

#186

Post by masklinn »

emmericp wrote: post #171
CodesInChaos wrote: post #166

Currently Rust doesn't make proper use of its aliasing rules because of bugs in LLVM. This can reduce performance of code by forcing unnecessary memory accesses. As an experiment you could try the `-Zmutable-noalias=yes` option, which should enable these optimizations (but exposes you to those bugs). See [masklynn's comment]( https://news.ycombinator.com/item?id=20948779 ). In general Rust suffers a bit because LLVM…

Yeah, enabling noalias optimizations is on our todo-list. I think that’s one of the most interesting performance features of Rust. It could be the thing that makes Rust faster than C, ultimately. Too bad it‘s so broken in LLVM :(

> Too bad it‘s so broken in LLVM :(

TBF it wasn't just LLVM: in https://github.com/rust-lang/rust/issues/54878 "nikic" and "comex" provided C test cases which failed in both clang[0] and gcc[1]. Though GCC has since fixed the issue while it remains open on LLVM.

[0] https://bugs.llvm.org/show_bug.cgi?id=39282

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609

Re: Why is Rust slightly slower than C?

#187

Post by tom_mellior »

bjourne wrote: post #178
Zarel wrote: post #58

Earlier quoted context omitted.

Their initial explanation is bounds checking specifically. While most abstractions are zero-cost, bounds checking isn't. I do wish there were a way to track expectations about integer ranges in a type system, but there currently aren't.

There are! It is done in compiled Lisp and Scheme runtimes such as SBCL to remove provably redundant bounds checking. For example, in (when ( = 0 x) (...))) SBCL will infer that if x is an integer, it must have one of the values 0, 1, 2 or 3. The knowledge is useful because if x is used as the index of an array containing 3 or more items the bounds checking can be elided.

Compilers do that, yes. But I think the grandparent wanted to express this at the source level, as an annotation to a type.

Re: Why is Rust slightly slower than C?

#188

Post by Quekid5 »

harry8 wrote: post #112
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…

> In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. This has not been my experience and I'm greatly relieved that I haven't been subjected to such a hostile and destructive working environment in finance as yourself. The correct response is always: "Show the benchmark numbers and make your case that the trade off is worth it." Then there is discussion on how c…

> The correct response is always: "Show the benchmark numbers and make your case that the trade off is worth it." Then there is discussion on how compelling a case has been made.

Where do you work that allows you to implement everything twice, once in C and once in C++, for a proper comparison to be made?

(I realize that's not quite what you said, but if we're going with 'benchmark', then presumably those places have already done the benchmarks and decided that C++ is generally superior performance-wise.)

Re: Why is Rust slightly slower than C?

#189

Post by fnord123 »

harry8 wrote: post #145
ncmncm wrote: post #122

Earlier quoted context omitted.

I have not encountered any hostility. But if you don't know how to get better performance from C++ than you can get from C and lots of extra work, you probably will not be hired, most places. It's not about hostility, it's about competence. Some places just demand competence more than others. The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would…

This conversation is now bordering on unhelpful. C has uses, some of them are compelling. Every finance shop I've worked in uses the linux kernel and drivers extensively. These are (mostly? all?) written in C. As is git. Nobody laughs. C++ has uses. Some of them are compelling. For a given case where these uses dominate nobody laughs. Claiming C is as obsolete as CRT monitors or 10baseT without any supporting evidenc…

Maybe in ncmncm's circle they laugh at C developers, but trying to extrapolate that across the finance industry is not credible.

Performance at the sharp end comes from preallocating memory, reducing syscalls, removing PIC (drop the GOT), static linking (enable LTO), using LTO, using simd where possible, hand rolling important functions in assembly, cpusets, reducing network hops, attempting to get the program to fit in L1 cache, putting the code into the switch, moving to fpga, moving to asic.

There's loads more optimizations but almost none of them have anything to do with C++ over C.

Re: Why is Rust slightly slower than C?

#190

Post by ncmncm »

fluffything wrote: post #179
jeremyjh wrote: post #79

Earlier quoted context omitted.

Is there really a performance cost from RAII? Presumably whatever a destructor has to do to release resources, C code would also have to do.

> C code would also have to do. Well that's the point: C does not have to do it. RAII protects you from, e.g., leaking memory. But C can just leak memory, and there isn't really anything substantially wrong with that (you can't get UB from leaking memory). Checking error values, releasing all resources, doing bound checks, and all the other things that both C++ and Rust do by default are more expensive than doing not…

If your constructor news memory, then if you don't write a destructor, then nothing deletes the memory. You don't need to "opt out". It is hard to guess where you get this idea.

It is bad form to code memory leaks, so normally one doesn't. Instead, one normally allocates in such a way that the automatically-generated destructor frees the memory.

But neither case requires writing more code to "opt in" or to "opt out". It is the same in Rust.

Post reply on HN