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

301–310 of 546 posts

Re: Speed of Rust vs. C

#301

Post by morty_s »

burntsushi wrote: post #251
amelius wrote: post #248

Earlier quoted context omitted.

> which means you use it in its compressed form without decompressing it first. So your code operates directly on a block of raw bytes? I can see how that can work with mmap without much problems. My argument was more about structured data (created using the type system), which is a level higher than raw bytes.

> So your code operates directly on a block of raw bytes? I can see how that can work with mmap without much problems. Correct. It's a finite state machine. The docs of the crate give links to papers if you want to drill down. > My argument was more about structured data (created using the type system), which is a level higher than raw bytes. Yes. You should be able to do in Rust whatever you would do in C. You can t…

Dang, burntsushi up in the house! Hey, just wanted to say I enjoy your work––I've learned a lot from it. Thank you!

Re: Speed of Rust vs. C

#302

Post by junippor »

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.

Not parent, but to me this one stood out.

https://news.ycombinator.com/item?id=26445167

Re: Speed of Rust vs. C

#303

Post by zelphirkalt »

bluejekyll wrote: post #154
pjmlp wrote: post #147

Earlier quoted context omitted.

Fearless concurrency sales pitch. Yes languages like Erlang and runtimes like Coyote and Orleans.

Erlang has a great concurrency model with higher overhead than Rust, but similar cross thread safety, doesn’t do anything about exterior resources to the application. I’ve not worked with Coyote, but if it is the system for .net, it describes itself as a framework, “Coyote provides developers a programming framework for confidently building reliable asynchronous software on the .NET platform”. Orleans similarly descr…

If I understand correctly, the Erlang point was, that you can have a distributed system by using Beam to scale to multiple machines and have them communicate via message passing, which is all possible and encouraged, because of how you structure and write code in Erlang, as actors with mailboxes, isolating actors from each other, except for the messages, that are passed.

You say, that the Erlang concurrency model has higher overhead than Rust. In Rust there are probably multiple projects going on right now (one of them is Bastion, but I guess there are probably others), which try to provide Erlang like concurrency. What do you mean by overhead of a concurrency model (that of Erlang) being higher than the overhead a programming language (Rust)? As far as I know Erlang's lightweight processes are about as lightweight as you can get. Is there a Rust framework for Erlang like concurrency, which reduces the footprint of lightweight processes even more?

Re: Speed of Rust vs. C

#304

Post by pornel »

up2isomorphism wrote: post #293

The article talks way too high level and is written like a marketing people even the title sounds technical, for example: "Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."

But this is true. I mean specifically about Send and Sync traits that have to be implemented on types for the compiler to allow them in multi-threaded constructs, like `thread::spawn` or Rayon's parallel iterators.

If you write a library, and use e.g. thread-unsafe `Rc` or not-sure-if-safe raw pointers anywhere in your structs, the compiler will stop me from using your library in my threaded code.

This is based on a real experience. I've written a single threaded batch-processing code, and then tried to make it parallel. The compiler told me that I used a GitHub client, which used an HTTP client, which used an I/O runtime, which in this configuration stored shared state in an object without a Mutex. Rust pointed out exactly the field in 3rd party code that would cause a data race. At compile time.

Re: Speed of Rust vs. C

#305

Post by howinteresting »

andrepd wrote: post #257
pdimitar wrote: post #201

Earlier quoted context omitted.

Lately on another Rust thread somebody pointed out that C programs use a lot of indirection like pointers and vtable dispatches which actually detracts from the supposed mega-speed of the low-level C. I found that to be mind-blowing and felt stupid for not remembering that earlier.

I don't think vtables are often used in C.

Dynamic dispatch (vtables are one way to do it, and so is a function pointer) is incredibly common in C, because there's no language-built-in way to perform monomorphization.

Re: Speed of Rust vs. C

#306

Post by masklinn »

cygx wrote: post #214
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…

That's what restrict is for: void foobar(struct foo *restrict f) { ... }

And just like that we're back to

> There's a significant difference between what these languages can achieve in theory, and how they're used in practice.

Theoretically in C you can use restrict for this. Practically nobody does (rust users keep finding bugs and miscompilation in LLVM's noalias support), and it's a huge footgun because you're completely on your own and all bets are off if you misuse it.

Meanwhile in rust land, it's the default and the compiler checks your homework, and while you can always lie to the compiler it's much rarer that you'd even get in a position to do so.

Re: Speed of Rust vs. C

#307

Post by trunnell »

pjmlp wrote: post #146
bluejekyll wrote: post #137

Earlier quoted context omitted.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need t…

Indeed, but the fearless concurrency sales pitch tends to overlook that.

It’s hard to see how you could be arguing in good faith given that your point of “fearless concurrency” being an overstated “sales pitch” has now been answered with multiple substantive answers.

Please stop moving the goal posts from “program concurrency” to “distributed or multi-process transactions.” It subtracts from the conversation.

Rust is honest about what it does and doesn’t do.

Re: Speed of Rust vs. C

#308

Post by masklinn »

bluejekyll wrote: post #137
pjmlp wrote: post #125

Earlier quoted context omitted.

Accessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need t…

> Rust won’t prevent all manner of bugs

Nit: rust will prevent all manner of bugs. Rust won't prevent every manner of bugs.

Re: Speed of Rust vs. C

#309

Post by tsegratis »

burntsushi wrote: post #287
tsegratis wrote: post #279

Earlier quoted context omitted.

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.

The interesting thing here is that rust has good threading and fantastic crates

I played with making a regex library in rust. Which, as per RE2 design involves constructing graphs and glueing them together as the regex is traversed

This requires a cycle catching gc, or, just a preallocated arena... It was my first foray into rust and felt I would need to be hitting into unsafe, which I wasn't ready for. Array indexing might decompose into an arena, but syntactically just a bit messier (imho)

Would be interesting to see how the RE2 does it in rust (didn't know that)

I like how the article shows both sides of the fence, it makes me realize:

I get a lot of optimizations from ptr stuffing in c. But sometimes we should lay down the good, for the better

Re: Speed of Rust vs. C

#310

Post by Jweb_Guru »

nyanpasu64 wrote: post #289
Jweb_Guru wrote: post #254

Earlier quoted context omitted.

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

This is the `Pin` example which I'm not that familiar with but was aware of. I think it's highly unlikely that this one, relatively niche use case is going to prevent Rust from ever being able to safely turn on aliasing optimizations. There have been several solutions proposed, e.g. adding a stricter UnsafeCell to the language; they may technically not be backwards-compatible, but given how `Pin` is used and the fact that this is a soundness issue, I think it should be fine.

The HN thread is mostly unrelated. I agree that it would have been better to integrate `Pin` directly into the language, though, but mostly for ergonomic reasons; it could still probably happen in an edition upgrade.

Post reply on HN