3 ms·

A really high performance vectorizer is dramatically easier to write if you hand wave some of the correctness ideas. It's an interesting point in the design spa

A really high performance vectorizer is dramatically easier to write if you hand wave some of the correctness ideas. It's an interesting point in the design space. Classically compilers considered miscompilation to be a serious problem - you disable the 'optimisation' while you work out who got the maths wrong. But maybe today you're better off with a compiler that produces fast wrong code where the customer doesn't seem to be upset about the wrong part. ffast-math is popular, enabling that by default is a plausible thing to do. Plenty of bugs in gcc and llvm. I'm really sure a closed source compiler could be higher quality. Probably not in the C++ world, but I expect there's an ADA compiler out there that gets the answer right whatever the source code is.

stabbles 3y ago
Sure, you can reorder floating point operations and assume no aliasing. Now you can vectorize and avoid redundant memory access. But it's a problem of the language really. Alias analysis in Fortran is much easier than in C / C++. Also I'm reasonably sure that Rust's borrow checker could be used for alias analysis and improve performance without making unsafe assumptions, no clue if that is actually done. For reordering of floating point numbers, there should just be clear demarcations in code where it's safe. It's ridiculous that `-ffast-math` works on the level of the command line. But I think that ship has sailed, cause although clang has supports pragma's, it's not a standard: #pragma clang fp exceptions(strict)
- JonChesterfield 3y ago
  Alias analysis can definitely be easier/harder for different languages. It's the independence of loop iterations which really does the trick for vectorising numerical code. That would be why cuda is magic - if the lanes of the vector operations step on each other, it is defined to be the programmers problem, not the compiler. Thus cuda autovectoriser cannot fail, the code is already a vector. Futhark is probably very good at vector operations. Fast-math has crazy things like setting it for one file affects other files. Last time I checked a more reasonable alternative set of constructs were being considered/implemented. Other faster-but-kindof-wrong things like assuming signed integers don't overflow exist too. Agreed that they're all less alarming when locally scoped.
- WalterBright 3y ago
  The semantics of C don't allow for alias analysis. For some cases, the compiler can prove that there are no aliases, but it will have to be conservative and throw up its hands most of the time. An ownership/borrowing system is able to implicitly fulfill the requirements of restrict.

stabbles 3y ago

Sure, you can reorder floating point operations and assume no aliasing. Now you can vectorize and avoid redundant memory access. But it's a problem of the language really. Alias analysis in Fortran is much easier than in C / C++. Also I'm reasonably sure that Rust's borrow checker could be used for alias analysis and improve performance without making unsafe assumptions, no clue if that is actually done. For reordering of floating point numbers, there should just be clear demarcations in code where it's safe. It's ridiculous that `-ffast-math` works on the level of the command line. But I think that ship has sailed, cause although clang has supports pragma's, it's not a standard: #pragma clang fp exceptions(strict)

JonChesterfield 3y ago
Alias analysis can definitely be easier/harder for different languages. It's the independence of loop iterations which really does the trick for vectorising numerical code. That would be why cuda is magic - if the lanes of the vector operations step on each other, it is defined to be the programmers problem, not the compiler. Thus cuda autovectoriser cannot fail, the code is already a vector. Futhark is probably very good at vector operations. Fast-math has crazy things like setting it for one file affects other files. Last time I checked a more reasonable alternative set of constructs were being considered/implemented. Other faster-but-kindof-wrong things like assuming signed integers don't overflow exist too. Agreed that they're all less alarming when locally scoped.
WalterBright 3y ago
The semantics of C don't allow for alias analysis. For some cases, the compiler can prove that there are no aliases, but it will have to be conservative and throw up its hands most of the time. An ownership/borrowing system is able to implicitly fulfill the requirements of restrict.