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

111–120 of 251 posts

Re: Why is Rust slightly slower than C?

#111

Post by donio »

emmericp wrote: post #33
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…

Thank you for your thoughtful comment, recommended reading: https://news.ycombinator.com/newsguidelines.html (edit: thanks for editing your comment, we can have a civil discussion here) To answer your question: Yes, that particular benchmark was done with GCC and yes, it would have been better to use clang/LLVM for a more fair comparison. We of course also compared gcc with clang/LLVM and found that clang was 0.8% sl…

It could be argued that using the best available implementation for each is the more fair comparison.

Re: Why is Rust slightly slower than C?

#112

Post by harry8 »

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 compelling a case has been made.

Re: Why is Rust slightly slower than C?

#113

Post by hermitdev »

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…

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.

Re: Why is Rust slightly slower than C?

#114

Post by ynx »

fluffything wrote: post #34
emmericp wrote: post #33

Earlier quoted context omitted.

Thank you for your thoughtful comment, recommended reading: https://news.ycombinator.com/newsguidelines.html (edit: thanks for editing your comment, we can have a civil discussion here) To answer your question: Yes, that particular benchmark was done with GCC and yes, it would have been better to use clang/LLVM for a more fair comparison. We of course also compared gcc with clang/LLVM and found that clang was 0.8% sl…

> We of course also compared gcc with clang/LLVM and found that clang was 0.8% slower, so it does not explain the difference entirely. I think it would be quite useful and interesting to figure out why there is still a small difference between clang and Rust. There might be some low hanging fruit in how Rust generates LLVM-IR that could be fixed.

doesn't it also use an older fork of LLVM rather than branching/rebasing off of master? That could account for losing out on optimizations.

Re: Why is Rust slightly slower than C?

#115

Post by bt848 »

codesushi42 wrote: post #76
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…

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++…

In what way can “STL” be considered a performance hit? It looks like you just threw out every C++-related word you know.

Re: Why is Rust slightly slower than C?

#116

Post by ncmncm »

comex wrote: post #101
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.

Indeed, RAII is a zero-cost abstraction compared to running the same destructors manually. On the other hand, C++ makes it really easy to write programs that copy and destroy things when it isn't necessary. For example, if a function takes a `std::string` as an argument (by value), any string you pass in will be copied into a new allocation, which will then have to be deallocated. That's fine if the function really n…

This is obsolete and faulty advice.

Given a modern compiler and library, a by-value string temporary can be passed down a chain of calls with no allocations beyond the first, and returned, likewise.

Passing a reference means the optimizer cannot optimize accesses, because it doesn't know what other pointers might be aliasing it. string_view has the same problem.

Quotes about Chromium and Firefox are likewise obsolete. Old code, old coding standards. Neither uses RAII, so they pay a 20-30% runtime penalty. With a modern library, short strings do no allocation. (IIRC Firefox uses 16-bit characters, so they get less.)

That said, if the runtime performance of code trafficking in string objects matters, you are Doing It Wrong.

Re: Why is Rust slightly slower than C?

#117

Post by jnordwick »

steveklabnik wrote: post #102
jnordwick wrote: post #97

Earlier quoted context omitted.

how do you not use bounds checking? (unsafe like get_unchecked doesn't count because then you can say that about almost every rust feature).

You're mis-understanding what "you don't pay for what you don't use" means. It means that a program that does not contain [] in it does not include code for []. There's no "mandatory runtime" code for []. It doesn't mean you can use [] in some special way and somehow get less code. And even if we were talking about your understanding, I don't see why get_unchecked would be disqualified. unsafe is a part of the langua…

I know, the meaning of "zero cost abstraction" is really "zero cost to not use the abstraction."

But that's like saying if you don't use rust you don't pay for it. Just because there is the unsafe escape hatch in the language, you don't get to label the language as zero cost abstraction. Because practically speaking there is a lot more runtime cost to rust than people will tell you.

Many langauges (almost anything without a runtime) meet that definition of zero cost abstraction then.

Re: Why is Rust slightly slower than C?

#118

Post by harry8 »

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'm also sorry if your exeprience has been similarly hostile. This is not a comment about which languages get used in which shops.

Whatever your technology choice you would expect to have to make a case, using evidence, and have that case properly listened to (or why did they hire you?). For performance critical technology you would expect that evidence to include benchmark numbers.

Any other approach to considering technology suggestions, involving "laughing out of the room", in the absence of evidence is completely unprofessional, very silly, utterly rude, purile, immature and wholly unacceptable. (And just quietly on that basis alone, I'd be pretty confident my solutions are faster than any put together by a team that ignores evidence and belittles talent. Again I say this is not about one technology vs another, this about "Laughing out of the room." Having said that I've sometimes used C and it has worked really quite well in those particular cases. I can say the same of C++ fwiw).

Re: Why is Rust slightly slower than C?

#119

Post by ncmncm »

bt848 wrote: post #115
codesushi42 wrote: post #76

Earlier quoted context omitted.

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++…

In what way can “STL” be considered a performance hit? It looks like you just threw out every C++-related word you know.

I have carefully benchmarked STL code against C-like loops and never got any measurable difference, even through multiple layers of abstraction.

Similarly, virtual function calls on modern CPUs are essentially free if the branch predictor can predict correctly, the usual case.

FUD from the '90s is way past its sell-by date.

Re: Why is Rust slightly slower than C?

#120

Post by verall »

bt848 wrote: post #115
codesushi42 wrote: post #76

Earlier quoted context omitted.

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++…

In what way can “STL” be considered a performance hit? It looks like you just threw out every C++-related word you know.

They probably meant, like everyone else who says that STL is a perf hit, "using STL containers is a perf hit"
Post reply on HN