11–20 of 36 posts
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays. While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays. While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
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…
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays. While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
Earlier quoted context omitted.
Are you talking about dropping pointers as a programmer-facing programming language concept (in which case you might find Hylo and similar languages interesting), or dropping pointers from everything - programming languages, their implementations, compilers, etc. (in which case I'm not sure that's even possible)?
Only the first one. Ofc under the hood they will stay, but I think its time to ditch random access model and pull fetching and concept of time closer to programmer
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays. While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
Is it? You just add "restrict" where needed? https://godbolt.org/z/jva4shbjs
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.
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?
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
Earlier quoted context omitted.
Only the first one. Ofc under the hood they will stay, but I think its time to ditch random access model and pull fetching and concept of time closer to programmer
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.
> 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)