C compiler and Rust-Lang

This post was flagged by the community and is temporarily hidden.

There are a few things that require the nightly compiler such as inline assembly, but normally you should be able to do everything on stable.

Thus, Rust-Lang can offer all C programming language features?

The only one I can think of that is missing is variable length arrays on the stack, although there is an RFC where they're discussing adding this feature.

Are there any features in particular you are curious about?

1 Like

"Can offer all features of language X" is largely irrelevant. Rust is a very expressive language and you can probably do anything you could do in C, but sometimes most likely in a different manner.

1 Like

On the road to learning Rust I have reimplemented a few non-trivial programs from C/C++ to Rust. I encountered no great problems doing so, apart from the usual when learning a new language. In all cases the resulting Rust code performed as well as the original C/C++ versions, sometimes a little better.

I have yet to find anything showstopping that can be done in C/C++ but not in Rust.

Meanwhile there is a Rust working group dedicated to fixing up the last niggles of interfacing Rust with C. To achieve "Parity with C" as they say: https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ so things will get even better in the future.

C got variable length arrays a while ago. My understanding is that it was later realized they are a bad I did and use of them is now deprecated. Use of variable length arrays was removed from the Linux kernel on the grounds they hindered performance. I would not like to see them come to Rust.

4 Likes

How about https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html?

I think this micro-controller project, originally C++ and rewritten in Rust nicely demonstrates how Rust can do anything C can. Rewriting m4vgalib in Rust: http://cliffle.com/blog/m4vga-in-rust/#continue-reading

2 Likes

Which one is faster?

It's never possible to categorically state that one language is faster than the other. But AFAIK:

  • there are no performance tricks you can do in C that you can't do in Rust
  • concurrency is wildly dangerous in C but trivially safe in Rust
  • some things do feel or seem harder to do in Rust (e.g. self-referential structs), but they're still possible in unsafe Rust, and just as hard to get right in C; Rust merely makes their difficulty harder to ignore
  • For most programs, idiomatic Rust is generally no slower than idiomatic C, and is often faster. Most "why is the Rust version slower?" threads turn out to be simple mistakes like not using --release or unidiomatic things like not using iterators and so on.

There's a million blog posts going into this in far more detail if you're still interested, but Cliffle's posts are my favorite in this space so: http://cliffle.com/p/dangerust/, http://cliffle.com/blog/prefer-rust/, http://cliffle.com/blog/m4vga-in-rust/

3 Likes

Here's a longer version explaining why it's hard to say which one is faster: https://kornel.ski/rust-c-speed

4 Likes

Language-wise, they are fairly comparable. C cannot encapsulate unsafe behavior. Rust cannot be compiled on nearly as many target architectures as C.

1 Like

Interesting article. And no doubt has a lot of truth to it.

My experience so far is that of the programs I have reimplemented in Rust from the C/C++ originals is:

  1. They all ended up being the same speed or marginally faster than the C/C++ originals on my x86_64 PC.

  2. They all ended up being 10 or 20% slower than the C/C++ originals on the ARM processor of a Raspberry Pi 3B.

Worse still I found that changes to the code that gained performance on x86_64 did the opposite on ARM.

I'm still puzzling over why this is.

1 Like

Have you tried with target-cpu setting tuned for the ARM? I'm not sure if Rustc enables NEON by default, for example.

1 Like

I'm building on the Pi itself. With a 64 bit kernel and using the d64-shell. I build like so:

RUSTFLAGS="-C opt-level=3 -C debuginfo=0 -C target-cpu=cortex-a53" cargo build --release --features=use_u64 --features=threaded

Using nightly I have tried setting target-cpu to all the possible aXX options available that produce code that runs without "illegal instruction"

So far the best result I get is with a53. All others seem to run in the same time or longer. My timing is done crudely using the 'time' command so it's a bit noisy. I have run it a few times at each setting though.

Code is here https://github.com/ZiCog/tatami-rust if you feel like trying your hand and speeding it up further. https://github.com/ZiCog/tatami-rust. Both Rust and the C/C++ versions of the same are in there, and a makefile to build them all.

The good news though is that on a Pi 4, which I don't have, the Rust plus rayon is second place behind a C version using hand crafted pthreads. See score board of all the various solutions in various languages here: https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=257317&start=250

Thing is though, on x86_64 the Rust version comes out on top. Grrr....

1 Like