3 ms·

It does not look like correctness is their main concern, they mostly care about performance of the vectorizer ;) Also note that before Intel oneAPI there was t

It does not look like correctness is their main concern, they mostly care about performance of the vectorizer ;) Also note that before Intel oneAPI there was the now deprecated Intel Classic Compiler (icc), which also had bugs, since 2003. In my opinion it's unlikely that a closed source vendor compiler will ever be on the same level as gcc and clang. It will never be tested as much, and it's hard to make actionable bug reports for closed source software. Being based on LLVM is of course a good choice... hopefully fewer bugs.

repelsteeltje 3y ago
My money's on llvm/clang and gcc as well, though Microsoft Visual C++ is still hanging in there. Fwiw icc once had a reputation for being fast but I never thought high of their software. Only hands on experience I had was with Intel Media SDK where even basic stuff, like finding a legal download, hardware requirements and installation guidance was tough. And then each iteration both software and hardware was deprecated faster than Google can dream to abandon their products.
- CoastalCoder 3y ago
  > Fwiw icc once had a reputation for being fast but I never thought high of their software. Aside from some GUI scaling issues on Linux, I was really impressed by Intel Vtune. Also, some of their low level libraries like Xed and Pin Tools are pretty cool, and seemed (last I looked) well-maintained.
  - repelsteeltje 3y ago
    Ah yes. VTune. I had forgotton that one, pretty good stuff indeed.
  - jsheard 3y ago
    Their Embree raytracing library is at the heart of pretty much every high-end production CGI renderer, it's the gold standard at what it does. Intel does have some gems.
JonChesterfield 3y ago
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.

repelsteeltje 3y ago

My money's on llvm/clang and gcc as well, though Microsoft Visual C++ is still hanging in there. Fwiw icc once had a reputation for being fast but I never thought high of their software. Only hands on experience I had was with Intel Media SDK where even basic stuff, like finding a legal download, hardware requirements and installation guidance was tough. And then each iteration both software and hardware was deprecated faster than Google can dream to abandon their products.

CoastalCoder 3y ago
> Fwiw icc once had a reputation for being fast but I never thought high of their software. Aside from some GUI scaling issues on Linux, I was really impressed by Intel Vtune. Also, some of their low level libraries like Xed and Pin Tools are pretty cool, and seemed (last I looked) well-maintained.
- repelsteeltje 3y ago
  Ah yes. VTune. I had forgotton that one, pretty good stuff indeed.
- jsheard 3y ago
  Their Embree raytracing library is at the heart of pretty much every high-end production CGI renderer, it's the gold standard at what it does. Intel does have some gems.

JonChesterfield 3y ago

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.