3 ms·

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 w

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

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.