Hacker News new | ask | show | jobs
by almindor 2356 days ago
Rust will outperform C consistently soon. It already does in some cases. It will also do so with safe idiomatic code in most cases. The reason behind my statement is simply more opportunity for the optimizer. Rusts rules allow for a more aggressive optimization. The reasons why it's not outperforming C yet are LLVM bugs and some missing Rust language features and fixes. LLVM in particular is driven by C needs so they rarely fix bugs present only Rustc generated IR.
3 comments

This is grey, but shouldn’t be. I assume people are downing it because it doesn’t give examples of the optimization opportunities it claims. So here are two that I think are likely most significant.

1. Rust’s aliasing semantics are more powerful than C’s unless you use the ‘restrict’ keyword everywhere, which most people don’t. It’s well recognized that FORTRAN continues to generally outperform C in many numeric applications because FORTRAN compilers are free to perform optimizations that C compilers cannot or don’t, due to the fact that multi-aliasing memory is undefined behavior in FORTRAN. The rust compiler currently doesn’t pass the relevant hints to the generated LLVM IR due to a long history of LLVM having bugs in ‘noalias’ handling, in large part due to the fact that those code paths are so rarely executed while compiling C code, itself due to the relatively low usage of the ‘restrict’ keyword.

2. Implicit arena allocations. The Rust compiler has access to information about possible aliasing and overlapping lifetimes that it can use to replace multiple allocations with similar lifetimes with offsets into a single allocation that is then all freed together. This is a complicated topic, but work is ongoing to make this a reality.

2 might sound overly optimistic like "Rust will eventually beat C" but V8 already has an allocation folding optimization which combines multiple objects into a single site. There's also run time profiling to try and figure out the allocation lifetime.

https://static.googleusercontent.com/media/research.google.c... and https://static.googleusercontent.com/media/research.google.c...

> work is ongoing to make [implicit arena allocations] a reality.

Ooh, interesting; I hadn't heard about that but it makes a lot of sense. Do you happen to have an RFC or issue link? My google-fu is failing me.

rustc still has a number of cases where it performs poorly compared to gcc and even clang
I'm not disputing that. In theory Rust should outperform even today but of course reality is a different beast and implementation details are important.

Then you also get into architecture specifics etc.

dodobirdlord described the two major advantages Rust has on the language level very well so I won't repeat them, but the gist I'm making is that Rust simply allows more optimizations purely on the language level. Specifics of backend implementations are of course another topic completely (and is one of the reasons why I'm excited for the possibility of a GNU Rustc)

What rules, is pointer aliasing enough?

The backends are getting so complicated now that I'm not sure low level languages can make that much difference assuming they generate clean IR.