Why is Rust slightly slower than C? • Hacker News Board

Re: Why is Rust slightly slower than C?

#211

Post by jcelerier » Thu, Sep 12, 2019, 2:30 PM UTC

ZoomZoomZoom wrote: post #155

jcelerier wrote: post #147

Earlier quoted context omitted.

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

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.

But more cores generally means that every core frequency goes down due to heat, which means that you can do less on each individual track.

Re: Why is Rust slightly slower than C?

#212

Post by michael_j_ward » Thu, Sep 12, 2019, 2:36 PM UTC

steveklabnik wrote: post #198

michael_j_ward wrote: post #191

Earlier quoted context omitted.

What exactly does "you couldn't implement it yourself any better" mean if the current implementation isn't as fast as it could be? Or are you saying that the current implementation fails to live up to the "zero cost abstraction" goal?

The implementation of bounds checking couldn't be written any better: https://doc.rust-lang.org/1.37.0/src/core/slice/mod.rs.html#... #[inline] fn get(self, slice: &[T]) -> Option { if self This is exactly how you'd write the feature, by hand, if you were implementing the language. That the optimizer could, but does not, do as much optimization as it theoretically can, means that it has more work to do. But that's di…

I don't know if you edited your comment, or if it was just my pre-coffee reading comprehension missed the part "because the compiler isn’t always removing bounds checks that are provably true."

I understand now, gracias.

Re: Why is Rust slightly slower than C?

#213

Post by steveklabnik » Thu, Sep 12, 2019, 2:49 PM UTC

michael_j_ward wrote: post #212

steveklabnik wrote: post #198

Earlier quoted context omitted.

The implementation of bounds checking couldn't be written any better: https://doc.rust-lang.org/1.37.0/src/core/slice/mod.rs.html#... #[inline] fn get(self, slice: &[T]) -> Option { if self This is exactly how you'd write the feature, by hand, if you were implementing the language. That the optimizer could, but does not, do as much optimization as it theoretically can, means that it has more work to do. But that's di…

I don't know if you edited your comment, or if it was just my pre-coffee reading comprehension missed the part "because the compiler isn’t always removing bounds checks that are provably true." I understand now, gracias.

I don't think I did, but I am very empathetic to pre-coffee reading comprehension woes :) Glad we got it sorted.

Re: Why is Rust slightly slower than C?

#214

Post by kzrdude » Thu, Sep 12, 2019, 2:59 PM UTC

ncmncm wrote: post #140

kzrdude wrote: post #135

Earlier quoted context omitted.

The actual bounds checking instructions are often negligible in terms of overhead, but it can inflict damage by inhibiting other optimizations and loop optimizations, like reduction or vectorization.

Low-hanging fruit. But there are still bigger fish to fry. Lower-hanging bigger fish? Rust isn't mature yet. Give it ten years. It will either exceed C performance, or fade away. It's still too early to say which.

What's the bigger things that need solving in Rust?

Re: Why is Rust slightly slower than C?

#215

Post by rswail » Thu, Sep 12, 2019, 3:07 PM UTC

graycat wrote: post #192

leni536 wrote: post #168

Earlier quoted context omitted.

The currently used C standards have no direct relationship with K&R and they define both the language and the standard library functions.

Then they changed the language. C was not supposed to change.

Who said? K&R is pre ANSI C, so pre any standardization.

The concept of the C standard library post-dates ANSI C, so to say that they "changed" the language in that they more closely documented the behavior of the language and the standard library means that, for all intents and purposes, the standard library is part of the language.

Which is exactly the point you are making about FORTRAN and PL/1. That they have standardized functions that perform in a documented manner and so can therefore be optimized by the compiler.

That C compilers understand the defined behavior of strcpy et al means that they are allowed to optimize the implementation.

Re: Why is Rust slightly slower than C?

#216

Post by StavrosK » Thu, Sep 12, 2019, 3:08 PM UTC

kbenson wrote: post #43

emmericp wrote: post #39

Earlier quoted context omitted.

Another thing to point out: our 6% - 11% difference is already quite low. Netbricks [1] has a similar comparison between a Rust and a C network function (only the NF, driver in C in both cases) and they find 14% (LPM) to 20% (synthetic NF) difference. Fun fact: we've a system where Rust is faster than C despite still using more instructions, so yeah, neither instructions nor cycles tell the whole story... [1] https:/…

> Fun fact: we've a system where Rust is faster than C despite still using more instructions I think Bryan Cantrill did a pretty good explanation on differences you might see when rewriting something in Rust[1], and one of the things he looked at to see what was going on was Cycles Per Instruction. Instruction count itself means little if the instructions themselves have very different performance profiles and requir…

Not only that, but your tight loop that takes up most of the execution time might have fewer instructions, whereas the rest of the program might have more, making the overall total higher but "instructions per time spent in function" lower.

Re: Why is Rust slightly slower than C?

#217

Post by igouy » Thu, Sep 12, 2019, 3:13 PM UTC

emmericp wrote: post #40

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

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

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?

Re: Why is Rust slightly slower than C?

#218

Post by jnordwick » Thu, Sep 12, 2019, 4:09 PM UTC

eridius wrote: post #157

comex wrote: post #153

Earlier quoted context omitted.

I don't entirely agree. As an analogy, suppose that you want to pass a pointer to an object as a function argument. As the programmer, you expect the object will necessarily remain allocated as long as the function uses it, since it's kept alive elsewhere, but you might have made a mistake. Before Rust, your options would be: 1. Use a C-style raw pointer. This has no overhead but is unsafe. 2. Use a reference counted…

Bounds-checked indexing isn't an abstraction, it's a safety feature. The abstraction is compared to manually doing bounds checks like you would in C. // C safe subscript if (i That's the abstraction, and Rust introduces no overhead here.

This is such a useless definition of "zero-cost" abstraction that almost everything qualifies for it.

Re: Why is Rust slightly slower than C?

#219

Post by haberman » Thu, Sep 12, 2019, 4:15 PM UTC

imtringued wrote: post #201

dbaupp wrote: post #160

Earlier quoted context omitted.

This is taking zero-cost abstraction to the extreme, and I think waters down the concept to the point that it almost isn't useful. One can argue that any feature is a zero-cost abstraction for the exact set of trade-offs it has (in the limit: "you couldn't implement a feature that executes this exact sequence of instructions 'mov ...' any better if you did it by hand"). I think focusing on a hypothetical perfect code…

Bounds checking is not an abstraction. Therefore you are the one who is twisting the word "zero-cost abstraction" to cover things it doesn't cover.

GC isn't an abstraction either. By that argument, you could claim that you have zero-cost abstractions even if you have stop-the-world GC.

Re: Why is Rust slightly slower than C?

#220

Post by SAI_Peregrinus » Thu, Sep 12, 2019, 5:03 PM UTC

graycat wrote: post #194

glangdale wrote: post #181

Earlier quoted context omitted.

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…

> 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? It's simple. Again, once again, over again, yet again, one more time, the main point is that functi…

> C is not supposed to have changed from K&R -- that it is backwards compatible was one of its main selling points and main reason to put up with such meager functionality that had programmers digging with a teaspoon.

C has gained new functionality and features. It just hasn't deprecated the old ones. K&R C will still compile with a modern C compiler, but it won't be as good as modern (C99/C17) C.