Why Programmer-Specified Aliasing Is a Bad Idea (2004) [pdf]

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.140&rep=rep1&type=pdf

by tjalfi • 5 years ago

39 26 5 years ago

citeseerx.ist.psu.edu

tjalfi• 5 years ago

(submitter)

Here’s the abstract.

The ISO C standard C99 has added a special keyword, named restrict to allow the programmer to specify non-aliasing as an aid to the compiler’s optimizer and to thereby possibly improve performance. However, it is the programmer’s responsibility to ensure that the annotations are correct. Therefore, in practice, restrict will be useful only when the programmer’s effort is rewarded with noticeable performance improvement. To assess the performance potential of the restrict annotation, we automatically generated best-case restrict annotations for SPEC CPU2000 benchmarks by using pointer profiling. However, even though we used the best possible restrict annotations, we found an average program speedup of less than 1% on average when using two state-of-the art optimizing compilers that implement the restrict pragma. Since the typical performance benefits do not warrant significant user effort and potential errors, we conclude that having the programmer specify non-aliasing is a bad idea.

nestorD• 5 years ago

Apparently the Rust compiler saw a 5% improvement (on average) when they enabled automatic aliasing information (they are now working with LLVM to get it back on).

Note that it is very program dependent, a friend got a 30% improvement on a very specialized numerical simulation.

vvanders• 5 years ago

Yeah, it's highly workload dependent. I've used restrict in anger to accelerate particle systems and we saw a significant speed boost.

Even a 5% speed increase is nothing to discount give that it's "free" once they have LLVM handling it correctly. I agree with the conclusion that if you have to manage the aliasing manually it's very limited in scenarios where you would want to deploy that given the failure modes of getting it wrong.

masklinn3• 5 years ago

Apparently the Rust compiler saw a 5% improvement (on average) when they enabled automatic aliasing information (they are now working with LLVM to get it back on).

For now, it should be part of the next release (1.54).

It was originally slated for 1.53, but then a new miscompilation was discovered during the 1.53 release cycle, so it stayed off.

amelius• 5 years ago

The downside is that it's totally out of your control. One small change to your program in a seemingly unrelated area, and suddenly your 5% or 30% improvement may vanish ...

b3morales• 5 years ago

I'm very curious what interaction there is with compiler-imposed strict aliasing. I can't determine from a scan of the paper what they expected the compiler to do in this regard. I.e., was some equivalent of either `-fstrict-alias` or `-fno-strict-alias` in effect?

mst• 5 years ago

I do wonder if there's a chicken and egg issue here, in that it not being used very much means not much effort has been put into optimisations that take advantage of it.

(though by "I wonder" I do not in any way suggest I'm qualified to have an opinion on the compiler internals themselves)

mhh__• 5 years ago

Highly dependant on the actual workload too.

It's worth pointing out that compiler optimizations are not written as a lump of symbolic logic which then automatically goes and finds speed, there does have to be some human written code directing the transformations, so there likely is a chicken and egg here.

One complication is that in situations where aliasing is unlikely but very harmful some compilers already check for aliasing then use an optimized routine rather than a slow one that has to handle aliasing - that means user specified alias hints could only yield the elision of a branch and some instructions rather than a dramatic increase in throughput.

zX41ZdbW• 5 years ago

In ClickHouse there is 1.6 times performance improvement after simply adding __restrict in aggregate functions:

https://github.com/ClickHouse/ClickHouse/pull/19946#issuecom...

anyfoo• 5 years ago

It's interesting to note that the hesitant adoption of "restrict" in C has affected rust's use of the LLVM implementation of that feature.

In rust, technically almost every pointer is non-aliasing, so you could enable "restrict" (or rather its equivalent down in the LLVM layer) by default for almost every pointer. However, this uncovered many unexercised corner cases where LLVM's restrict implementation appeared broken:

https://stackoverflow.com/questions/57259126/why-does-the-ru...

Scroll down to the answer to see how often noalias was enabled and disabled.

dataangel• 5 years ago

It just got reenabled again.

vlovich123• 5 years ago

Are you aware of any interesting benchmarks? I’m curious what the performance difference is in different kinds of applications.

pjmlp2• 5 years ago

Until the next miscompilation bug is found, how many times it has been reenabled thus far?

Const-me• 5 years ago

These low-level things are hardware dependent.

SPARC and Itanium are dead, and these two are the only platforms being benchmarked in the article.

This makes the article useless, we only care about AMD64 and ARM these days.

rurban• 5 years ago

This is my probe to disable broken restrict implementations

https://github.com/rurban/autoconf-archive/commit/91625ebef2...

Why Programmer-Specified Aliasing Is a Bad Idea (2004) [pdf]

Related Stories