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

Re: Why is Rust slightly slower than C?

#91

Post by DoreenMichele » Thu, Sep 12, 2019, 2:41 AM UTC

ShorsHammer wrote: post #87

The_rationalist wrote: post #12

Earlier quoted context omitted.

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

I've certainly seen requests for sources used obnoxiously by people who felt zero need to back up their side of the argument with sources. But it's also often a legitimate request to see what the OP is talking about.

The internet is vast. I sometimes have difficulty finding things I personally saw before and know exist. Slightly different search terms can turn up drastically different results and, with five million visitors per month to HN, it is a melting pot of people with vastly different backgrounds.

Re: Why is Rust slightly slower than C?

#92

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

Zarel wrote: post #58

013a wrote: post #42

Earlier quoted context omitted.

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

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.

Bounds checking is a “zero cost abstraction” in the sense that it is both “pay for what you use” and “you couldn’t implement it yourself any better.” That said, the implemention is not as fast as it theoretically can be, because the compiler isn’t always removing bounds checks that are provably true.

When const generic lands, you will be able to make those assertions! A basic implementation is in nightly.

Re: Why is Rust slightly slower than C?

#93

Post by steveklabnik » Thu, Sep 12, 2019, 2:52 AM UTC

glangdale wrote: post #59

steveklabnik wrote: post #19

Earlier quoted context omitted.

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

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 c…

If it is implemented, it will be used. And people will put it in their own builds.

We already have one “secret” escape flag feature, and people do use it, as much as we don’t talk about it and tell people not to use it when they find it.

Re: Why is Rust slightly slower than C?

#94

Post by eigenloss » Thu, Sep 12, 2019, 2:58 AM UTC

graycat wrote: post #37

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…

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.

Re: Why is Rust slightly slower than C?

#95

Post by glangdale » Thu, Sep 12, 2019, 2:59 AM UTC

steveklabnik wrote: post #93

glangdale wrote: post #59

Earlier quoted context omitted.

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 c…

If it is implemented, it will be used. And people will put it in their own builds. We already have one “secret” escape flag feature, and people do use it, as much as we don’t talk about it and tell people not to use it when they find it.

Maybe put a tainted flag in it that causes the linker or runtime to fail? Then don't open source or release the modifications to allow the linker/runtime to avoid that failure check and refuse to let anyone check in a "fix" that allows this check to be skipped to an official build...

This surely seems like an incredibly important cost. Surely it's worth doing a bit of ugly magic to be able to keep track of it persistently.

Re: Why is Rust slightly slower than C?

#96

Post by jcranmer » Thu, Sep 12, 2019, 3:06 AM UTC

paulddraper wrote: post #51

maxk42 wrote: post #50

Earlier quoted context omitted.

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.

Huh, that surprises me. g++ exceptions have been touted as zero-cost for the happy path. https://stackoverflow.com/a/13836329 http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012...

Zero-cost exception handling is only so cheap by excluding a lot of things from the cost/benefit analysis. It adds no extra code to the exception-free path. But it has a few major impacts:

* Exception tables are not particularly small, and can involve extra relocations, which can increase the time it takes to load the binary.

* Every function call where there is a variable with a destructor in scope has an implicit try/catch wrapped around it. This can increase code size tremendously, which hits your instruction cache. And, unlike the unwind tables, the relevant data is in the middle of your code sections, so you can't do tricks like lazy loading of the data.

* Every time you call a function that may throw, you need to break up the basic blocks. So every optimization in the compiler that cannot work across basic block boundaries is going to perform much more poorly with ZCEH.

* Of the various kinds of basic block edges, the exceptional edges are the hardest to reason about (computed goto edges being the second hardest). So many optimizations that can work across basic blocks are still going to bail out in ZCEH conditions.

* It's possible to ameliorate the optimization costs if the compiler can figure out that the callee isn't going to throw an exception and turn a may-throw call into a may-not-throw call. But memory allocation may throw (by default), so anything that might allocate memory (say, adding a value to a std::vector) potentially throws an exception and inhibits optimization.

Re: Why is Rust slightly slower than C?

#97

Post by jnordwick » Thu, Sep 12, 2019, 3:13 AM UTC

steveklabnik wrote: post #92

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.

Bounds checking is a “zero cost abstraction” in the sense that it is both “pay for what you use” and “you couldn’t implement it yourself any better.” That said, the implemention is not as fast as it theoretically can be, because the compiler isn’t always removing bounds checks that are provably true. When const generic lands, you will be able to make those assertions! A basic implementation is in nightly.

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

Re: Why is Rust slightly slower than C?

#98

Post by monocasa » Thu, Sep 12, 2019, 3:14 AM UTC

graycat wrote: post #84

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…

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+ y…

It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest.

And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well.

Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.

Re: Why is Rust slightly slower than C?

#99

Post by [deleted] » Thu, Sep 12, 2019, 3:15 AM UTC

jnordwick wrote: post #97

steveklabnik wrote: post #92

Earlier quoted context omitted.

Bounds checking is a “zero cost abstraction” in the sense that it is both “pay for what you use” and “you couldn’t implement it yourself any better.” That said, the implemention is not as fast as it theoretically can be, because the compiler isn’t always removing bounds checks that are provably true. When const generic lands, you will be able to make those assertions! A basic implementation is in nightly.

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

[deleted]

Re: Why is Rust slightly slower than C?

#100

Post by jnordwick » Thu, Sep 12, 2019, 3:15 AM UTC

atoav wrote: post #45

013a wrote: post #42

Earlier quoted context omitted.

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

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)

you can't turn bounds checking off.

there are unsafe method for vec that allow you unchecked access to the array, but you need to to write it in unsafe block (some code that is performance sensitive does this).