Is Rust faster than C?

401–402 of 402 posts

Re: Is Rust faster than C?

#401

Post by arghwhat » Sat, Jan 17, 2026, 11:04 PM UTC

bcantrill wrote: post #395

arghwhat wrote: post #392

Earlier quoted context omitted.

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

> I don't often do this

You should have practiced better restraint then, as this was not a productive addition to the discussion.

My experience disagrees with your opinion and I see no value in engaging further.

Re: Is Rust faster than C?

#402

Post by repstosb » Sun, Jan 18, 2026, 12:06 PM UTC

bennettnate5 wrote: post #358

throwaway2037 wrote: post #329

Earlier quoted context omitted.

> 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?

The simplest example is `memcpy(dst, src, len)` and similar iterative byte copying operations. If the function did not use noalias, the compiler wouldn't be free to optimize individual byte read/writes into register-sized writes, as the destination may overlap with the source. In practice this means 8x more CPU instructions per copy operation on a 64-bit machine. Note that memcpy specifically may already be implement…

That's not a great example, since memcpy() already has all the information it needs to determine whether the regions overlap (src The real purpose of restrict is to allow the compiler to cache a value that may be used many times in a loop (in memcpy(), each byte/word is used only once) in a register at the start of the loop, and not have to worry about repeatedly reaching back to memory to re-retrieve it because it might have been modified as a side effect of the loop body.

Post reply on HN