5 ms·

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

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.

wycy 9y ago
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.
- peatmoss 9y ago
  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 :-)
  - gnufx 9y ago
    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.
    - peatmoss 9y ago
      Hmm... maybe it was the Intel linear algebra stuff (MKL?) that was the source of that speedup
      - gnufx 9y ago
        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.
        peatmoss 9y ago
        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.
- gnufx 9y ago
  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.
  - gnufx 9y ago
    I found that results from the Polyhedron benchmarks are online again <https://www.fortran.uk/fortran-compiler-comparisons/polyhedron-benchmarks-linux64-on-intel/> 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.
martinpw 9y ago
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.
- chrisseaton 9y ago
  Maybe their optimisations reveal proprietary information about how their processors are implemented that they don't want to disclose?
  - peatmoss 9y ago
    Maybe people would flip the RUN_SLOW_ON_AMD flag to false. :-)
    - sanxiyn 9y ago
      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.
      - dredmorbius 9y ago
        Source?

wycy 9y ago

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.

peatmoss 9y ago
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 :-)
- gnufx 9y ago
  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.
  - peatmoss 9y ago
    Hmm... maybe it was the Intel linear algebra stuff (MKL?) that was the source of that speedup
    - gnufx 9y ago
      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.
      - peatmoss 9y ago
        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.
gnufx 9y ago
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.
- gnufx 9y ago
  I found that results from the Polyhedron benchmarks are online again <https://www.fortran.uk/fortran-compiler-comparisons/polyhedron-benchmarks-linux64-on-intel/> 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.

martinpw 9y ago

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.

chrisseaton 9y ago
Maybe their optimisations reveal proprietary information about how their processors are implemented that they don't want to disclose?
- peatmoss 9y ago
  Maybe people would flip the RUN_SLOW_ON_AMD flag to false. :-)
  - sanxiyn 9y ago
    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.
    - dredmorbius 9y ago
      Source?