[yoshimi] Re: faster or safer optimization options

  • From: "Nikita Zlobin" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "cook60020tmp" for DMARC)
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Mon, 28 May 2018 19:26:16 +0500

В Mon, 28 May 2018 11:30:59 +0200
Ichthyostega <prg@xxxxxxxxxxxxxxx> пишет:

On 28.05.2018 01:27, Nikita Zlobin (Redacted sender cook60020tmp for
DMARC) wrote:
Current installed version of yoshimi is 1.5.1.1, where i see these
defaults in basic opts: -O3 -ffast-math. Would -Ofast be same as
these two, besides that it adds yet two fortran-specific options?
Also i found, that -ffast-math involves several other options, among
which is -fno-math-errno. Is is already checked, or needs to be?  

by coincidence, I also happened to have a look into package building
and build options these last days. If you use the current Debian
Packaging plus the current CMake-Buildfile, you get yoshimi with
 -O3 -ffast-math  -fomit-frame-pointer -fstack-protector-strong

Funny enough, the more platform optimised variants preconfigured in
the CMake-Build would be

 -march=athlon64 -m64 -O3 -msse -msse2 -mfpmath=sse
   -ffast-math -fno-finite-math-only -fomit-frame-pointer

rsp.

 -march=core2    -m64 -O3 -msse -msse2 -mfpmath=sse
   -ffast-math -fno-finite-math-only -fomit-frame-pointer


If I recall correct, the -fno-math-errno, which automatically is
selected by -ffast-math is known to be the biggest reason for an
performance gain on average, since it allows the optimiser to skip
checks and the overhead for the thread-local error variable.

This brings up another interesting question: Why does the
CMake-Builfile add -fno-finite-math-only to the "better optimised"
setups, but leaves it out from the fallback case, which is

set (BuildOptionsBasic
    "-O3 -ffast-math -fomit-frame-pointer"
    CACHE STRING "basic compilier options"
)

This seems totally counter intuitive for me, since -ffast-math implies
-ffinite-math-only, which means, any checks for infinity and NaN
values can be skipped. An -fno-finite-math-only does *remove* that
additional optimisation. So why to we add an aggressive optimisation
in the fallback/default case, yet explicitly switch it off in the more
specifically optimised cases?


At this point, there should be the standard reminder: we are entering
an extremely slippery ground here. Just adding some optimisation flags
guided by gut feeling comes close to charlatanry.
We all know that the only sensible approach is a rational one, which
means to conduct a measurement series with a selection of the most
common hardwares setups in common practical use. And since in practice
almost no one is in the position to conduct such research, IMHO we
should confine ourselves to setting very generic flags, like -Ofast

Correctness and usability are more important than a superficial
performance gain of 20% (which might even introduce subtle bugs
elsewehre)

-- Ichthyo



PS: Link to the GCC-Onlinedocs

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
Yoshimi source code is available from either:
https://sourceforge.net/projects/yoshimi Or:
https://github.com/Yoshimi/yoshimi Our list archive is at:
https://www.freelists.org/archive/yoshimi To post, email to
yoshimi@xxxxxxxxxxxxx

No, I use gentoo-based distro (calculate) :)
I worried about -fno-math-errno, because gcc man says, that it breaks
behavior for apps, relying to exact conformance to some iso standards.

Btw, imho, cpu-specific cflags don't need to have cpu instruction
flags, which are included automatically by correct -march. Or is it
really?
(at least, this is from gentoo articles about system cflags).

What if there would be separate cmake file, dedicated to contain
options for different cpu configurations... might be useful in case of
different compilers/platforms.
Yoshimi source code is available from either: 
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: