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

311–320 of 402 posts

Re: Is Rust faster than C?

#311

Post by vlovich123 »

School-Cotton wrote: post #150
pizlonator wrote: post #146

It's not binary. If you try hard enough, I bet you can make an argument that C is faster and you can make an argument that Rust is faster. There is a set of programs that you can write in C and that are correct, that you cannot write in Rust without leaning into unsafe code. So if by "Rust" we mean "the safe subset of Rust", then this implies that there must be optimal algorithms that can be written in C but not in R…

> There is a set of programs that you can write in C and that are correct, that you cannot write in Rust without leaning into unsafe code. So if by "Rust" we mean "the safe subset of Rust" Well, unsafe rust is part of rust. So no, we don’t mean that.

If programs were primarily unsafe rust, no one would use the language. Unsafe rust is strictly more difficult to write than C in certain constructs because the complex invariants the rust language requires remain in unsafe, there’s just no compiler proof checking them being upheld.

Is argue that he’s right that generally it’s referring to safe subset and in practice people relax the conversation with a little unsafe being more ok. But as Steve points out it really depends on the definitions you choose.

Re: Is Rust faster than C?

#312

Post by atoav »

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…

There was a contest for which language the fastest tokenizer could be written in. I entered my naive 15 minutes Rust version and got second place among roughly 30 entries. First place was hand-crafted assembly.

I am not saying Rust is faster always. But it can be a damn performant language even if you don't think about performance too deeply or don't twist yourself into bretzels to write performant code.

And in my book that counts for something. Because yes, I want my code to be performant, but I'd also not have it blow up on edge cases, have a way to express limitations (like a type system) and have it testable. Rust is pretty good even if you ignore the hype. I write audio DSP code on embedded devices with a strict deadline in C++. I plan to explore Rust for this, especially now since more and more embedded devices start to have more than one processor core.

Re: Is Rust faster than C?

#313

Post by cyberax »

pjmlp wrote: post #303
cyberax wrote: post #283

Earlier quoted context omitted.

You can debug release builds with gcc/clang just fine. They don't generate debug information by default, but you can always request it ("-O3 -g" is a perfectly fine combination of flags).

Not really, because some optimizations get the step through and such rather confusing. VC++ dynamic debugging pretends the code motion, inlining and similar optimizations aren't there and maps back to the original code as written. Unless this has been improved for gdb,lldb.

Ah, I see what you mean.

GCC can now emit information that can be used to reconstruct the frame pointers for inlined functions: https://lwn.net/Articles/940686/ It's now filtering through various projects: https://sourceware.org/binutils/wiki/sframe

It will not undo _all_ the transformations, but it will help a lot. I used it for backtraces, and it fixed the missing frame issues for me.

This was possible with the earlier DWARF format (it's Turing-complete), and I think this is how VCC does it. Although I have not checked it.

Re: Is Rust faster than C?

#314

Post by beng-nl »

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…

This is a tangent, because it clearly didn’t pan out, but I had hope for rust having an edge when I learned about how all objects are known to be immutable or not. This means all the mutable objects can be held together, as well as the immutable, and we’d have more efficient use of the cache: memory writes to mutable objects share the cache with other mutable objects, not immutable Objects, and the bandwidth isn’t wasted on writing back bytes of immutable objects that will never change.

As I don’t see any reason rust would be limited in runtime execution compared to c, I was hoping for this proving an edge.

Apparently not a big of an effect as I hoped.

Re: Is Rust faster than C?

#315

Post by dochtman »

pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

I think the way Rust checks borrows also makes it a lot more feasible to avoid allocations/copies; not because it is impossible to do in C, but because doing it in C requires writing very careful documentation and the caller to actually read that documentation. In (safe) Rust this is all checked by the compiler such that libraries can leverage it without blowing their complexity budget.

Re: Is Rust faster than C?

#316

Post by kazinator »

kouteiheika wrote: post #97
OptionOfT wrote: post #88

Earlier quoted context omitted.

Apart from multi threading, there is more information in the Rust type system. Would that would allow more optimizations?

Yes. All `&mut` references in Rust are equivalent to C's `restrict` qualified pointers. In the past I measured a ~15% real world performance improvement in one of my projects due to this (rustc has/had a flag where you can turn this on/off; it was disabled by default for quite some time due to codegen bugs in LLVM).

But of course the only thing restrict does in C is potentially introduce certain kinds of undefined behavior into a program that would be correct without it (and then things can be optimized on the assumption that the code is not invoked in a way that it would happen)

Re: Is Rust faster than C?

#317

Post by dwattttt »

oguz-ismail2 wrote: post #300
dwattttt wrote: post #294

Earlier quoted context omitted.

Optimising out TLS isn't going to be a good example of compiler capability. Whether another thread exists is a global property of a process, and beyond that the system that process operates in. The compiler isn't going to know for instance that an LD_PRELOAD variable won't be set that would create a thread.

> Whether another thread exists is a global property of a process, and beyond that the system that process operates in. TLS is a language feature. Whether another thread exists doesn't mean it has to use the same facilities as the main program. > The compiler isn't going to know for instance that an LD_PRELOAD variable won't be set that would create a thread. Say the program is not dynamically linked. Still no?

> Say the program is not dynamically linked. Still no?

Whether the program has dynamic dependencies does not dictate whether a thread can be created, that's a property of the OS. Windows has CreateRemoteThread, and I'd be shocked if similar capabilities didn't exist elsewhere.

If I mark something as thread-local, I want it to be thread-local.

Re: Is Rust faster than C?

#318

Post by kazinator »

dmitrygr wrote: post #274
kouteiheika wrote: post #97

Earlier quoted context omitted.

Yes. All `&mut` references in Rust are equivalent to C's `restrict` qualified pointers. In the past I measured a ~15% real world performance improvement in one of my projects due to this (rustc has/had a flag where you can turn this on/off; it was disabled by default for quite some time due to codegen bugs in LLVM).

Do you not use restrict in your normal everyday C code that you write? I use it in my normal C code.

restrict works by making some situations undefined behavior that would otherwise be defined without it. It is probably unwise to use casually or habitually.

Re: Is Rust faster than C?

#319

Post by simonask »

usrnm wrote: post #308
oconnor663 wrote: post #281

Earlier quoted context omitted.

> Despite benefits, I don't actually think the memory safety really plays a role in the usage rate of parallelism. I can see what you mean with explicit things like thread::spawn, but I think Tokio is a major exception. Multithreaded by default seems like it would be an insane choice without all the safety machinery. But we have the machinery, so instead most of the async ecosystem is automatically multithreaded, and…

> Multithreaded by default seems like it would be an insane choice without all the safety machinery You're describing golang, and somehow it's fine. Bugs are possible, but not super common

Isn't that "somehow" super attributable to the fact that Go is garbage collected?

Garbage collection is the one other known way to achieve memory safety.

Re: Is Rust faster than C?

#320

Post by coldtea »

mandw wrote: post #277
josephg wrote: post #267

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 really liked this article by Bryan Cantrill from 2018: https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... 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 co…

The only real question I have with this is did the program have to have any specific performance metric? I could write a small utility in python that would be completely acceptable for use but at the same time be 15x slower than an implementation in another language. So you do you compare code across languages that were not written for performance given one may have some set of functions that happens to favour one la…

>If he needed his app to be 30% faster he would have made it so

That still validates "In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code" the parent wrote

Post reply on HN