Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

321–330 of 546 posts

Re: Speed of Rust vs. C

#321

Post by tsegratis »

mplanchard wrote: post #284
tsegratis wrote: post #236

Earlier quoted context omitted.

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

I don’t think people are downvoting you because they disagree on a matter of opinion. You’ve literally got the author of ripgrep having replied to you to tell you that what you’ve said is categorically false.

I anticipated my own falsity. I'm aware and at home with it

Re: Speed of Rust vs. C

#322

Post by jblow »

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster.

There is this habit in both academia and industry where people say "as fast as C" and justify this by comparing to a tremendously slow C program, but don't even know they are doing it. It's the blind leading the blind.

The question you should be asking yourself is, "If all these claims I keep seeing about X being as fast as Y are true, then why does software keep getting slower over time?"

(If you don't get what I am saying here, it might help to know that performance programmers consider malloc to be tremendously slow and don't use it except at startup or in cases when it is amortized by a factor of 1000 or more).

Re: Speed of Rust vs. C

#323

Post by pornel »

kazinator wrote: post #275
moonchild wrote: post #13

> C libraries typically return opaque pointers to their data structures, to hide implementation details and ensure there's only one copy of each instance of the struct. This costs heap allocations and pointer indirections. Rust's built-in privacy, unique ownership rules, and coding conventions let libraries expose their objects by value The primary reason c libraries do this is not for safety, but to maintain ABI com…

> This costs heap allocations and pointer indirections. Heap allocations, yes; pointer indirections no. A structure is referenced by pointer no matter what. Remember that the stack is accessed via a stack pointer . The performance cost is that there are no inline functions for a truly opaque type; everything goes through a function call. Indirect access through functions is the cost, which is worse than a mere pointe…

Escape analysis is tough in C, and data returned by pointer may be pessimistically assumed to have escaped, forcing exact memory accesses. OTOH on-stack struct is more likely to get fields optimized as if they were local variables. Plus x86 has special treatment for the stack, treating it almost like a register file.

Sure, there are libraries which have `init(&struct, sizeof(struct))`. This adds extra ABI fragility, and doesn't hide fields unless the lib maintains two versions of a struct. Some libraries that started with such ABI end up adding extra fields behind internal indirection instead of breaking the ABI. This is of course all solvable, and there's no hard limit for C there. But different concerns nudge users towards different solutions. Rust doesn't have a stable ABI, so the laziest good way is to return by value and hope the constructor gets inlined. In C the solution that is both accepted as a decent practice and also the laziest is to return malloced opaque struct.

Re: Speed of Rust vs. C

#324

Post by ameliaquining »

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…

Source? I would like this to be true, but I haven't actually seen it anywhere.

Re: Speed of Rust vs. C

#325

Post by howinteresting »

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.

Bothsidesism is unhelpful in technical discussions just as much as in politics. If you have specific critiques please share them.

I have a number of specific critiques of Rust, chief being that APIs and implementations are bound too tightly. &[String] and &[&str] are logically similar but changing from one to the other in your implementation might mean a breaking API change.

Re: Speed of Rust vs. C

#326

Post by supergarfield »

loeg wrote: post #278
rcxdude wrote: post #131

Earlier quoted context omitted.

True of the more common ones, but it should be acknowledged that OpenBSD was doing this kind of thing (and many other hardening techniques) before heartbleed, which was the main reason Theo de Raadt was so upset that they decided to circumvent this, because OpenBSD's allocator could have mitigated the impact otherwise.

Even higher-performance mallocs like jemalloc had heap debugging features (poisoning freed memory) before Heartbleed, which -- if enabled -- would catch use-after-frees, so long as libraries and applications didn't circumvent malloc like OpenSSL did (and Python still does AFAIK).

> and Python still does AFAIK

Don't you sort of have to do that if you're writing your own garbage collector, though? I guess for a simple collector you could maintain lists of allocated objects separately, but precisely controlling where the memory is allocated is important for any kind of performant implementation.

Re: Speed of Rust vs. C

#327

Post by drchickensalad »

bakatubas wrote: post #239
bluejekyll wrote: post #198

Earlier quoted context omitted.

It doesn’t say it “works badly” it says the borrow checker can’t protect against external modifications to the file while memory-mapped, which has a host of issues in C as well. You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.

I don’t get this obsession with “dangerous.” Honestly, what does that even mean? I think a better word is “error-prone.” Danger is more like, “oh my god a crocodile!”

Errors are up to interpretation. It just means the thing didn't happen as requested. Errors are meant to be expected or not expected depending on the context.

Dangerous means dangerous. It's not up for interpretation.

Languages have multiple, very different words, for exactly this reason.

Re: Speed of Rust vs. C

#328

Post by howinteresting »

hsaliak wrote: post #296

For parallelism, Modern tooling like TSAN can close the gap somewhat. If you are planning to introduce threads, not testing it with TSAN is silly at best.

If you're writing safe, parallel Rust code, you don't really need to use TSAN. You may hit a deadlock sometimes, but those tend to be easy to figure out in my experience.

The people implementing the libraries you use (e.g. Rayon) may have to use TSAN, of course.

Re: Speed of Rust vs. C

#329

Post by pjmlp »

eru wrote: post #175
anfilt wrote: post #118

Earlier quoted context omitted.

Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are n…

> Some people even feel C++ keeps adding too many new features too fast. It's not so much that they keep adding features, but that they (almost?) never remove any.

Python 3 has shown the world what happens when that is done without bringing the ecosystem along.

Re: Speed of Rust vs. C

#330

Post by howinteresting »

pornel wrote: post #285
ReactiveJelly wrote: post #225

I'm a Rust evangelist, but the article is titled "Speed of Rust vs. C" and doesn't seem to contain even one benchmark. For fuck's sake.

There's already The Benchmarks Game and ixy-languages if you want hard numbers. Maximum speeds are already explored. I wanted to discuss an aspect that's not typically covered by pure benchmarks: what can you expect from normal day-to-day use of these languages. Not fine-tuned hot loops, but a "median" you can expect when you just need to get shit done. If I tried to write a benchmark code to represent average, pract…

Thank you for writing this. Real world, qualitative experience reports are vital.

My experience using Rust vs C aligns with yours as well.

Post reply on HN