4 ms·

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 gfo

by 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.

by 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.