Hacker News Reader

Comment by agumonkey | Hacker News Reader

I read some 2015 review of rust from viva64 where they used benchmarkgame to show rust is still 3x C. Nowadays benchmarkgame has Rust and C in the same numbers. That's quite a feat.

View on HN

I've mentioned it before but there's a chance for Rust to get better than most C code with the ability to implicitly mark mut& as restrict.

Restrict is one of those very, very sharp tools that's usually only reserved for cases where you've profiled and done the extensive work to guarantee non-aliasing pointers. The fact that it's just implicit as part of the ownership design of Rust is pretty bad-ass.

For those of us unfamiliar with restrict, I found this article: https://en.cppreference.com/w/c/language/restrict

"The intended use of the restrict qualifier (like the register storage class) is to promote optimization, and deleting all instances of the qualifier from all preprocessing translation units composing a conforming program does not change its meaning (i.e., observable behavior).

The compiler is free to ignore any or all aliasing implications of uses of restrict.

To avoid undefined behavior, the programmer must ensure that the aliasing assertions made by the restrict-qualified pointers are not violated. ..."

AIUI it seems that one of the issues that Rust is having right now is that it actually has more precise information than LLVM is really capable of taking advantage of, which makes sense given that LLVM was originally intended to take advantage only of C's coarser restrict semantics. It's sort of a funny situation where the fact that Rust could improve on C's optimization capabilities is the same reason that it can't yet do so: it's using an optimizer designed for C!

That said, I'm hardly an expert here and the situation on the ground may have changed since last I looked (or I may be completely misunderstanding the discussions that I've peeked into). An example of the problem in this GitHub issue: https://github.com/rust-lang/rust/issues/53105

Yeah, this is true.

We do the equivalent of telling the compiler that things don't alias at function boundaries (i.e. restrict) and not much more.

Nobody writes C code with restrict all over the place, which means that not only is this the finest grained level we can give this info to LLVM, it doesn't even necessarily support it well! We had to turn it off for &mut for a long time because of a bunch of bugs.

The weird thing is, to be able to do most optimizations LLVM does its own alias analysis anyway! (I don't know the details).

A lot of program analysis research is focused on improving alias analyses which are usually slow, imperfect, and global. Rust's aliasing info is "free" (you don't need to compute anything extra to get it), local, and perfect (ish). We really could get a lot of wins from doing our own aliasing-aware analyses, or by reordering the code in such a way so as to make it easier for LLVM (e.g., hoisting reads and writes to function boundaries so llvm just sees a bunch of locals)

Discussed three years ago: https://news.ycombinator.com/item?id=9531822

and two years ago: https://news.ycombinator.com/item?id=12232385

Rust hasn't really got 'faster' in that time, barring the odd optimizer improvement as noted in sibling. Much more likely that whatever benchmark you refer to has been rewritten for better performance.

Don't discount multiple years of "odd optimizer improvements". They add up.

That said, yes, re-writes are probably a bigger thing here. Especially lately: https://llogiq.github.io/2018/09/06/fast.html

maybe stable semantics helped people writing better libs too ?

That's true, though the benchmark game doesn't use many libraries, and the post was written just before 1.0, as things were settling down a bit.

Another major evolution is that SIMD is becoming part of stable Rust. It is available in C and C++ as GCC and Clang extensions, but not part of the standard language. Careful use of SIMD can result in fairly massive speedups across a wide range of problem domains.

Rust just recently got SIMD support in stable and they have been working on applying it to benchmarkgame very recently, so it should be improving more soon.

Reply on news.ycombinator.com