
What every scientific programmer should know about compiler optimizations? - blopeur
https://dl.acm.org/doi/abs/10.1145/3392717.3392754
======
chrisaycock
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
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
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
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
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.

------
ISL
A lesson I learned as an undergraduate: Sometimes changing optimization
settings can yield different answers.

It's been ~17 years since then, so I can't recall the options used, but seeing
different results emerge when I used a higher optimization option caused an
unanticipated puff of smoke from my little brain.

A possible moral of the story -- test every little change.

~~~
gumby
I used to be a compiler developer and this was no big deal (except when it was
an actual code generator bug!). The compiler switches tell the compiler to do
different things, so of course some of them change the output semantics. It’s
up to the user to decide what she wants — it’s not like the differences are
obscure or surprising.

Then I went on to other things and realized that developers are experts in
_their_ domains, and those “obvious” things were only clear to someone steeped
in the code — not obvious at all. In fact some of them are no longer obvious
to me any more after decades doing other things. Hopefully I’ve become at
least slightly less arrogant and thoughtless by now.

~~~
kyllo
Are you talking about things like very small differences in the results of
floating point calculations?

~~~
gumby
Some optimization switches are off by default as they can subtly change the
semantics of your code.

Yes, this can trip up even quite knowledgeable people as with the fp post from
Lemire the other day — he thought gcc was making a mistake, but it was doing
the correct thing.

But there are plenty of others, for example telling the compiler not to worry
about aliasing. I might use this on certain modules or individual files which
were carefully written for this.

Or asking for more aggressive loop unrolling Which could increase code size
but improve performance (or not!).

99.9% the defaults are fine.

------
gnufx
I've skimmed the paper, and I'm not sure what to make of it. Definitely you
need tools, but even basic profiling is a good start and quite rare.
Suggesting changing source code because of the behaviour of a particular
compiler version's optimizer is a bad idea generally, especially without
checking the optimization reports and investigating tuning the available
parameters, like cost models. Optimizers can be quite unstable for good
reasons.

The paper isn't concentrating on what are probably the two most important
performance governors these days, vectorization and fitting the memory
hierarchy, which can make a factor of several difference. ("Your mileage may
vary", of course.) Then it isn't obvious whether comparing different
generations of compilers was even sufficiently controlled; their default
tuning may be for different micro-architectures which were considered the most
relevant at the time. GCC performance regressions are monitored by
maintainers, but I wonder what real optimization bugs uncovered in a
maintained version have been reported as such from this sort of work.

In large scale scientific code, such compiler optimizations may be relatively
unimportant anyway compared with time spent in libraries of various sorts:
numerical (like BLAS, FFT), MPI communication, and filesystem i/o. Or not: you
must measure and understand the measurements, which is what users need to be
told over and over.

------
blopeur
Video :
[https://www.youtube.com/watch?v=YbHzM6bNTXk](https://www.youtube.com/watch?v=YbHzM6bNTXk)

CCTLib - Framework for fine-grained monitoring and execution-wide call path
collection. : [https://github.com/CCTLib](https://github.com/CCTLib)

------
fortran77
Why does this title have a question mark at the end? (The ACM did it -- it was
copied accurately here?)

------
neonate
Pdf:
[https://dl.acm.org/doi/pdf/10.1145/3392717.3392754](https://dl.acm.org/doi/pdf/10.1145/3392717.3392754)

------
zoomablemind
How does this pan out for major sci libraries, like NAG, IMSL/MKL, GSL, BLAS,
LAPACK etc.? Do distributions control the optimization levels used with a
particular compiler, or just make sure it simply passes the tests?

------
ketanhwr
I'm seeing these kind of titles (what every X programmer should know about Y)
quite frequently which seems like the trend of adding "for humans" in front of
library names.

~~~
SketchySeaBeast
Are you saying that we should replace "by {poster}" with "posted with love by
{poster}"?

~~~
wolfgke
Only if there really _is_ love behind it. Otherwise, such a message is
fraudulent.

~~~
SketchySeaBeast
I guess I need to have a talk with the Atom devs about expectations and
boundaries.

