Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

11–20 of 402 posts

Re: Is Rust faster than C?

#11

Post by embedding-shape »

bfrog wrote: post #9

One example where Rust enables better and faster abstractions is traits. C you can do this with some ugly methods like macros and such but in Rust it’s not the implementers choice it’s the callers choice whether to use dynamic dispatch (function pointer table in C) or static dispatch (direct function calls!) In c the caller isn’t choosing typically. The author of some library or api decides this for you. This turns o…

It's a tradeoff though, as I think traits makes the Rust build times grow really quickly. I don't know the exact characteristics of it, also I think they speed it up compared to how it used to be, but I do remember that you'll get noticeable build slowdowns the more you use traits, especially "complicated" ones.

Re: Is Rust faster than C?

#12

Post by steveklabnik »

einpoklum wrote: post #6

tl;dr: Rust officially allows you to write inline assembly so it's fast, but in C it's not officially specified as part of the language. Plus more points which do not actually indicate Rust is faster than C. ... well, that's what I get for reading an article with a silly title.

That’s not how I would summarize what I wrote, for what it’s worth. My summary would be “the question is malformed, you need to first state what the boundaries are for comparison before you can make any conclusions.” I think this is an interesting thing to discuss because many people assume that the answer to “is x faster than C?” to be “no” for all values of X.

Re: Is Rust faster than C?

#14

Post by pron »

The question is what do we mean by "a fast language"? We could mean it to be how fast the fastest code that a performance expert in that language, with no resource constraints, could write. Or, we can restrict it to "idiomatic" code. Or we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget (in which case probably none of the languages mentioned here are among the fastest).

Re: Is Rust faster than C?

#16

Post by treyd »

embedding-shape wrote: post #11
bfrog wrote: post #9

One example where Rust enables better and faster abstractions is traits. C you can do this with some ugly methods like macros and such but in Rust it’s not the implementers choice it’s the callers choice whether to use dynamic dispatch (function pointer table in C) or static dispatch (direct function calls!) In c the caller isn’t choosing typically. The author of some library or api decides this for you. This turns o…

It's a tradeoff though, as I think traits makes the Rust build times grow really quickly. I don't know the exact characteristics of it, also I think they speed it up compared to how it used to be, but I do remember that you'll get noticeable build slowdowns the more you use traits, especially "complicated" ones.

Code is typically run many more times than it's compiled, so this is a perfectly good tradeoff to make.

Re: Is Rust faster than C?

#17

Post by ajross »

taminka wrote: post #4

struct field alignment/padding isn't part of the C spec iirc (at least not in the way mentioned in the article), but it's almost always done that way, which is important for having a stable abi also, if performance is critical to you, profile stuff and compare outputted assembly, more often than not you'll find that llvm just outputs the same thing in both cases

> struct field alignment/padding isn't part of the C spec iirc

It's part of the ABI spec. It's true that C evolved in an ad hoc way and so the formal rigor got spread around to a bunch of different stakeholders. It's not true that C is a lawless wasteland where all behavior is subject to capricious and random whims, which is an attitude I see a lot in some communities.

People write low level software to deal with memory layout and alignment every day in C, have for fourty years, and aren't stopping any time soon.

Re: Is Rust faster than C?

#18

Post by nicoburns »

K0nserv wrote: post #10
bfrog wrote: post #9

One example where Rust enables better and faster abstractions is traits. C you can do this with some ugly methods like macros and such but in Rust it’s not the implementers choice it’s the callers choice whether to use dynamic dispatch (function pointer table in C) or static dispatch (direct function calls!) In c the caller isn’t choosing typically. The author of some library or api decides this for you. This turns o…

> In c the callers isn’t choosing typically. The author of some library or api decides this for you. Tbf this applies to Rust too. If the author writes fn foo(bar: Box ) they have forced the caller into dynamic dispatch. Had they written fn foo(bar: impl BarTrait) the choice would've remained open to the caller

Right, but almost all APIs in Rust use something like

    fn foo(bar: impl BarTrait)
and AFAIK it isn't possible to write that in C (though C++ does allow this kind of thing).

Re: Is Rust faster than C?

#19

Post by _zagj »

einpoklum wrote: post #6

tl;dr: Rust officially allows you to write inline assembly so it's fast, but in C it's not officially specified as part of the language. Plus more points which do not actually indicate Rust is faster than C. ... well, that's what I get for reading an article with a silly title.

The article felt fairly dispassionate and even-handed to me, and I say this as someone who dislikes Klabnik very much and also dislikes the Rust community (especially its insidious, forced MIT rewrites of popular GPL software, with which they also break backwards compatibility). It is worth mentioning that there are certain things about Rust that conceivably could make it faster, e.g., const by default (theoretically facilitating certain optimizations), but in practice, thus far, do not.
Post reply on HN