5 ms·
> The performance difference comes from the fact that Fortran says aliasing is not allowed [...] This is one of the legacies modern C++ is still wrestling with
by pipo234 3y ago
> The performance difference comes from the fact that Fortran says aliasing is not allowed [...]
This is one of the legacies modern C++ is still wrestling with today, supposedly solved by Rust, Zig, Val and the likes.
- fsckboy 3y agofortran is call by reference, it's all aliasing, you can even in some implementations change the value of literals c is call by value, you have to at least try to alias
- gpderetta 3y agomy understanding is that in fortran, if two arguments alias each other, it is UB. So it is not that fortran doesn't have aliasing, it is just that the optimizer assume that it doesn't (but don't quote me on this!).
- Bostonian 3y agoArguments are allowed to alias if they are both inputs that will not be changed in the function -- technically if they are both "intent(in)".
- pklausler 3y agoINTENT(IN) is not required to allow aliasing of unmodified dummy arguments.
- kergonath 3y agoYes, but in practice no compiler checks whether an argument with no INTENT is modified or not, or could alias with something else or not. So the compilers tend to trust the programmer. With INTENTS, it’s obvious and much easier to check.
- pklausler 3y agoDummy argument aliasing has nothing to do with INTENT.
- TheRealKing 3y agoI believe the NAG Fortran compiler does check for some aliasing scenarios if not all. The argument intent is irrelevant.
- gnufx 3y agoFortran does not call by reference, and the term aliasing isn't used by the standard. It calls by what's usually called value-return or copy-in/copy-out, according to the "storage association" rules in the standard. While it may be true that the rules aren't generally checked by compilers, Toolpack did it for pure Fortran77 in the 1980s, though I don't know how comprehensive it actually was.
- bregma 3y agoIt took me days one time to figure out why 0 had adopted the value four. The technicality is that Fortran is call by descriptor (not by reference, not by value). That's a powerful difference but a sharp two-edged sword.
- kaba0 3y agoCould you please explain how is it differs from the other two? Never looked into Fortran.
- kergonath 3y agoThe Fortran standard does not specify anything about passing by references or value. Instead, it specifies the expected results. The compilers do it however they want or can, which means that they can pass pointers, values, copies, or pointers to copies depending on the situation. Sometimes (most of the time, to be fair), the compiler can work out the best solution. Sometimes, the developer has to jump through some hoops to avoid unnecessary copies.
- zik 3y agoIt's true that there's no "restrict" inthe C++ standard, however all the major C++ compilers have extensions for it ("__restrict__") and have had for a long time.
- patrec 3y agoExcept that it doesn't work and is basically WONTFIX since no C or C++ programmer ever uses it. This is only very slightly exaggerated.
- zik 3y agoThat's utterly incorrect. It's used thousands of times in the linux kernel.
- Conscat 3y agoI've never had issues with it, personally. In what way does it not work?
- lmkg 3y agoRust has aliasing guarantees. In theory, Rust code can pass noalias annotations to LLVM and become more optimized. In practice, it took years for Rust access these optimizations because the noalias annotations kept hitting codegen bugs in LLVM. It was an area of the compiler that had not seen much active use before Rust, and they were causing a lot of dormant bugs to become issues. The feedback cycle was also very long because LLVM didn't fix the problems quickly. I didn't pay close attention so I don't know if this is prioritization or because those fixes required major surgery, but Rust sometimes had to wait for major version bumps in LLVM before seeing if "this time was the last time."
- vlovich123 3y agoYup. But it is true now though so hopefully they’ve added the test cases to LLVM to make sure things continue to work correctly in the face of more and more optimizations being thrown at code.
- _flux 3y agoHmm, I thought basically only Rust solves it. How do Zig and Val solve it?