[HN Gopher] Why Programmer-Specified Aliasing Is a Bad Idea (200...
___________________________________________________________________
Why Programmer-Specified Aliasing Is a Bad Idea (2004) [pdf]
Author : tjalfi
Score : 19 points
Date : 2021-07-30 22:34 UTC (1 days ago)
(HTM) web link (citeseerx.ist.psu.edu)
(TXT) w3m dump (citeseerx.ist.psu.edu)
| anyfoo wrote:
| 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 wrote:
| It just got reenabled again.
| vlovich123 wrote:
| Are you aware of any interesting benchmarks? I'm curious what
| the performance difference is in different kinds of
| applications.
| tjalfi wrote:
| (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.
| mst wrote:
| 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)
| nestorD wrote:
| 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 wrote:
| 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.
| amelius wrote:
| 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 ...
| temac wrote:
| That's the case with tons of compiler optims.
| Tuna-Fish wrote:
| In Rust, that's not true at all. The aliasing information
| flows out of the type system, which you control. If a
| reference is marked mutable, the compiler is free to treat
| it as unaliased, and an unrelated change elsewhere cannot
| change that.
| [deleted]
| masklinn wrote:
| > 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.
| b3morales wrote:
| 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?
___________________________________________________________________
(page generated 2021-07-31 23:01 UTC)