News for hackers. Stuff that matters.
Re:Intel's “cripple AMD” function (2019) by jedbrown on Friday August 28, 2020 @05:55PM (#24310511)
This is an overstatement. ICC consistently compiles the slowest and produces the largest binaries. It also defaults to something close to -ffast-math, which may or may not be appropriate. If your app benefits from aggressive inlining and vectorization at the expense of potentially huge increases in code size, ICC is likely to do well for you. However, I've seen lots of cases where well-vectorized code is faster with GCC or Clang, including some very important cases using Intel intrinsics. (Several such cases reported to/acknowledged by Intel; some have been fixed over the years, but these observations are not uncommon.)

BLIS is used by AMD and is a good open alternative to MKL (for BLAS) across many platforms. https://github.com/flame/blis/blob/master/docs/Performance.m...

Re:Intel's “cripple AMD” function (2019) by outworlder on Friday August 28, 2020 @06:59PM (#24311344)
I have been hearing about the superiority of Intel's compiler for a couple of decades now. Back when GCC was a tiny baby compared to what it is now, and when Clang/LLVM didn't even exist.

I wonder if this Intel compiler 'superiority' is still the case today, or if this is just a meme at this point.

Re:Intel's “cripple AMD” function (2019) by jarvist on Friday August 28, 2020 @07:18PM (#24311524)
For matrix manipulation based Fortran scientific codes, ifort/MKL can give +30% compared to gfortran. It's difficult to disentangle where the speedup comes from, but certainly as jedbrown aludes to, the Intel compilers seem to make a better go of poorly optimised / badly written code.

For C based software, its a much closer run thing, and often sticking with GCC avoids weird segfaults when mixing Intel and GCC-compiled Linux libraries.

Re:Intel's “cripple AMD” function (2019) by gnufx on Saturday August 29, 2020 @07:01PM (#24320033)
> This is an overstatement.

To be generous...

Where do you typically see lack of inlining and vectorization with GCC? I'm curious because most times people have said GCC wouldn't vectorize code that I've been able to try, it would, at least if allowed -ffast-math a la Intel (as in BLIS now).

Re:Intel's “cripple AMD” function (2019) by kzrdude on Friday August 28, 2020 @08:36PM (#24312126)
Can you explain "BLIS is used by AMD"? In what way do they use it?
Re:Intel's “cripple AMD” function (2019) by jedbrown on Saturday August 29, 2020 @09:23AM (#24315890)
It's their official BLAS [1] since 2015 when they moved away from their proprietary ACML implementation [2].

[1]https://developer.amd.com/amd-aocl/blas-library/

[2] https://developer.amd.com/open-source-strikes-again-accelera...

Re:Intel's “cripple AMD” function (2019) by gnufx on Saturday August 29, 2020 @07:11PM (#24320067)
Amusingly, OpenBLAS significantly beat the bought-in ACML, on DGEMM, over the six(?) generations of Opteron I had available. AMD learnt.