Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aliasing

xania.org

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Aliasing

#21

Post by uecker »

aw1621107 wrote: post #20
uecker wrote: post #15

Earlier quoted context omitted.

This is basically what many functional programming languages do. This always came with plausibly sounding claims that this allows so much better optimizations that this soon will surpass imperative programs in performance, but this never materialized (it still did not - even though Rust fans now adopted this claim, it still isn't quite true). Also control over explicit memory layout is still more important.

Gah, can't believe I forgot about functional programming languages here :( > even though Rust fans now adopted this claim Did they? Rust's references seem pretty pointer-like to me on the scale of "has pointers" to "pointers have been entirely removed from the language". (Obviously Rust has actual pointers as well, but since usefully using them requires unsafe I assume they're out of scope here)

What I meant is that Rust has stricter aliasing rules which make some optimization possible without extra annotations, but this is balanced out by many other issues.

Re: Aliasing

#22

Post by uecker »

adev_ wrote: post #16
uecker wrote: post #14

Earlier quoted context omitted.

Is it? You just add "restrict" where needed? https://godbolt.org/z/jva4shbjs

> Is it? You just add "restrict" where needed? Yes. That is the main solution and it is not a good one. 1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood. 1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.

Regarding "restrict", I don't think one puts it everywhere, just for certain numerical loops which otherwise are not vectorized should be sufficient. FORTRAN seems even more dangerous to me. IMHO a better solution would be to have explicit notation for vectorized operations. Hopefully we will get this in C. Otherwise, I am very happy with C for numerics, especially with variably modified typs.

For C++, yes, I agree.

Re: Aliasing

#23

Post by Etheryte »

pklausler wrote: post #19
Etheryte wrote: post #17

Earlier quoted context omitted.

It's literally in the description? Because of aliasing, a variable that should've been zero became four.

It wasn't a variable.

It wasn't intended to be a variable, but it did become one. Its value varied, it's in the name.

Re: Aliasing

#24

Post by cv5005 »

newpavlov wrote: post #10
artemonster wrote: post #3

I wonder how much potential optimisation there is if we entirely drop pointer nonsense.

For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust. Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }

Re: Aliasing

#25

Post by newpavlov »

cv5005 wrote: post #24
newpavlov wrote: post #10

Earlier quoted context omitted.

For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust. Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like: void foo(void *a, void *b, int n) { assume_aligned(a, 16); assume_stride(a, 16); assume_distinct(a, b); ... go and vectorize! }

LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess.

Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.

Re: Aliasing

#26

Post by mrspuratic »

pklausler wrote: post #12
bregma wrote: post #8

Earlier quoted context omitted.

Aliasing can be a problem in Fortran too. Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect…

How does this bug concern aliasing?

In old school FORTRAN (I only recall WATFOR/F77, my uni's computers were quite ancient) subroutine (aka "subprogram") parameters are call-by-reference. If you passed a literal constant it would be treated as a variable in order to be aliased/passed by reference. Due to "constant pooling", modifications to a variable that aliased a constant could then propagate throughout the rest of the program where that constant[sic] was used.

"Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html

Re: Aliasing

#27

Post by gpderetta »

dataflow wrote: post #18
Ono-Sendai wrote: post #9

When you have done enough C++ you don't need to fire up compiler explorer, you just use local variables to avoid aliasing pessimisations. I also wrote about this a while ago: https://forwardscattering.org/post/51

I think this might not be a shortcoming of MSVC but rather a deliberate design decision. It seems likely that MSVC is failing to apply strict aliasing, but that it's deliberately avoiding it, probably for compatibility reasons with code that wasn't/isn't written to spec. And frankly it can be very onerous to write code that is 100% correct per the standard when dealing with e.g. memory-mapped files; I'm struggling to…

AFIK MSVC has never implemented TBAA by design.

Re: Aliasing

#28

Post by aw1621107 »

uecker wrote: post #21
aw1621107 wrote: post #20

Earlier quoted context omitted.

Gah, can't believe I forgot about functional programming languages here :( > even though Rust fans now adopted this claim Did they? Rust's references seem pretty pointer-like to me on the scale of "has pointers" to "pointers have been entirely removed from the language". (Obviously Rust has actual pointers as well, but since usefully using them requires unsafe I assume they're out of scope here)

What I meant is that Rust has stricter aliasing rules which make some optimization possible without extra annotations, but this is balanced out by many other issues.

Sure, but I think the presence/absence of aliasing is different from what GP was wondering/asking about, which was the removal of pointers from the programmer-facing model.

Re: Aliasing

#30

Post by aw1621107 »

newpavlov wrote: post #25
cv5005 wrote: post #24

Earlier quoted context omitted.

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like: void foo(void *a, void *b, int n) { assume_aligned(a, 16); assume_stride(a, 16); assume_distinct(a, b); ... go and vectorize! }

LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess. Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to i…

Does make me wonder what restrict-related bugs will be (have been?) uncovered in GCC, if any. Or whether the GCC devs saw what LLVM went through and decided to try to address any issues preemptively.
Post reply on HN