Why is Rust slightly slower than C?

https://github.com/ixy-languages/ixy-languages/blob/master/Rust-vs-C-performance.md

by homarp • 7 years ago

326 247 7 years ago

I wonder if some of the bounds checks could be eliminated by using iterators instead of loops? It is common when coming from C to Rust to sometimes avoid complicated iterators because you imagine it can't be fast, so you use a loop, but usually the iterator really is faster.

And I believe the checked math can be eliminated just by explicitly stating you want to use unchecked math. It doesn't require unsafe to do so.

holy_city2• 7 years ago

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.

The_rationalist3• 7 years ago

Source?

GordonS• 7 years ago

As an aside, I seem to recall .NET making an interesting optimisation here, such that if you access an array using, for example, `data[20]`, bounds checks are omitted for lower indexes.

hcs2• 7 years ago

Integer overflow checks are disabled by default in release builds, the author noted they were explicitly enabled in this project for additional safety.

(This is just for the normal operators, if you use e.g. checked_add() or wrapping_add() then you can be explicit about what behavior you want.)

[edit: oops, the overflow checks were only enabled for a separate test, see note from the author below]

emmericp9• 7 years ago

No, we don't run with overflow checks by default; the overflow check performance analysis is a separate test.

ridiculous_fish• 7 years ago

It's worth observing that signed integer overflow is undefined in C but defined in Rust, which can impose an additional cost.

C: https://godbolt.org/z/CDha8-

Rust: https://godbolt.org/z/DlN3uf

jnordwick6• 7 years ago

iterators had a lot of work done on them for this reason. although it doesn't always work.

eg, once the difference between using a sign and unsigned value in a loop was causing tustc to not be able to optimize out the checks and resulted in terrible performance for that loop, but it was non-trivial to figure this out

im3w1l2• 7 years ago

I'm surprised how much bloat rusts adds and how little it affects the speed.

Is there any other downside? Electricity consumption / heat? Evicting other stuff from cache?

webkike2• 7 years ago

LLVM is a really good backend that optimizes away a lot of it. Bounds checks, for example, usually get removed.

saagarjha• 7 years ago

…when possible, of course, unless you're using one of the unsafe methods.

wyldfire2• 7 years ago

What bloat are you referring to specifically?

grenoire• 7 years ago

I think GP forgot to build with the release flag instead of debug.

im3w1l2• 7 years ago

I'm referring to the table in the article.

snuxoll• 7 years ago

We can see in this specific case there was better cache locality and more data was served from the L1 and L2 cache with a drop in L3 cache misses (no hits, because it didn’t have to look in L3 for anything).

6 cycles for bounds checks that the branch predictor never had to rewind on is nothing in comparison to saving a couple trips to L3.

topspin• 7 years ago

We can see in this specific case there was better cache locality

Dramatically better L1 and L2 cache behavior. It seems clear that the additional instruction load of the Rust driver is partially made up by the excellent cache utilization.

This "Rust vs C" document is just one part of a larger analysis of network driver implementations in many languages; C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript and Python. Have a look at the top level README.md of that GitHub repo.

safercplusplus• 7 years ago

Presumably a C++ (or SaferCPlusPlus[1] ;) implementation would see a similar cache performance advantage versus C?

Also, isn't it unintuitive that branch mispredictions go up with larger batch sizes? Wouldn't there be fewer branches per unit time?

[1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

eximius2• 7 years ago

Unless/until a lot more is written in Rust... not much. It uses slightly more base RAM to load the binary. Some of the bloat is things that in C programs would be dynamically linked in - it isn't that Rust is doing more, it's that C gets to share a lot of stuff and Rust has to bring it's own.

masklinn8• 7 years ago

It uses slightly more base RAM to load the binary.

It's mostly vmem until / unless the data actually gets used though, no?

hcs2• 7 years ago

It does take extra space, but ideally you'd store the exceptional error handling code out-of-line, so that they don't need to take up cache in the common case.

emmericp9• 7 years ago

Our results probably only hold true for workloads with a low IPC. The test case is also a very limited forwarder, but real network functions also have a relatively low IPC in my experience (don't have any numbers to back up this claim, though).

userbinator• 7 years ago

In general, the effect of bloat is not visible in benchmarks like these where the goal is to run something small many many times, with ample memory available, and as little else on the system adding noise to the results as possible. It's the same reason you see "Java is faster than C" benchmark results, yet everyone knows how the former actually performs in practice.

The effects of larger memory usage don't become obvious until other applications start contending for it and/or swapping happens, and it's conveniently also something that is not as easily blamed on one application "being slow", which is why it doesn't receive nearly as much attention as it should.

wyldfire2• 7 years ago

Our Rust driver is a few percent slower than our C driver

Please qualify the title: it's not generally the case.

tom_mellior5• 7 years ago

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 compiler (micro-)optimizations might be at play as well.

Also, from the paper's Conclusions: "The cost of [Rust's] safety and security features are only 2% - 10% of throughput on modern out-of-order CPUs." 10% network throughput is a lot.

steveklabnik11• 7 years ago

(or maybe there is even a flag for this?)

We specifically do not give you a flag to control this behavior, but you can choose to call different functions to use unchecked access.

sh1mmer2• 7 years ago

I'm curious if there is a discussion thread on that design choice.

glangdale4• 7 years ago

This, imo, is absolutely correct (it is a dark idea to have a "let's be unsafe for more performance" flag) but maybe a experimental build of the Rust compiler could have this as a configuration option? Possibly the toolchain could warn every step of the way if such a 'tainted' module is ever linked, etc.

It just seems like this sort of question is going to recur, and being able to persistently track the overhead of checking (it would allow you to monitor specific performance improvements) is much nicer than having someone do a one-off experiment.

Diggsey2• 7 years ago

In case anyone is interested, rust has unsafe methods to index arrays without bounds checking:

https://doc.rust-lang.org/std/primitive.slice.html#method.ge...

hossbeast• 7 years ago

Sounds much worse than the compile time flag.

lallysingh• 7 years ago

Is there a disassembly to compare? I'd rather just check.

jcelerier3• 7 years ago

only 2% - 10%

yeah, I wonder in which world they live. If I could sell a limb to get 10% more audio plug-ins in my DAW, you could be sure that my bedtime book would be "Life pro-tips for quadruple amputees"

ZoomZoomZoom2• 7 years ago

Fortunately for your body, this problem is easily solvable by hardware. Modern DAW's performance scales well with multithreading, for regular use cases at least.

emmericp9• 7 years ago

2-10% for an already fast user space driver is nothing.

State of the art for a lot of these use cases is still the kernel driver which is ~7 times slower. Sure, all that stuff is moving to XDP/eBPF/AF_XDP, but that is still ~20-30% slower than a user-space driver.

Also, these 2-10% only show up when underclocking the CPU while running the unrealistic benchmark of forwarding packets bidirectionally on only one core (trivial to parallelize).

In the end it's about 6-12 cycles spent more in the driver. That's not a lot if you have a non-trivial application on top of it.

fluffything11• 7 years ago

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.

viraptor4• 7 years ago

I wish they included rust benchmark code so we can play around and improve it. If the issue really is the bounds checks, then there are many ways to massage Rust code to make it obvious they're not needed. But it seems you can't really play with it without running on actual hardware.

emmericp9• 7 years ago

Really no point to running it without real hardware, it will perform completely differently if you don't have the MMIO accesses and DMA by the NIC in there.

We'll have a VirtIO driver soon, but that's bottlenecked by the hypervisor and not really useful for performance tests.

viraptor4• 7 years ago

With fake memory mapping it would not access the same memory, but you'd still run the same code, right? So the timing/details of access may change a lot, but the profile of executed code would be still meaningful. For example, if you run a loop with range checks, and a loop without them, it doesn't matter what's happening in the loop, as long as it stays consistent between the runs - you can still tell things about the loop overhead.

Or did I miss something more nuanced?

NickMar• 7 years ago

They have provided the code :https://github.com/ixy-languages/ixy.rs and the benchmark script : https://github.com/ixy-languages/benchmark-scripts . I found that in the readme of the repo containing the article.

viraptor4• 7 years ago

Those generate traffic on a real, connected PCI device. I meant branches of isolated sections of code with fake memory mapping.

aloknnikhil• 7 years ago

It's be interesting to see how Rust performs compared to vector packet processing (https://fd.io/technology/). My hunch is, it's not very easy to implement something similar in Rust that can keep the instruction cache hot, especially going by the data from this paper.

fluffything11• 7 years ago

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 want to focus this on Rust, then the downside of Rust vs C here is that C has a GCC toolchain that happens to be faster for this use case, but Rust does not.

emmericp9• 7 years ago

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% slower, so it does not explain the difference entirely.

fluffything11• 7 years ago

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.

donio• 7 years ago

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

013a• 7 years ago

Yeah, their initial explanation is that its the "safety features", but I was under the impression that literally everything related to rust's safety happens at compile time. Their big selling point is the "zero cost abstractions".

atoav3• 7 years ago

While you are spot on with zero cost abstractions a bounds check in Rust is not without penalty (if enabled, should be off in release mode)

mehrdadn• 7 years ago

I don't know... while it may not be the case here, I wouldn't be exactly shocked if the fact that Rust restricts your ability to do some things ends up having a performance penalty, even if any safety checks themselves happen at compile time.

Zarel2• 7 years ago

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.

kzrdude4• 7 years ago

It's never claimed that every abstraction in Rust is zero cost. Just that these are often possible.

rstuart4133• 7 years ago

The explanation I heard from a Rust core dev (explain why Rust tends to be slightly slower than C++) is the borrow checker makes programmers to use a slightly different coding style. Were C programmers tend to pass references around Rust programmers tend to take copies of to avoid the borrow checker.

Passing the smaller reference will be faster in single threaded code. In multi threaded code I'd expect making a thread local copy to be a win, and indeed multi threaded Rust programs tend to be quicker than their C/C++ counterparts.

paulddraper3• 7 years ago

the downside of Rust vs C here is that C has a GCC toolchain that happens to be faster for this use case, but Rust does not.

Yes, this is the "legitimate" criticism to be made here.

I say "legitimate" because LLVM has a bright future and I doubt many people see that as an actual issue.

m0zg• 7 years ago

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.

masklinn8• 7 years ago

The very different load/store amounts, higher rate of instructions being retired and seemingly better L1 behaviour seem interesting though, does compile their C code under clang yield the same behaviour or is it closer to GCC's?

bjourne2• 7 years ago

I similarly found that C was slightly faster than Rust in a microbenchmark called LPATHBench: https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9... That was with clang which performed significantly better than gcc. clang appears to generate very good code tree traversals.

But this was way back in 2016. Numbers from microbenchmarks that old are hardly relevant anymore.

asdkhadsj• 7 years ago

As an aside, can I just say how happy I am that the language I generally find a joy to use is nearly as fast as C? It's my daily driver, and I have almost no complaints.

I really do love this language.

atoav3• 7 years ago

Agreed. And even if it would be gone over night I still learned a lot by using it.

jayflux• 7 years ago

Nearly? Rust is already faster than C in quite a few scenarios and benchmarks. The other comment also said Rust is faster when C is compiled through clang.

physicsyogi• 7 years ago

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

emmericp9• 7 years ago

Geometric mean over their "fastest measurement at the largest workload" data set actually shows that Rust is faster than C in this benchmark

igouy2• 7 years ago

Please share!

If true, can you say the difference is not due to chance?

(fwiw the GM that I see — whether the scores are based-on elapsed secs, cpu secs or "busy" secs — are a little slower for the Rust programs.)

Perhaps the median score of the Rust programs is faster?

jamessteel2• 7 years ago

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.

graycat9• 7 years ago

On how "fast" C is, guys, sorry to say this, but in my experience actually (1) even assembler is not very "fast", (2) for much the same reasons C is not very fast, (3) often Fortran is faster than C, and (4) PL/I can be the fastest of all of (1)-(4). More generally, how Fortran and PL/I can be faster than C should be exploited quite generally but apparently has not been fully generally.

Why? How can Fortran and PL/I beat assembler and C?

In particular, first, Fortran can easily beat C in subroutines that receive multidimensional arrays as parameters. Here PL/I also can beat C for the same reasons. Second, PL/I beats both Fortran and C in string handling.

How, why, what the heck is going on? In simple terms, first, Fortran gets to compile the multidimensional array handling within the language and C does not: In C, the programmer has to write the array addressing logic (e.g., row major or column major) that looks to the C compiler like just more code where the compiler has to treat that handling as general purpose code; the Fortran compiler KNOWS that the work is array handling and gets to make better uses of registers and to store intermediate results where the Fortran source code can't see them and, thus, take some liberties. That is, in Fortran, the array handling is in the language where the compiler can take liberties where a C compiler has to treat the work as ordinary code and not take the liberties. PL/I has the same advantages. Second, similarly for string handling in PL/I.

In particular, commonly in C and Fortran, string handling is via subroutines that to the linkage editor look like external references that must be linked. That indirection, stack manipulation, register save, restore, etc., PL/I doesn't have to do.

Scientific, engineering, analytical code is awash in multidimensional arrays, and there Fortran and PL/I can beat C. Now nearly all code is awash in string handling, and there PL/I can beat both Fortran and C.

For assembler, the old remark was that in practice an assembler programmer would write his own code that was less well designed and, thus, slower than C, Fortran, and PL/I. Further, the assembler programmer would be tempted to have a large library for arrays and strings that would be external subroutine calls likely with the overhead. Sure, in principle, assembler should win, but in practice writing code good enough to win is usually a bit too much work.

More generally, compiled functionality offered directly by the language can be faster than libraries of external subroutines, methods, etc.

glangdale4• 7 years ago

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 very unlikely that strcpy or memmem is going through external linkage.

graycat9• 7 years ago

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 surprised if in C strcpy, etc., were not still external: They USED to be, and then someone might have written their own version, e.g., for their own versions of strings, and linked to it; for compatibility, strcpy would about have to be an external function call still.

eigenloss2• 7 years ago

This is a great comment, but it's in the wrong place. The OP is about using Rust/C to compose network and packet handling software; using Fortran there would be completely pointless. There is no easy gain to be found from vectorization in networking.

graycat9• 7 years ago

I was not bringing up vectorization in Fortran. E.g., in Fortran we can have

     Real X(20, 30,40), all

     Call addall(X, 20, 30,40, all)

and have

          Subroutine Addall (Z, L, M, N, Result)

          Real Z(L, M, N), All, Result

          Integer L, M, N, I, J, K

          Sum = 0.0
          Do 100 I = 1, L
          Do 100 J = 1, M
          Do 100 J = 1, N
          All = All + Z(I, J, K)
     100  Continue

So what is good here is that in the subroutine the parameter Z gets its array bounds PASSED from the calling routine, the statement

     Real Z(L, M, N)

honors those bounds, and the code then does the indexing arithmetic (row major or column major, I don't recall which) using the bounds passed as arguments to the parameters L, M, N. That is, in the subroutine we can have the array bounds as parameters, and still Fortran does the array indexing arithmetic.

Can't do that in C: In C the programmer has to do array indexing with their own code in the subroutine. Thus to the compiler this code is just ordinary code and has to be treated as such. In contrast array indexing Fortran does is not from ordinary code thus permitting Fortran to make better use of registers and, for example, leaving intermediate values in registers and not writing them back to storage in variables known to the source code.

Here vectorization has nothing to do with it.

Bluntly, C doesn't support arrays, and that's a bummer for the programmer and also execution speed.

My point is on topic because this thread is about C performance, and I've brought up the point that functionality, in this case array indexing arithmetic, defined in the language and implemented in the compiler can be faster than the programmer implementing the functionality in their own code, especially, in the case of strings, if that implementation is via external routines.

I thought that this was all simple and clear.

maxk423• 7 years ago

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

(2) Optimization. Rust and C are going to be compiled with either GCC or LLVM. The way both work is they compile the program to an internal representation of opcodes, which then get optimized and platform-specific, optimized machine code is then emitted. In some cases the specific set of opcodes or optimizations used with various conventions / data structures may be more efficient or less efficient. Over time this will improve.

atoav3• 7 years ago

AFAIK Rust type checks only during compilation and won’t allow you to cast values of one into another without clearly defining how it should work. So if there are any type related checks done during runtime, they happen because you added them.

paulddraper3• 7 years ago

Rust is strongly-typed, is it not?

Yes, at compile-time.

Does it do run-time type-checking?

No. The closest thing is the occasional vtable-based dynamic dispatch.

Exception handling in particular requires a non-negligible amount of run-time overhead

Wouldn't the side-table approach be used? That has essentially zero cost, if an exception is not thrown.

maxk423• 7 years ago

Well again -- I don't know how Rust does it specifically, but when you compile C++ programs in g++ with exceptions disabled you pretty consistently see a 10% speed improvement right off the bat and the performance falls more closely in line with the performance of C code.

Specifics aside the broader point is that the runtimes between the two languages will differ.

andolanra• 7 years ago

Others have pointed out that Rust's type-checking is all done at compile time. Rust also does not have exception handling.

To be more specific: errors in Rust are either propagated by function return values (usually in the form of `Result` or `Option` types) which do not require any kind of runtime support, or by panicking, which unwinds the stack for clearing-up of resources and then halts the running thread. (Panics cannot be caught, although they can [EDIT: sometimes but not always; see burntsushi's comment below] be observed by a parent thread if they have occurred in a child thread.) Rust's "runtime", therefore is negligible, much like C's: it consists mainly of functions which can be called for things like stack unwinding or backtrace support.

burntsushi• 7 years ago

The thread boundary restriction for catching panics was lifted quite a while ago with std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Do note the caveats in the docs though. It isn't guaranteed to catch all panics. Indeed, unwinding can be disabled completely with a compiler option (instead, panics will abort).

jadbox2• 7 years ago

AFAIK, some Rust types are checked at runtime. For example, RefCell:

"Because RefCell<T> allows mutable borrows checked at runtime, you can mutate the value inside the RefCell<T> even when the RefCell<T> is immutable."

*source https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (like RefCell).

mlindner• 7 years ago

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.

maxk423• 7 years ago

Yes, rust has a runtime. Even most assemblers have runtimes these days.

Take a look at this: https://imgur.com/lPOPj1G

You see that difference? That's not rust producing less-efficient code. That's the more complex rust runtime.

Think it's an artifact of static linkage? Guess again.

https://imgur.com/KsrApXC

But IIRC rust doesn't statically link glibc by default.

So the difference in runtime overhead is more than 10x the machine code size. That doesn't translate to a 10x slowdown and a lot of that is probably baked-in optimization but rust certainly has a runtime and associated overhead and it has a lot larger runtime than C.

fluffything11• 7 years ago

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

jamessteel2• 7 years ago

This is an additional comparison I found with other languages.

https://github.com/ixy-languages/ixy.swift/blob/master/perfo...

didibus• 7 years ago

Would be nice to also see why Java is slower than C# and Go.

masklinn8• 7 years ago

https://www.reddit.com/r/programming/comments/d2pku3/a_highs...

We are at ~20 bytes of allocation per forwarded packet in Java.

C# and Go have much better facilities to avoid heap allocations.

pjmlp2• 7 years ago

Java will eventually get them via Panama and Valhalla projects, something that should have been there from the the get go, though.

ncmncm16• 7 years ago

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 any pointer-to-const might be use to write through. Because alias analysis is ironclad, copies can be elided even if some function borrows a reference to the copy.

At a larger scale, improved abstraction tools mean more powerful libraries may be written and used, that would be unavailable to the C coder.

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.

This is why articles about other languages comparing them to some fraction of C performance are amusing. C is a low bar. If you can't beat C, you are Doing It Wrong. In Rust's case, that would be "still doing it wrong"; we may assume fixing this is on the schedule, after various "getting it right" and "compiling faster" goals are met.

codesushi422• 7 years ago

That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++ when compared to C.

Rust has optimization issues of its own apparently.

C isn't a low bar. It is the benchmark.

jeremyjh• 7 years ago

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.

bt848• 7 years ago

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

pjmlp2• 7 years ago

Nowadays, it is ironic given how bad C compilers used to generate code all the way up to the late 90's.

fluffything11• 7 years ago

C isn't a low bar. It is the benchmark.

C isn't the benchmark, assembly is.

C forces you to write code closer to what assembly looks like than Rust or C++. That's good if you can write good assembly, and bad if you cannot. That's particularly bad for writing robust code that doesn't have security vulnerabilities, because the C programmer is required to manually write all checks correctly, while C++ and Rust have abstractions that automatically write the checks for you.

You don't have to use them in those languages if you don't want to.

As I mentioned in the other thread, I think this article is comparing GCC vs LLVM, so the info in the post is kind of moot. But if the authors really believe that Rust bound checks are the culprit of the performance difference, they can just remove them. Takes one line of code, and would show if they are right or wrong.

freejulian85• 7 years ago

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

monocasa7• 7 years ago

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

dang• 7 years ago

Ok, but please don't be rude or post shallow dismissals here. If you know more, it would be great to share some of what you know. Then we can all learn something. Alternatively, it's fine not to post even when someone else is wrong.

https://news.ycombinator.com/newsguidelines.html

xigency• 7 years ago

Is there an element of runtime correctness and safety as well? Are we comparing programs that have proper bounds checking to ones that don't?

ncmncm16• 7 years ago

One hopes that the optimizer has arranged to check the bounds at the start of the loop, and not in it. Apparently Rust's doesn't, yet, but it seems usually to happen to overlap the checking it does with other stalls, so it might not usually matter much.

harry85• 7 years ago

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.

hermitdev2• 7 years ago

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.

Quekid52• 7 years ago

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

sharpneli• 7 years ago

”even though C++ suffers from the same aliasing flaws C has.”

C no longer has them. Not since a standard that’s 20 years old (C99). restrict qualifier handles that.

Unfortunately C++ committee has not included restrict in C++, but it is available in all major compilers as an extension.

masklinn8• 7 years ago

C absolutely has them, you can opt out of aliasing on an individual basis but aliasing flaws are the default.

So much so that rustc regularly has to disable their noalias annotations because its pervasive noaliasing exercises rarely used LLVM paths and leads to miscompilation. Outputting noalias is currently disabled again in IR generation[0][1].

Note from downthread comments in [1] that it's completely possible to create valid C code which miscompiles on both GCC and LLVM (though GCC has been fixed since), it's just unlikely that a regular C dev would write the mix of unrolled loops, inlined functions and restrict annotations which triggers the issue.

[0] https://github.com/rust-lang/rust/issues/54462

[1] https://github.com/rust-lang/rust/issues/54878

Omin• 7 years ago

restrict is so rarely used that optimizations based on non-aliasing data are broken in both major compilers. A fact which has bitten Rust repeatedly.

tom_mellior5• 7 years ago

It is routine for C++ programs to be substantially faster than a C program that attempts the same job

Can you point us to a concrete benchmark to illustrate this?

kahlonel• 7 years ago

it does not suffer from the pointer aliasing faults C has.

There's a `restrict` keyword in C99.

const really means const, where in C the compiler has to assume any pointer-to-const might be use to write through

Lookup what `const int *const ptr` does in C.

account422• 7 years ago

Look up what (int*)ptr does in C.

andrepd• 7 years ago

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)

steveklabnik11• 7 years ago

Yes, you use .get_unchecked instead of [].

lmkg• 7 years ago

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.

masklinn8• 7 years ago

Newbie to rust, but surely there must be a way to disable bounds checking in rust, right??

There's an unsafe method to not do bounds-checking, keeping in mind that indexing outside the collection is UB. It's usually a better idea to e.g. use iterators, or try and nudge the optimiser towards removing the bounds checks.

disables it for optimised builds

A compiler flag to add UBs to a valid (though not correct) program is not considered a great idea by the rust team.

hamilyon2• 7 years ago

So, the main point I got from article is: rust has runtime array bound checks and integer owerflow checks. I am excited. Where do I sign up?

CodesInChaos• 7 years ago

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 is primarily a C++ compiler backend. For example infinite loops without side-effects are UB in C++, but supposed to be well defined in Rust. This is even an issue for C, because `while(1) {}` is a valid in C but UB in C++. https://github.com/rust-lang/rust/issues/28728

emmericp9• 7 years ago

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 :(

masklinn8• 7 years ago

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

fulafel2• 7 years ago

The infinite-loop Rust issue is old, and the asm "" fix had been known for a long time. I wonder what is behind this seeming perf over correctness decision.

timvisee• 7 years ago

We should not forget that Rust wants safety over speed, so it utilizes array bound checks and such at runtime, because programmers make mistakes. Sadly, that introduces slight overhead.

Why is Rust slightly slower than C?

Related Stories