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

241–250 of 402 posts

Re: Is Rust faster than C?

#241

Post by kannujd »

nineteen999 wrote: post #228
arghwhat wrote: post #112

Earlier quoted context omitted.

To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`. Despite benefits, I don't actually think the memory safety really plays a role in the usage ra…

> (As a personal anecdote, I've probably run into more concurrency-related heisenbugs in Go than I ever did in C, with C heisenbugs more commonly being memory mismanagement in single-threaded code with complex object lifetimes/ownership structures...) This is my experience too.

[flagged]

Re: Is Rust faster than C?

#242

Post by ndesaulniers »

OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

> For instance, in C, qsort() takes a function pointer for the comparison function, in Rust and C++, the standard library sorting functions are templated on the comparison function.

That's more of a critique of the standard libraries than the languages themselves.

If someone were writing C and cared, they could provide their own implementation of sort such that the callback could be inlined (LLVM can inline indirect calls when all call sites are known), just as it would be with C++'s std::sort.

Further, if the libc allows for LTO (active area of research with llvm-libc), it should be possible to optimize calls to qsort this way.

Re: Is Rust faster than C?

#243

Post by salmon640 »

marcianx wrote: post #117
steveklabnik wrote: post #101

Earlier quoted context omitted.

Not just all &mut T, but also all &T, where the T does not transitively contain an UnsafeCell . Click "show llvm ir" instead of "build" here: https://play.rust-lang.org/?version=stable&mode=release&edit...

I was confused by this at first since `&T` clearly allows aliasing (which is what C's `restrict` is about). But I realize that Steve meant just the optimization opportunity: you can be guaranteed that (in the absence of UB), the data behind the `&T` can be known to not change in the absence of a contained `UnsafeCell `, so you don't have to reload it after mutations through other pointers.

[flagged]

Re: Is Rust faster than C?

#244

Post by kazinator »

Assembly is not part of the C language in the sense that it's not in the ISO standard dialect, which is inapplicable to Rust.

Rust is a project that is rather more comparable to GCC than ISO C.

Re: Is Rust faster than C?

#245

Post by jonstewart »

JacoboJacobi wrote: post #104
jonstewart wrote: post #37

“It’s the memory, stupid!” So wrote Richard Sites, lead designer of the famous DEC Alpha chip, in 1996 ( http://cva.stanford.edu/classes/cs99s/papers/architects_look... ). It’s rung true for 30 years. Where C application code often suffers, but by no means always, is the use of memory for data structures. A nice big chunk of static memory will make a function fast, but I’ve seen many C routines malloc memory, do a st…

I'd certainly agree that malloc is the Achilles heel of any real world C. Overall though C++ was not a particularly good solution to memory efficiency since having OO available made the situation look like a fast sprint to the cake shop.

Heavy smalltalk-style OOP in C++ has kind of died out, especially with data structures. So with any templated data structure you’re reducing indirection from vtables and you have the opportunity to allocate however you want, often in continuous slabs to ease memory transfer and caching.

Re: Is Rust faster than C?

#246

Post by jesse__ »

ndesaulniers wrote: post #242
OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

> For instance, in C, qsort() takes a function pointer for the comparison function, in Rust and C++, the standard library sorting functions are templated on the comparison function. That's more of a critique of the standard libraries than the languages themselves. If someone were writing C and cared, they could provide their own implementation of sort such that the callback could be inlined (LLVM can inline indirect…

"could" and "should" are doing some very theoretical heavy lifting here.

Sure, at the limit, I agree with you, but in reality, relying on the compiler to do any optimization that you care about (such as inlining an indirect function call in a hot loop) is incredibly unwise. Invariably, in some cases it will fail, and it will fail silently. If you're writing performance critical code in any language, you give the compiler no choice in the matter, and do the optimization yourself.

I do generally agree that in the case of qsort, it's an API design flaw

Re: Is Rust faster than C?

#247

Post by jesse__ »

steveklabnik wrote: post #61
mid-kid wrote: post #54

I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…

I will admit the title was a bit of a gamble, but thank you for taking the time to read it and I'm glad that you enjoyed it in the end.

From the other side of the table, I love performance comparisons, so I always read these things. I also enjoyed your commentary, thanks for writing it :)

Re: Is Rust faster than C?

#248

Post by kibwen »

marcosdumay wrote: post #235
OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

> On the other hand, signed integer overflow being UB would count for C/C++ Rust defaults to the platform treatment of overflows. So it should only make any difference if the compiler is using it to optimize your code, what will most likely lead to unintended behavior.

Rust's overflow behavior isn't platform-dependent. By default, Rust panics on overflow when compiled in debug mode and wraps on overflow when compiled in release mode, and either behavior can be selected in either mode by a compiler flag. In neither case does Rust consider it UB for arithmetic operations to wrap.

Re: Is Rust faster than C?

#249

Post by tick_tock_tick »

OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

You're qsort example is basically the same reason people say C++ is faster than Rust. C++ templates are still a lot more powerful than Rusts systems but that's getting closer and closer every day.

Re: Is Rust faster than C?

#250

Post by kibwen »

esrauch wrote: post #64
torben-friis wrote: post #48

Earlier quoted context omitted.

Doesn’t rust have incremental builds to speed up debug compilation? How slow are we talking here?

People do have cold Rust compiles that can push up into measured in hours. Large crates often take design choices that are more compile time friendly shape. Note that C++ also has almost as large problem with compile times with large build fanouts including on templates, and it's not always realistic for incremental builds to solve either especially time burnt on linking, e.g. I believe Chromium development often use…

There's no Rust codebase that takes hours to compile cold unless 1) you're compiling a massive codebase in release mode with LTO enabled, in which case, you've asked for it, 2) you've ported Doom to the type system, or 3) you're compiling on a netbook.
Post reply on HN