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

281–290 of 546 posts

Re: Speed of Rust vs. C

#281

Post by adamnemecek »

Animats wrote: post #26

"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." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

I'm not sure how your architecture but you might not even need to lock things. I find that using mpsc channels allows me to get around like 60% of locking. Essentially, you have some sort of main loop, then you spawn a tread, load whatever you need there and then send it to the main thread over mpsc. The main thread handles it on the next iteration of the main loop.

Re: Speed of Rust vs. C

#283

Post by up2isomorphism »

My experience is that languages survives not because of a particular feature, but because they are USEFUL in practice to produce a software.

The fact that C is used in so many places speaks for itself about it usefulness. And this is done by writing software by majority of C programmers instead of jumping on every forum to attack other languages, writing extended blog posts just to convince people that they "should" switch to the language they like.

Also if you believe bounds check is the most difficult thing in software development, it just mean that you haven't dealt with a sufficient system yet or you just pretends to be.

The similar thing also applied to that if you think naively putting pthread_mutex_lock and unlock around the data structure is hard, it just means you haven't touched the scenarios that C programmers resorts to non-trivial locking mechanisms for.

Re: Speed of Rust vs. C

#284

Post by mplanchard »

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

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.

Re: Speed of Rust vs. C

#285

Post by pornel »

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, practical, idiomatic, but less-than-maximally optimized code, I don't think anyone would believe me that's a fair comparison. So I describe problems and patterns instead, and leave it to readers to judge how much applies to their problems and programming style.

Re: Speed of Rust vs. C

#286

Post by kibwen »

ragnese wrote: post #227
TazeTSchnitzel wrote: post #195

Earlier quoted context omitted.

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it. Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing. A very simple example: void foobar(struct foo *f) { f->a += 2; foo(); f->a += 2; b…

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

Re: Speed of Rust vs. C

#287

Post by burntsushi »

tsegratis wrote: post #279
burntsushi wrote: post #247

Earlier quoted context omitted.

No it's not. Its regex library is written in Rust, but was inspired by RE2. It shares no code with RE2. (And RE2 is a C++ library, not C.) Off the top of my head, the only C code in ripgrep is optional integration with PCRE2. In addition to whatever libc is being used on POSIX platforms. Everything else is pure Rust.

Ah, thanks burntsushi, I believe you are the ripgrep author even? Great work btw. Ripgrep is the best ... I will have to restrict my comment to just LLVM being a larger, c++, dependency ... Just angling for more downvotes ;) Thanks for the reply

To be clear, ripgrep has no runtime dependency on any LLVM or C++ library. rustc does.

Re: Speed of Rust vs. C

#288

Post by kimundi »

ragnese wrote: post #227
TazeTSchnitzel wrote: post #195

Earlier quoted context omitted.

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it. Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing. A very simple example: void foobar(struct foo *f) { f->a += 2; foo(); f->a += 2; b…

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

The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".

Re: Speed of Rust vs. C

#289

Post by nyanpasu64 »

Jweb_Guru wrote: post #254
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.

Code affected by unsafe already has to go through `UnsafeCell` which disables most aliasing optimizations, and the stacked borrow semantics have explicit opt-outs for such cases. I don't believe there are any Rust semantic issues standing in the way of exploiting aliasing information in this way, just LLVM bugs (and the fact that its restrict model isn't currently equipped to handle the information at such a fine gra…

There is undefined behavior in Rust affecting real-world code, including Tokio's scheduler, and code produced by async fn definitions. UnsafeCell doesn't solve the problem. There's more information at https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a....

Bug report at https://github.com/rust-lang/rust/issues/63818.

Reddit threads at (older) https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... and (newer) https://www.reddit.com/r/rust/comments/lxw6cl/update_to_llvm....

Somewhat related HN thread at https://news.ycombinator.com/item?id=26406989.

Re: Speed of Rust vs. C

#290

Post by up2isomorphism »

ben0x539 wrote: post #165
brwell wrote: post #91

> "Clever" memory use is frowned upon in Rust. In C, anything goes. No, it does not. If Rust programmers don't have discipline in C, other people have. And don't drag out some random CVE numbers again. These are about a fraction of existing C projects, many of them were started 1980-2000. It is an entirely different story if a project is started with sanitizers, Valgrind and best practices. I'm not against Rust, exce…

C evangelism is exhausting too. Maybe we can stick to discussing the merits of each language instead of complaining about how people with differing opinions make us feel.

Actually I never see any occasion that a C guys jump into a well establish project and ask them to rewrite that in C.

And TBH I rarely see other popular language did the similar things either, including very popular ones like python, Java or Go.

And you even observe there is thing called "C evangelism" actually exists?

Post reply on HN