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

121–130 of 546 posts

Re: Speed of Rust vs. C

#121

Post by maccard »

Galanwe wrote: post #108
snovv_crash wrote: post #82

Earlier quoted context omitted.

Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? Personally, I'd prefer to have a single binary that I start with some arguments, then need to also have a launch script, probably in a different language, which needs to coordinate all the starting, stopping, shared state etc. But, most of my work has been at the workstation…

> Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? That's true indeed, but I find it more manageable that way. To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary. A typical example that happens quite often is when you have some kind of producer/…

You can make exactly this argument the other way around:

If implemented with processes it becomes quite messy very fast. You end up with a bunch of processes that do whatever the hell they want, and need some complex orchestrator script to tell it how many processes you want, and need some notifications to the orchestrator to increase or decrease the number of workers

With threads, you can have a main thread that reads the socket and places messages in a shared queue, and if you want more/less workers you just spawn worker threads to read from the queue.

Re: Speed of Rust vs. C

#122

Post by skohan »

pharmakom wrote: post #87
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…

Rust makes building from source and cross compiling so easy that I don’t really care for dynamic linking in my use cases of Rust.

Dynamic linking is one thing I miss from Swift - I used dynamic linking for hot code reloading for several applications, which resulted in super fast and useful development loops. Given Rust's sometimes long compile times, this is something which would be welcome.

Re: Speed of Rust vs. C

#123

Post by p0nce »

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…

> I also wonder why corporations are pushing Rust.

Recruiting.

Re: Speed of Rust vs. C

#124

Post by pjmlp »

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…

While it works great for some cases, one should not forget it doesn't cover external resources, specially those shared across processes.

Re: Speed of Rust vs. C

#125

Post by pjmlp »

gridspy wrote: post #98
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…

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.

Re: Speed of Rust vs. C

#126

Post by anonymoushn »

AndyKelley wrote: post #66

> computed goto I did a deep dive into this topic lately when exploring whether to add a language feature to zig for this purpose. I found that, although finnicky, LLVM is able to generate the desired machine code if you give it a simple enough while loop continue expression[1]. So I think it's reasonable to not have a computed goto language feature. More details here, with lots of fun godbolt links: https://github.c…

Oh, that's great. I write interpreters off and on and I love Zig, so it's nice to hear I can get the best code gen while keeping the language small

Re: Speed of Rust vs. C

#127

Post by ShinTakuya »

rbanffy wrote: post #117
riquito wrote: post #92

Earlier quoted context omitted.

He tried with few effort and noticed that for his use case the code is faster, I fail to understand this rebuttal of the parent's comment

The average cellphone today has more than 4 cores. A decent desktop can deal with 16 threads on 8 cores. There is a lot of untapped parallelism readily available waiting for the right code.

It's not about number of available threads, the very act of scheduling tasks across multiple threads has scheduling and communication overheads, and in many situations actually ends up being slower than running it on the same thread.

That said, I think the original comment was rightly pointing out how easy it was to make the change and test it, which in this case did turn out to be noticeably faster.

Re: Speed of Rust vs. C

#129

Post by rocqua »

rbanffy wrote: post #115
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.

I used to say that wrt to memory leaks with Java and C++ and it remains true when comparing C and Rust: It's not that it's easier to write programs in [Java|Rust]. It's that it makes it much harder to write the bugs.

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.

Re: Speed of Rust vs. C

#130

Post by bumbada »

jandrewrogers wrote: post #3

As an observation, performance optimized code is almost always effectively single-threaded these days, even when using all the cores on a CPU to very efficiently process workloads. Given this, it is not clear to me that Rust actually buys much when it comes to parallel programming for the purposes of performance. Is there another reason to focus on parallelism aside from performance? This reminds me of when I use to…

It really depends of your definition of terms. What do you call "performance optimized"?

For example I consider glyph drawing as "performance optimized". It requires massive parallelism just to be able to display text smoothly in a high definition screen.

But most people will never see it, because they use a library that they call that does all the work for them and do not need to care about that.

The difference is tremendous. We are talking 100x more efficiency just using GPUs alone. You can get 1000x, 10.000x with hardware(electronic chip design) acceleration parallelism(increasing the cost and rigidity, and times to market too).

It is so big that it is a different level. It is not performance alone. It is that some things are so inefficient that are just not practical(like expending a million dollars in your energy bill in order to solve a problem).

Same happens with of course 3D, audio or video recognition. Sensor I/O. Artificial intelligence.

Rust lets you just prototype lots of code in a parallel way in the CPU, even for things that will run in a FPGA or ASIC in the future. It let's you transition smaller steps: CPU->GPU->FPGA->ASIC

Post reply on HN