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

201–210 of 546 posts

Re: Speed of Rust vs. C

#201

Post by pdimitar »

TazeTSchnitzel wrote: post #195
scorpion95 wrote: post #90

Earlier quoted context omitted.

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

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…

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.

Re: Speed of Rust vs. C

#202

Post by amelius »

bluejekyll wrote: post #198
amelius wrote: post #194

Earlier quoted context omitted.

But Rust works badly with mmapped (memory-mapped) files, as the article notes. So in C you could load (and save!) stuff almost instantly, whereas in Rust you still have to de-serialize the input stream.

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.

But that may be of little solace. If you snapshot your entire heap into an mmapped file for fast I/O, then basically the entire advantage of Rust is gone.

Re: Speed of Rust vs. C

#203

Post by planetis »

ben0x539 wrote: post #192
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.

Hm, is there some specific criticism of Rust you'd like to see discussed more? It's easy to get side-tracked in these "actually my language is better than your language" with everybody launching whole broadsides of arguments, so I wouldn't be surprised if some more subtle points get lost.

eh, I don't partake in the usual "actually my language is better than your language" that comes up in all posts. I just don't like people going overboard with their claims, when they try to promote any PL really, and would appreciate more fact checking.

Re: Speed of Rust vs. C

#204

Post by Const-me »

jandrewrogers wrote: post #49
andi999 wrote: post #35

Earlier quoted context omitted.

Thanks. What is latency hiding?

There are many operations on data that are relatively slow from a CPU’s perspective — filling a cache line, page faulting, cache coherency, acquiring a lock, waiting on I/O to complete, etc. All of these add latency by stalling execution. In conventional software, when these events occur you simply stall execution, possibly triggering a context switch (which is very expensive). In many types of modern systems, these…

> There are exotic CPU architectures explicitly designed for latency hiding, mostly used in supercomputing.

I don’t know much about supercomputers, but what you described is precisely how all modern GPUs deal with VRAM latency. Each core runs multiple threads, the count is bound by resources used: the more registers and group shared memory a shader uses, the less threads of the shader can be scheduled on the same core. The GPU then switches threads instead of waiting for that latency.

That’s how GPUs can saturate their RAM bandwidth, which exceeds 500 GB/second in modern high-end GPUs.

Re: Speed of Rust vs. C

#205

Post by spacechild1 »

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

I'd like to point out that this is not always the case. Some libraries, especially those with embedded systems in mind, allow you to provide your own memory buffer (which might live on the stack), where the object should be constructed. Others allow you to pass your own allocator.

Re: Speed of Rust vs. C

#206

Post by smt1 »

scorpion95 wrote: post #90
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…

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

> Code converted from C to Rust seems much more voluminous.

I haven't seen that in practice. A good point of reference are implementations of things like ruby, python, or the erlang vm in rust compared to the C alternatives. This might be because Rust is also more expressive (probably by borrowing certain syntax/semantics from ocaml/haskell), though the borrow checker does add back some verbosity.

Re: Speed of Rust vs. C

#207

Post by Shadonototro »

jmacjmac wrote: post #188
ackxolotl wrote: post #128

We've implemented network drivers in C and Rust and did a performance comparison. Interestingly, the C-to-Rust-transpiled code ended up being faster than the original C implementation: https://github.com/ixy-languages/ixy-languages/blob/master/R...

https://github.com/emmericp/ixy/blob/0e00605be4153b06df06184... Looks like you're compiling C code with -O2. Does Rust build set -O3 on clang? Did you try -O3 with C? I know it's not guaranteed to be faster, just curious.

Good catch

Re: Speed of Rust vs. C

#208

Post by smt1 »

scorpion95 wrote: post #106
Lvl999Noob wrote: post #96

Earlier quoted context omitted.

The author did say that there is nothing that Rust does that C cannot. The difference is that in Rust, those things are easier, or many times, the default way, while in C, you would have to take care of way too many things to make sure things work.

Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…

servo is written in rust, not firefox. The firefox codebase is quite old, while servo was written from scratch, being the first new web codebase in years.

Re: Speed of Rust vs. C

#209

Post by hderms »

scorpion95 wrote: post #106
Lvl999Noob wrote: post #96

Earlier quoted context omitted.

The author did say that there is nothing that Rust does that C cannot. The difference is that in Rust, those things are easier, or many times, the default way, while in C, you would have to take care of way too many things to make sure things work.

Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…

As someone who's worked predominantly in high level languages (Scala, Ruby, etc...) I've found Rust to be relatively straightforward to use for simple CLI tools or gRPC servers (tonic library is pretty nice). I haven't tried building a CRUD app yet, but I don't see any real reason why it would be impossible to have an ergonomic web framework in Rust.

The things I find most difficult: 1. Wrangling with the borrow checker can be painful before you know what you're doing (and even afterwards) but if you understand the standard library/patterns well, it seems to minimize the cost. Example being trying to write your own `get_or_else_insert` style method for a HashMap. Writing your own version is easy in other languages but hard in Rust. If you didn't know that methods like that already exist on HashMap you will experience a lot of pain until you understand the "right" way to do something.

2. Shared memory concurrency is definitely at the nexus of all the more difficult parts of Rust. Especially with async/await. There's no question in my mind that if you want to write a webserver that has async functions accessing shared memory, that you will for sure need to fill in any gaps in your knowledge as it will be difficult to get to a working program without understanding significantly more concepts than what it might take for a simple single-threaded CLI app

I'm pretty sure that it will be possible (if it isn't already) to get the Rust ecosystem to a state where writing a CRUD app is about as simple as in Go (and considerably easier/more ergonomic w.r.t certain things like JSON serialization).

Post reply on HN