In the scientific / numeric space it’s not unheard of to buy Intel Fortran/C compilers for performance reasons.
Also, it’s been a few years since I touched IBM’s POWER hardware with AIX, but I’m pretty sure XLC and whatever the Fortran compilers were didn’t come free.
I wish Intel would make their compiler free, or work harder on integrating their optimizations into free compilers. They can't be making much money off it, and it just feels counterproductive to charge customers extra to get the best performance from their own hardware.
Anecdotally, changes to ICC are evaluated (by management) on two metrics: improvement on Intel CPU, but also improvement on Intel CPU minus improvement on AMD CPU. The end result is similar to RUN_SLOW_ON_AMD flag.
If you think this cheesy, consider this: you are a manager of Intel compiler team. Someone implemented an optimization that improves performance by 1% on Intel, but 10% on AMD. Do you think it is a good change? The change will be no-brainer on GCC, but consideration for ICC is necessarily different.
My organization uses the Intel Fortran compiler. I did a few rough benchmarks at one point and found it produced code nearly 3x faster than the same code in gfortran.
I hear this a lot, but if it's with equivalent optimizations it's quite pathological and should be reported as a bug; it's certainly not generally the case. They are typically similar at the 10-20% level in my experience (not always in ifort's favour). There are several significant HPC codes which recommend GCC where it matters. You also need to consider reliability; GCC is surprisingly better in my experience -- I've quite often solved users' problems with "just try GCC".
There used to be a published set of results from Polyhedron -- presumably to help to sell proprietary compilers -- which had a geometric mean favouring ifort by ~20%, if I remember right. However, the last I saw didn't use the latest GCC, required the same flags for each case (which didn't include profile-directed, for instance), and the cases with the biggest differences actually bottlenecked on libraries, not generated code. gfortran is infinitely faster on most architectures, of course.
Most benchmark results I see aren't useful because they don't supply the parameters needed to be reproducible and they don't have profile information to allow you to understand, and maybe improve, them.
I found that results from the Polyhedron benchmarks are online again <https://www.fortran.uk/fortran-compiler-comparisons/polyhedr.... Note that they compare gfortran from 2015 and ifort from 2017. I don't know how representative they are of the part of the workload on typical HPC systems for which the compiler might be important.
I suspect the exact speedup depends a lot on the workload, but the last time I supported scientists on HPC, they reported pretty substantial performance gains with ifort over gfortran as well. But then Intel has deeper pockets to pay for this kind of thing than the FSF.
I think I also recall something about gfortran deliberately choosing some more conservative optimization strategies, which could also explain some differences. Or I could be misremembering absolutely everything :-)
Much large scale computation on a typical general HPC system is quite insensitive to the compiler, with most time spent in maths libraries and/or MPI. Most scientists compiling code don't know anything about performance engineering, or even measuring things, unfortunately.
GCC does correct optimization by default (modulo bugs). ifort's default set of flags on GNU/Linux at least used to be non-standard-conforming (maybe fast-math?). Comparisons need to use equivalent flags for gfortran. I don't have the ones I once noted to hand, but they'd include -Ofast -funroll-loops -march=native. The ifort default also generates static binaries, which require static libraries and which you typically don't want so that you can do profiling, for instance.
Maybe. For what it's worth, OpenBLAS is at least as fast on all AMD64 micro-architectures before AVX512 that I've had access to. That's for DGEMM, which is what normally matters; MKL may well have optimized more kernels than OpenBLAS has. Unfortunately, many cling to performance myths in the face of measurements.
Yeah, my last experience with paid MKL libs / Intel compilers was some years ago now—before I ever remember seeing anything about OpenBLAS. I know OpenBLAS has been a big performance boon.
And to be clear, I’d love to see Free and Open Source options be the standard for HPC. It sounds like we may be much closer to that state today than we were years ago when last I worked with people highly concerned about performance in this area. That’s great news.
> Now I want to write compilers and developer tools, but there's no money to be made.
It's sad. One the one hand it's great that we have access to so many amazing compilers for free. But now there's a monopoly of compilers - and by extension, programming languages - by large corporations. They're all kind of the same thing too - vaguely C-like statically typed ALGOL languages with OO and FP features bolted on top. Swift/Kotlin/C#/Java/Typescript/Go, it's all much the same.
I don't think anything novel (a smalltalk, prolog, haskell or scheme) could get any mindshare today, unless a big company lost their mind and tried to push something weird.
