Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#351

Post by burntsushi » Sat, Mar 13, 2021, 6:17 PM UTC

pjmlp wrote: post #332

burntsushi wrote: post #223

Earlier quoted context omitted.

This is a bad take. ripgrep, to my knowledge, cannot be written in a higher level language without becoming a lot slower.[1] And yet, if I removed its use of parallelism by default, there will be a significantly degraded user experience by virtue of it being a lot slower. This isn't an "obsession." It's engineering. [1] - I make this claim loosely. Absence of evidence isn't evidence of absence and all that. But if I…

Python isn't really something I would even think as possible example, Common Lisp, D, Nim, Swift, most likely.

So? I said, "higher level language." I didn't say, "Python specifically."

I would guess D could do it.

I don't know enough about Nim or Swift.

I would learn something if Common Lisp did it. I'd also learn something if Haskell or Go did it.

Re: Speed of Rust vs. C

#352

Post by Tuna-Fish » Sat, Mar 13, 2021, 6:21 PM UTC

loeg wrote: post #343

Tuna-Fish wrote: post #156

Earlier quoted context omitted.

It's not that simple. While fully specializing everything wins microbenchmarks, as C++ has shown time and time again, it can easily lose performance in large applications. If fully specializing code saves a few branches in the hot loop, but also blows through all the L1i, it can easily be a huge net negative. > Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brillia…

> As someone who uses a lot of rust, they are sort of the red-headed stepchild. As a minimum to make the properly usable, we need a way of passing one object with multiple different traits. What do you mean? fn foo (x: T) { T.something(); }

Unless TraitB is an auto trait, that isn't currently valid?

From the reference:

> Trait objects are written as the optional keyword dyn followed by a set of trait bounds, but with the following restrictions on the trait bounds. All traits except the first trait must be auto traits, there may not be more than one lifetime, and opt-out bounds (e.g. ?Sized) are not allowed.

The only one of those restrictions that is acceptable to have is the single lifetime one. All the others are seriously restricting. The devs seem to agree, but work on this aspect of rust is very slow, and people are arguing on how to implement it. (I, for one, feel very strongly that dyn TraitA + TraitB should have a size of 3 pointers. That is, no magic combining vtables, just every added trait adds a new pointer to vtable.)

Re: Speed of Rust vs. C

#353

Post by Tuna-Fish » Sat, Mar 13, 2021, 6:21 PM UTC

zesterer wrote: post #243

Tuna-Fish wrote: post #156

Earlier quoted context omitted.

It's not that simple. While fully specializing everything wins microbenchmarks, as C++ has shown time and time again, it can easily lose performance in large applications. If fully specializing code saves a few branches in the hot loop, but also blows through all the L1i, it can easily be a huge net negative. > Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brillia…

> As a minimum to make the properly usable, we need a way of passing one object with multiple different traits. Supertraits?

That is possible, but gets really hairy if you use a lot of trait objects.

Re: Speed of Rust vs. C

#354

Post by dataangel » Sat, Mar 13, 2021, 6:27 PM UTC

kibwen wrote: post #286

ragnese wrote: post #227

Earlier quoted context omitted.

> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can. Can it, though? I keep hearing/reading FUD around both unsafe and Pin making it unlikely to ever be able to ubiquitously enable the noalias stuff.

You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan…

> The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees.

Are there issues I can subscribe to or RFCs for this?

Re: Speed of Rust vs. C

#355

Post by carols10cents » Sat, Mar 13, 2021, 6:29 PM UTC

tsegratis wrote: post #236

ben0x539 wrote: post #184

Earlier quoted context omitted.

ripgrep? :)

ripgrep is based on re2, a c library I would guess it contains more c than rust code... But what I love about this article is its lack of hype. It makes clear arguments both ways and all of them I can get behind Hype doesn't help Edit: To all my downvoters; I anticipated you :) With love and best wishes

Why would you guess about how much C or Rust code that ripgrep contains when you could very quickly look? https://github.com/BurntSushi/ripgrep

Re: Speed of Rust vs. C

#356

Post by bambam24 » Sat, Mar 13, 2021, 6:32 PM UTC

Rust is low-level enough that if necessary, it can be optimized for maximum performance just as well as C. Higher-level abstractions, easy memory management, and abundance of available libraries tend to make Rust programs have more code, do more, and if left unchecked, can add up to bloat. However, Rust programs also optimize quite well, sometimes better than C. While C is good for writing minimal code on byte-by-byte pointer-by-pointer level, Rust has powerful features for efficiently combining multiple functions or even whole libraries together.

But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C.

Re: Speed of Rust vs. C

#357

Post by hctaw » Sat, Mar 13, 2021, 6:36 PM UTC

gspr wrote: post #197

rectang wrote: post #18

Earlier quoted context omitted.

> ABI compatibility Rust provides ABI compatibility against its C ABI, and if you want you can dynamically link against that. What Rust eschews is the insane fragile ABI compatibility of C++, which is a huge pain to deal with as a user: https://community.kde.org/Policies/Binary_Compatibility_Issu... I don't think we'll ever see as comprehensive an ABI out of Rust as we get out of C++, because exposing that much incid…

Rust seems great to me, but aren't we losing a lot by giving up on C's dynamic linking and shared libraries?

Some would argue you gain more than you lose.

Also to be pedantic, C doesn't spec anything about linkage. Shared objects and how linkers use them to compose programs is a system detail more than a language one.

Re: Speed of Rust vs. C

#358

Post by cambalache » Sat, Mar 13, 2021, 6:38 PM UTC

nindalf wrote: post #264

planetis wrote: post #176

Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.

The problem is that most people criticising Rust don't make the case very well. If you want to read good critique, I'd recommend this - https://matklad.github.io/2020/09/20/why-not-rust.html . This post up-to-date, succinct and objective. And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shoul…

> And most pertinently, this critique was written by someone who genuinely loves programming in Rust.

That is putting the bar impossible high. I would expect most of the criticism to come from people who hate to program in Rust, which it is fine as long as the criticism is well argued.

Re: Speed of Rust vs. C

#359

Post by carols10cents » Sat, Mar 13, 2021, 6:43 PM UTC

dig1 wrote: post #256

ben0x539 wrote: post #162

Earlier quoted context omitted.

Any book you'd recommend to back up your claims?

"The C Programming Language" from K&R is something everyone should read, even if they are not fond of C. "Expert C Programming" [1]. Not up to date, but written from a C compiler writer standpoint. A lot of references to why C (and libs) are the way they are. [1] https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

How does K&R back up the claims you've made here?

Re: Speed of Rust vs. C

#360

Post by cwalv » Sat, Mar 13, 2021, 6:44 PM UTC

jandrewrogers wrote: post #17

rational_indian wrote: post #7

Earlier quoted context omitted.

> As an observation, performance optimized code is almost always effectively single-threaded these days, even when using all the cores on a CPU to very efficiently process workloads. Why? Edit: Thanks for all the replies. It seems this applies to data-parallel workloads only. I'd use a GPU for this. An RTX 3090 has around ~10000 CUDA cores (10000 simultaneous operations) v/s just ~10 for CPUs.

Data locality is everything for computational throughput. Having all data private to a single core is extraordinarily efficient compared to sharing data, and particularly mutable data, across cores. This creates a new problem: how do you balance load across cores? What if the workload is not evenly distributed across the data held by each core? Real workloads are like this! Fortunately, over the last decade, architec…

I'd like to learn more about the architectures and techniques developed over the last decade for this; can you recommend a few links or keywords to search?