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

161–170 of 546 posts

Re: Speed of Rust vs. C

#161

Post by ben0x539 »

mratsim wrote: post #150

> There are other kinds of concurrency bugs, such as poor use of locking primitives causing higher-level logical race conditions or deadlocks, and Rust can't eliminate them, but they're usually easier to diagnose and fix. Which is why so many people are creating formal verification languages and spending years in research to fix those ... That just isn't true. It's a very complex problem that is an issue in both hard…

Rust may or may not help you write synchronization primitives safely, but it for sure helps you use synchronization primitives without having to worry about memory safety. If you aren't parallelizing particularly subtle shenanigans, that's plenty for fearlessness.

Re: Speed of Rust vs. C

#162

Post by ben0x539 »

dig1 wrote: post #142

> For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). You can do that in Java (with byte arrays) or in Common Lisp, so what is the point here? It is not practice in Java, Lisp nor in C and C++. > It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)allocation of growing buffers This is becau…

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

Re: Speed of Rust vs. C

#163

Post by mcherm »

scorpion95 wrote: post #112
bsder wrote: post #110

Earlier quoted context omitted.

> Code converted from C to Rust seems much more voluminous. This is a fairly odd claim. If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose. If you need a data structure more complex than an array of something, C is stupidly verbose. If you want to deal with pattern matching/regexen, C is ridiculously verbose. Do I agree that Rust is far more verbose for an embedded "blinky" (the embedd…

When I converted code from C to Rust, I was left with much more code. Are you just noting specifics, or was it your experience that there was less Rust required for a full C to Rust conversion?

Did you ever take a look to try and figure out where the extra verboseness came from? For instance, was it spread equally across all functions or concentrated in those doing numeric computations (or whatever)? It would be interesting to learn something from this example.

Re: Speed of Rust vs. C

#164

Post by ben0x539 »

12thwonder wrote: post #134

I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size. am I a minority having this opinion?

I don't know if you are a minority, but Rust is available right now and C-but-with-Rust's-great-ideas isn't. As far as I know no one is working on C-but-with-Rust's-great-ideas, so I don't think it's a good strategy to wait around for it instead of using the tools that exist and are already used with great impact.

Re: Speed of Rust vs. C

#165

Post by ben0x539 »

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.

Re: Speed of Rust vs. C

#166

Post by brink »

phkahler wrote: post #153
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…

>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?

The simplest (and often best) option is to use the Arc> pattern.

The Arc is an async reference counter that allows multiple ownership. And the nested Mutex enforces only one mutable borrow at a time.

Re: Speed of Rust vs. C

#167

Post by ben0x539 »

phkahler wrote: post #153
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…

>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?

Eh, with Arc you can share ownership easily, and there are probably a lot of cleverer concurrent data structures or entity component kinda things that'd just work too. But maybe you can arrange things so that one thread owns the scene but the other thread can still do useful work?

Re: Speed of Rust vs. C

#168

Post by simias »

I completely agree with the points made here, it matches my experience as a C coder who went all-in on Rust.

>"Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED).

Ha!

>It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)allocation of growing buffers. Idiomatic Rust still gives a lot control over memory allocation, and can do basics like memory pools, combining multiple allocations into one, preallocating space, etc., but in general it steers users towards "boring" use or memory.

Since I write a lot of memory-constrained embedded code this actually annoyed me a bit with Rust, but then I discovered the smallvec crate: https://docs.rs/smallvec/1.5.0/smallvec/

Basically with it you can give your vectors a static (not on the heap) size, and it will automatically reallocate on the heap if it grows beyond that bound. It's the best of both world in my opinion: it lets you remove a whole lot of small useless allocs but you still have all the convenience and API of a normal Vec. It might also help slightly with performance by removing useless indirections.

Unfortunately this doesn't help with Strings since they're a distinct type. There is a smallstring crate which uses the same optimization technique but it hasn't been updated in 4 years so I haven't dared use it.

Re: Speed of Rust vs. C

#169

Post by simias »

pjmlp wrote: post #125
gridspy wrote: post #98

Earlier quoted context omitted.

The very short version: There are many things which cause both frequent and rare strange crashes in multi-threaded code. In C, all these things will compile OK. In safe Rust, practically none of them will compile. It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.

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

Rust has the expressive power to design an API that explicitly makes it impossible if you so desire though. For instance by using an API similar to mutexes where you have to lock to access the contents.

Re: Speed of Rust vs. C

#170

Post by ben0x539 »

JohnStrangeII wrote: post #135
rocqua wrote: post #129

Earlier quoted context omitted.

Yesterday I upgraded an entire code-base from C to C++ just because it was faster than writing my own dynamically resizing array in C. Writing programs in C is harder just because there are essentially no containers in the stdlib.

Aren't there good container libraries for C?

There are a lot of great libraries for sure, but they aren't in the stdlib and C doesn't make it as easy to use external libraries as languages with modern tooling. Everybody gets grumpy about dependencies and a lot of people probably figure it's easier to maintain their own container code in their application than to deal with that.
Post reply on HN