4 ms·

The paper covers inefficiencies in compiler-generated binaries, either from missed optimization opportunities or from the compiler's own poor code generation.

The paper covers inefficiencies in compiler-generated binaries, either from missed optimization opportunities or from the compiler's own poor code generation. The paper shows that some of these perceived inefficiencies can be resolved by manual changes on a few lines of code, such as eliminating redundancies. However, the paper then demonstrates that such manual changes can sometimes make the results worse because a particular compiler might not be able to perform inlining or vectorization. The paper concludes the optimization study by stating, "no compiler is better or worse than another production compiler in all cases." (The study was on GCC, LLVM, and ICC.)

andrepd 6y ago
That conclusion is hardly insightful. We don't expect one compiler to be universally better in every single conceivable situation that another. Of course (in terms of performance) one can still build benchmarks that evaluate how good it is in typical numerical code, for instance.
- gnufx 6y ago
  Yes, however typical users do appear to expect or claim that, normally for the Intel compiler, on the basis of myth and not measurement and understanding. I'm not convinced there is typical numerical code across scientific applications, though; consider the (behaviour) on the Polyhedron Fortran benchmarks, for a start.
  - xscott 6y ago
    I used to work with some folks who believed the Intel compiler was amazing. I think the logic to the myth was, "Who would better know how to optimize for Intel chips?". However, in my experience icc crashed more than any other compiler I've ever used (internal compiler errors). That kind of a bug in a compiler makes me really wonder what else is wrong under the hood. And of course, being closed source, I can't possibly know...
    - gnufx 6y ago
      Indeed, and you can be told you have to use it even when it won't compile the code, or the result won't run correctly (and obviously you should use it and MKL on AMD hardware too). At least it's not as bad as the infamous "Pentium GCC" from long ago.
- mayank 6y ago
  The conclusion is just a restatement of the No Free Lunch theorem in optimization. [1] https://en.m.wikipedia.org/wiki/No_free_lunch_theorem https://en.m.wikipedia.org/wiki/No_free_lunch_theorem

andrepd 6y ago

That conclusion is hardly insightful. We don't expect one compiler to be universally better in every single conceivable situation that another. Of course (in terms of performance) one can still build benchmarks that evaluate how good it is in typical numerical code, for instance.

gnufx 6y ago
Yes, however typical users do appear to expect or claim that, normally for the Intel compiler, on the basis of myth and not measurement and understanding. I'm not convinced there is typical numerical code across scientific applications, though; consider the (behaviour) on the Polyhedron Fortran benchmarks, for a start.
- xscott 6y ago
  I used to work with some folks who believed the Intel compiler was amazing. I think the logic to the myth was, "Who would better know how to optimize for Intel chips?". However, in my experience icc crashed more than any other compiler I've ever used (internal compiler errors). That kind of a bug in a compiler makes me really wonder what else is wrong under the hood. And of course, being closed source, I can't possibly know...
  - gnufx 6y ago
    Indeed, and you can be told you have to use it even when it won't compile the code, or the result won't run correctly (and obviously you should use it and MKL on AMD hardware too). At least it's not as bad as the infamous "Pentium GCC" from long ago.
mayank 6y ago
The conclusion is just a restatement of the No Free Lunch theorem in optimization. [1] https://en.m.wikipedia.org/wiki/No_free_lunch_theorem https://en.m.wikipedia.org/wiki/No_free_lunch_theorem