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

381–390 of 402 posts

Re: Is Rust faster than C?

#381

Post by stonogo »

rtpg wrote: post #309
stonogo wrote: post #304

Earlier quoted context omitted.

Even just spawning a thread is going to make somebody complain that they can't build the code on their platform due to C11/pthread/openmp. This matches squarely with my experience, but it's not limited to threading, and Rust evades a large swath of these problems by relatively limited platform support. I look forward to the day I can run Rust wherever I run C!

While Rust doesn't have C coverage, it has (by my last check) better coverage than something like CPython currently does. The big thing though is Rust is honest about their tiers of support, whereas for many projects "supported platform" for minor platforms often mean "it still compiles (at least we think it does, when the maintainer tries it and it fails they will fix it)" Not to be too glib though, there are obviou…

All too common (not just with compilers) for someone to port the subset they care about and declare it done. Rust's decision to create standards of compliance and be conscious about which platforms are viable targets and which ones don't meet their needs is a completely valid way to ensure that whole classes of trouble never come. I think it's a completely valid approach, despite complaints from some.

Re: Is Rust faster than C?

#382

Post by tcfhgj »

johnisgood wrote: post #364
steveklabnik wrote: post #345

Earlier quoted context omitted.

When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust! (And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)

You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning. In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been broug…

The editors (and the desktop environment) are examples for apps with a GUI in Rust, to show people indeed create apps with GUIS in Rust, nothing else.

Re: Is Rust faster than C?

#383

Post by AlanLan »

voidUpdate wrote: post #65
philipallstar wrote: post #36

Earlier quoted context omitted.

This is like saying that no car is faster than any other because it depends what gear you drive it in

That's true as well. Language speed depends on how you use it

It’s a bit more fundamental than just "using it badly." The real tension lies in whether a language's safety invariants force a memory layout that is inherently at odds with the CPU cache hierarchy.

In low-latency systems, the true "tax" is often the loss of determinism. If I have to sacrifice a cache-friendly structure or introduce indirection just to satisfy a borrow checker's static analysis, the performance game is already lost, regardless of how "well" I use the language.

To give a concrete example: I previously built a high-frequency bridge for MT4 using a strict Modern C++ stack. I observed that after the initial warm-up, the working set actually settled from 13.6MB down to a stable 11.0MB and stayed there for a 7-day continuous stress test.

This 2.6MB drop was simply the OS reclaiming initialization overhead—a result of manual memory management (via custom pool allocators) preventing heap fragmentation from "pinning" that memory. You don't achieve that level of long-term residency stability by just "using a language well"; you get it by using a toolchain that allows you to treat the hardware as the ultimate source of truth.

Re: Is Rust faster than C?

#384

Post by morshu9001 »

Social factors mentioned there can make a big difference. I've seen plenty of C code choose safety over efficiency.

Our team writes a lot of C++ code for high-level stuff you'd normally do in say JS or Python. At the rate we make changes, we can't write very tight code. Strings and other structs end up getting copied needlessly due to ownership, like if something takes vector& and internally copies those strings into a map, we don't bother also making an external-owned version taking vector&. Or less efficient algorithms are used due to ease of safe implementation. Or there are fewer or less optimized libs available. Or it's a webserver and we have to throw threads at it instead of event loops.

The end result is C++ code that's slower than the equivalent Python code, dev time being equal.

Re: Is Rust faster than C?

#385

Post by morshu9001 »

kibwen wrote: post #38

I like to say that there are two primary factors when we talk about how "fast" a language is: 1. What costs does the language actively inject into a program? 2. What optimizations does the language facilitate? Most of the time, it's sufficient to just think about the first point. C and Rust are faster than Python and Javascript because the dynamic nature of the latter two requires implementations to inject runtime ch…

A lot of people think of static types as a safety feature, but the origin is performance. The assembly needs to know struct sizes ahead of time.

Re: Is Rust faster than C?

#386

Post by mrheosuper »

Mawr wrote: post #338
johnisgood wrote: post #321

Earlier quoted context omitted.

> He straight ported some C code to rust and found the rust code outperformed it by ~30% or something. The culprit ended up being that in C, he was using a hash table library he's been copy pasting between projects for years. In rust, he used BTreeMap from the standard library, which turns out to be much better optimized. Are you surprised? Rust is never inherently faster than C. When it appears faster, it boils down…

> When it appears faster, it boils down to library quality and algorithm choice, not the language. That's a thin, thin line of argumentation. The distinction between the ecosystem and language may as well not exist. A lot of improvements of modern languages come down to convenience, and the more convenient something is, the more likely it is to be used. So it is meaningful to say that the average Rust program will pe…

Then this is more like comparison between Cargo and whatever-C-using. If a project decided not to use cargo, then Rust would have the same problem.

I acknowledge that C needs a tool as good as cargo, but if we are comparing language, we should restrict to language.

Re: Is Rust faster than C?

#387

Post by esrauch »

estebank wrote: post #264
dwattttt wrote: post #259

Earlier quoted context omitted.

I'm curious if this is tracked or observed somewhere; crater runs are a huge source of information, metrics about the compilation time of crates would be quite interesting.

I know some large orgs have this data for internal projects. This page gives a very loose idea of how we're doing over time: https://perf.rust-lang.org/dashboard.html

Down and to the right is good, but the claim here is the average full release build is only 2 seconds?

Re: Is Rust faster than C?

#388

Post by kibwen »

esrauch wrote: post #387
estebank wrote: post #264

Earlier quoted context omitted.

I know some large orgs have this data for internal projects. This page gives a very loose idea of how we're doing over time: https://perf.rust-lang.org/dashboard.html

Down and to the right is good, but the claim here is the average full release build is only 2 seconds?

Those are graphs of averages from across the benchmarking suite, which you can read much more information about here: https://kobzol.github.io/rust/rustc/2023/08/18/rustc-benchma...

Re: Is Rust faster than C?

#389

Post by teo_zero »

bluGill wrote: post #8
gignico wrote: post #2

The article does not mention the possible additional optimisation opportunities that arise in Rust code due to stricter aliasing rules of references. But I don’t have an example in mind. Does anyone know of an example of it happening in real code?

Many C programs are vailid C++ and are faster when compiled with a C++ compiler because of those stricter aliasing and type rules. Like you though I have no examples.

Interesting concept! Any examples?

Re: Is Rust faster than C?

#390

Post by esjeon »

steveklabnik wrote: post #355
esjeon wrote: post #282

Theoretically, C is likely faster than Rust only by an unnoticeably small margin. Still, this is unavoidable because Rust works with abstraction that (1) adds overhead per-se albeit tiny (2) forces overhead in the design level. Practically, that little margin can be removed thru a series of engineering, as both are proper system-level programming languages, which offer tight control over the generated machine code. T…

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.

Post reply on HN