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

391–400 of 402 posts

Re: Is Rust faster than C?

#391

Post by bfrog »

Maxatar wrote: post #366
Seattle3503 wrote: post #273

Earlier quoted context omitted.

Interesting, there isn't some way to have a template that is polymorphic over virtuals?

In C++ you do it the other way around, have a single class that is polymorphic over templates. The name of this technique within C++ is type-erasure (that term means something else outside of C++). Examples of type erasure in C++ are classes like std::function and std::any, and normally you need to implement the type erasure manually, but there are some library that can automate it to a degree, such as [1], but it's…

It's neat this is a thing I guess, but I agree it looks fairly clumsy compared to the Rust answer.

Re: Is Rust faster than C?

#392

Post by arghwhat »

bcantrill wrote: post #359
josephg wrote: post #341

Earlier quoted context omitted.

> the Rust ecosystem's churn (constant breakage, edition migrations, dependency hell in Cargo.lock) creates its own class of problems. What churn? Rust hasn't broken compatibility since 1.0, over a decade ago. These days it feels like rust changes slower than C and C++. > Either way, I would like to reiterate that the comparison is flawed at a more fundamental level because hash tables and B-trees are different data…

One point of clarification: the C version does not have (and never had) a hash table; the C version had a BST (an AVL tree). Moreover, the "Rust hash table implementation" is in fact still B-tree based; the hash table described in the post is a much more nuanced implementation detail. The hash table implementation has really nothing to do with the C/Rust delta -- which is entirely a BST/B-tree delta. As I described i…

I wouldn't consider implementing a B-tree in C any more "arduous" than implementing any other notable container/algorithm in C, nor would making a library be "brutal" as moving data really isn't an issue. Libraries are available if you need them.

Quite frankly, writing the same in Rust seems far, far more "arduous", and you'd only realistically be writing something using BTreeMap because someone else did the work for you.

However, being right there in std makes use much easier than searching around for an equivalent library to pull into your C codebase. That's the benefit.

Re: Is Rust faster than C?

#393

Post by ratmice »

kawogi wrote: post #269
ratmice wrote: post #91

I feel like another optimization that rust code can exploit is uninhabited types. When combined with generics and sum types these can lead to entire branches being unreachable at the type level. Like Option or Result , rust hasn't stablized !, but you can declare them other ways such as an empty enum with no variants.

In your specific example `std::convert::Infallible` can be used: https://doc.rust-lang.org/std/convert/enum.Infallible.html

Sure, in the Result case, less in the option case. I didn't mention it because Infallible is documented and named specifically as an Error "The error type for errors that can never happen". The use of uninhabited types as an unreachable code optimization is useful beyond errors though.

Re: Is Rust faster than C?

#394

Post by randomNumber7 »

throwaway2037 wrote: post #329
randomNumber7 wrote: post #204

Earlier quoted context omitted.

In C there is the "restrict" keyword to tell the compiler that there is no other pointer to the values accessed over a certain pointer. If you do not use that the generated code can be quite suboptimal in certain cases.

> If you do not use that the generated code can be quite suboptimal in certain cases. I believe you, but I don't understand it. Can you give a simple example to demonstrate your point?

Say you have 2 pointers (that might overlap). You (or the compiler) keep one value read from the first pointer in a register, since the value is needed multiple times.

You then write access the second pointer. Now the value you kept in the register is invalidated since you might have overwritten it through the overlapping pointers.

Re: Is Rust faster than C?

#395

Post by bcantrill »

arghwhat wrote: post #392
bcantrill wrote: post #359

Earlier quoted context omitted.

One point of clarification: the C version does not have (and never had) a hash table; the C version had a BST (an AVL tree). Moreover, the "Rust hash table implementation" is in fact still B-tree based; the hash table described in the post is a much more nuanced implementation detail. The hash table implementation has really nothing to do with the C/Rust delta -- which is entirely a BST/B-tree delta. As I described i…

I wouldn't consider implementing a B-tree in C any more "arduous" than implementing any other notable container/algorithm in C, nor would making a library be "brutal" as moving data really isn't an issue. Libraries are available if you need them. Quite frankly, writing the same in Rust seems far, far more "arduous", and you'd only realistically be writing something using BTreeMap because someone else did the work for…

I don't often do this, but I'm sorry, you don't know what you're talking about. If you bother to try looking for B-tree libraries in C, you will quickly find that they are either (1) the equivalent of undergraduate projects that are not used in production systems or (2) woven pretty deeply into a database implementation. This is because the memory model of C makes a B-tree library nasty: it will either be low performance or a very complicated interface -- and it is because moving data is emphatically an issue.

Re: Is Rust faster than C?

#396

Post by steveklabnik »

esjeon wrote: post #390
steveklabnik wrote: post #355

Earlier quoted context omitted.

What abstraction do you refer to?

Rust is actually few steps above from the bare metal, to enforce its security invariants. Boundary checks (which breaks auto-vectorization of loops), stack probe, fat pointer (wastes register), fixed index type (uint), etc. There are other hidden costs coming from usage of std. Even `Result` is a bit of inefficiency. I'm not saying any of these are bad. I'm just saying Rust would be slower than C if * naively* used.

Okay, cool, I can see where you're going with this. I wouldn't exactly agree, because all of these things are stuff you can easily opt out of, but I thought you were maybe suggesting something like "the borrow checker has overhead" which I would take more direct issue with.

(and yeah, the opt out question gets right to what you're saying about "naively used", I saw "unavoidable" but you're not actually saying it's unavoidable.)

Re: Is Rust faster than C?

#397

Post by ActorNightly »

mywittyname wrote: post #376
ActorNightly wrote: post #372

Earlier quoted context omitted.

Here is my issue > Is Rust faster than C > Example: >... unsafe... Its like Rust proponents can't even see the irony.

I agree, I thought this was a weird example - but I'm not a Rust nor C programmer. I assume this example is used because programmers of either language reach for asm when looking for raw performance. But to me, it's shouldn't even be a discussion point, since even I know both languages can be made to emit the same assembly. Also, I think it side-steps the hard parts of the question - which is, what are the performanc…

>, what are the performance impacts of Rust safety?

None from the aspect of borrow model, since that is all compile time.

For safety at run time, there is a hit if you use certain structures because you can't figure out at compile time what things like dynamic bounds are. But its no different than C with having to do manual bounds checking.

Re: Is Rust faster than C?

#398

Post by michalsustr »

lionkor wrote: post #357
michalsustr wrote: post #176

Earlier quoted context omitted.

What are your favorite tools for profiling/optimizing C and Rust code?

Definitely the combination of callgrind (valgrind --tool=callgrind) and kcachegrind, or the combination of HotSpot and perf. I have toyed with Intel's vTune, but I felt it was very hard to get running so its discouraging before you even start. That said, if you need a lot of info on cache etc., vTune is fantastic.

Thank you! :)

Re: Is Rust faster than C?

#399

Post by groundzeros2015 »

gf000 wrote: post #335
groundzeros2015 wrote: post #207

Earlier quoted context omitted.

And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.

It reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer. - "That's not even close" - "Yeah, but it was fast" Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty? And it's not like the performance doesn't…

your topic is shifting from multi-threading benefits in language compilation, to ergonomics of C headers.

Re: Is Rust faster than C?

#400

Post by groundzeros2015 »

pjmlp wrote: post #302
groundzeros2015 wrote: post #207

Earlier quoted context omitted.

And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.

No it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.

Turbo pascal compiles faster because of better parallelization?
Post reply on HN