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

181–190 of 546 posts

Re: Speed of Rust vs. C

#181

Post by _vvhw »

_ph_ wrote: post #73
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…

When we talk about support for threading/concurrent programming in programming languages, it is less about how to reach the theoretical limits of your system best, especially if you are free to architect the whole software stack towards that goal. In that case, your statements might apply. It is about how easily a programmer, who deals with a certain subtask in a system, can utilize more cores for the this task. Not…

You are not factoring in the cost of context switches, and that many user applications today are memory-bound and not CPU-bound.

It's one of the secrets exploited by the M1 chip, seen in how many more cache lines the CPU's LFB can fill concurrently compared to Intel chips and that these are now 128 byte cache lines instead of 64 byte cache lines.

Re: Speed of Rust vs. C

#182

Post by skohan »

> Both are "portable assemblers"

I don't tend to think of Rust as "portable assembly", and this is indeed one of the points where I think it differs the most from C. I think of "portable assembly" as being applicable to C, because it is some version of a "minimal" level of abstraction for a high-level language. Rust is very much a tool for abstraction, and one of the USPs of rust is that the compiler abstracts away the low-level details of memory management in a way which is not as costly as other automatic memory management strategies.

Maybe it's due to lack of experience, but with C code it's fairly easy to look at a block of code and imagine approximately which assembly would be generated. With highly abstract Rust code, like with template-heavy C++ code, I don't feel like that at all.

Re: Speed of Rust vs. C

#183

Post by celeritascelery »

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…

Really cool investigation. I wonder if this applies to rust as well.

As you said though, this is finicky, and if you need this optimization for performance then you don’t want to rely on compiler heuristics.

Re: Speed of Rust vs. C

#184

Post by ben0x539 »

eru wrote: post #180
alerighi wrote: post #144

Earlier quoted context omitted.

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

> In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simplicity and solidity using a single thread is really fine. Depends on which of the classic utilities you are talking about. Many of them are typically IO bound. You might not get much out of throwing more CPU at them.

ripgrep? :)

Re: Speed of Rust vs. C

#185

Post by jdright »

skohan wrote: post #122
pharmakom wrote: post #87

Earlier quoted context omitted.

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.

There are crates for hot reloading in Rust, and they use dynamic linking.

Re: Speed of Rust vs. C

#186

Post by eru »

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…

Somewhat off-topic: I just looked into zig, because you mentioned it.

> C++, D, and Go have throw/catch exceptions, so foo() might throw an exception, and prevent bar() from being called. (Of course, even in Zig foo() could deadlock and prevent bar() from being called, but that can happen in any Turing-complete language.)

Well, you could bite the bullet and carefully make Zig non-Turing complete. (Or at least put Turing-completeness behind an escape hatch marked 'unsafe'.)

That's how Idris and Agda etc do it.

Re: Speed of Rust vs. C

#187

Post by gameswithgo »

waterhouse wrote: post #30
viraptor wrote: post #6

Earlier quoted context omitted.

It's not trivial to write a funny and clever burn, but this just hits the spot...

That is nice, although I think Heartbleed was due to a missing bounds check enabling the reading of adjacent memory, not due to reusing the same buffer...

iirc both issues caused the problem. Buffer overlow let the memory get read, re-use meant there was important data in the buffer.

Re: Speed of Rust vs. C

#188

Post by jmacjmac »

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.

Re: Speed of Rust vs. C

#189

Post by _ph_ »

_vvhw wrote: post #181
_ph_ wrote: post #73

Earlier quoted context omitted.

When we talk about support for threading/concurrent programming in programming languages, it is less about how to reach the theoretical limits of your system best, especially if you are free to architect the whole software stack towards that goal. In that case, your statements might apply. It is about how easily a programmer, who deals with a certain subtask in a system, can utilize more cores for the this task. Not…

You are not factoring in the cost of context switches, and that many user applications today are memory-bound and not CPU-bound. It's one of the secrets exploited by the M1 chip, seen in how many more cache lines the CPU's LFB can fill concurrently compared to Intel chips and that these are now 128 byte cache lines instead of 64 byte cache lines.

Which context switches? With the Go model, I have exactly one thread per CPU, no context switches. And if you are memory-bound, why have more CPUs?

But sure, there is a reason why the M1 has so stellar performance, it has one of the fastest single-thread performances and many applications do not manage to load more than 4 cores for common tasks - which partially is also a consequence of doing that is difficult in many programming languages, but easy in some, which are only slowly gaining traction.

Re: Speed of Rust vs. C

#190

Post by fulafel »

alerighi wrote: post #144
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…

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

A lot of modern embedded hw are running operating systems providing threads (such as Linux) and multi-core CPUs.
Post reply on HN