4 ms·

Good luck with that, cause there are bugs, as the article also points out. Previous release miscompiled Python [1] Current release miscompiles bison [2] It's

Good luck with that, cause there are bugs, as the article also points out. Previous release miscompiled Python [1] Current release miscompiles bison [2] It's also the type of compiler that defaults to -ffast-math to look good in benchmarks (well, all vendor compilers do). That breaks many packages that rely on signalling NaNs, or use e.g. Kahan summation for stable math with IEEE floats. It's caught in the Spack package manager because it's probably one of the few package managers that lets users pick their own compiler for a full software stack. [1] https://github.com/spack/spack/issues/38724 https://github.com/spack/spack/issues/38724 and https://github.com/python/cpython/issues/106424 https://github.com/python/cpython/issues/106424 [2] https://github.com/spack/spack/issues/37172#issuecomment-1810420500 https://github.com/spack/spack/issues/37172#issuecomment-181...

repelsteeltje 3y ago
So it's an LLVM front end + Intel backend, relatively new and not in common use. Not surprised there are issues, but wouldn't it be fair to attribute those to "growing pains"? First issue was resolved, the bison issue is still pending. > It was a compiler bug. The test now passes when cpython is built with an internal build. The next compiler release (likely 2024.0) should have the fix. So I wouldn't recommend running FreeBSD on oneAPI in production just yet, but I give them some credit & celebrations for reaching a milestone.
- stabbles 3y ago
  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.
RuggedPineapple 3y ago
It works at least well enough to build a working FreeBSD kernel, as the article notes that was built and then booted as a test. I have to imagine if the thing can build that its doing pretty well. That isn't a trivial piece of software. Makes me suspect any teething issues will be sorted and that it's not fundamentally compromised.
Twirrim 3y ago
> It's also the type of compiler that defaults to -ffast-math to look good in benchmarks Not sure if they're still doing that, but in the early days of Clear Linux they were using -ffast-math on everything they compiled, as a way to give their distro a big performance boost over competition, too.
- stabbles 3y ago
  I think they do a lot of good stuff, like LTO and PGO. But in benchmarks you sometimes see like a 4x speedup compared to ubuntu, which is obviously not due to superior compilers. For example: https://github.com/phoronix-test-suite/phoronix-test-suite/issues/633 https://github.com/phoronix-test-suite/phoronix-test-suite/i...

repelsteeltje 3y ago

So it's an LLVM front end + Intel backend, relatively new and not in common use. Not surprised there are issues, but wouldn't it be fair to attribute those to "growing pains"? First issue was resolved, the bison issue is still pending. > It was a compiler bug. The test now passes when cpython is built with an internal build. The next compiler release (likely 2024.0) should have the fix. So I wouldn't recommend running FreeBSD on oneAPI in production just yet, but I give them some credit & celebrations for reaching a milestone.

stabbles 3y ago
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.

RuggedPineapple 3y ago

It works at least well enough to build a working FreeBSD kernel, as the article notes that was built and then booted as a test. I have to imagine if the thing can build that its doing pretty well. That isn't a trivial piece of software. Makes me suspect any teething issues will be sorted and that it's not fundamentally compromised.

Twirrim 3y ago

> It's also the type of compiler that defaults to -ffast-math to look good in benchmarks Not sure if they're still doing that, but in the early days of Clear Linux they were using -ffast-math on everything they compiled, as a way to give their distro a big performance boost over competition, too.

stabbles 3y ago
I think they do a lot of good stuff, like LTO and PGO. But in benchmarks you sometimes see like a 4x speedup compared to ubuntu, which is obviously not due to superior compilers. For example: https://github.com/phoronix-test-suite/phoronix-test-suite/issues/633 https://github.com/phoronix-test-suite/phoronix-test-suite/i...