Fix #423: change -ffast-math to -mtune=native #432
Conversation
|
You should be mindful that this change will break some cluster installations of EGS. For example, many users on our cluster install/compile their own version of EGS in their home area, which is mounted on an NFS partition and shared across a heterogeneous cluster (5 nodes, 3 different generations of CPU architectures). Compiling with march=native will produce a binary that is only "valid" for the CPU architecture of the node that the user was logged in on, not other compute nodes. In this setup, it wouldn't really be possible to compile with different architectures as the binaries would just be overwritten since it's all the same mount. (mtune will work, though I'm curious about the performance penalty of losing ffast-math and only using mtune or doing march=oldest_cpu_in_cluster) I predict many headaches for people in charge of their department's clusters as new users install EGS from the github repo and have code that runs fine interactively but crashes when they submit batch jobs to their cluster. |
|
Very good point @marenaud. Then I suggest settling for |
|
Agreed, alternatively we could also look at which flag is causing issues. According to the gcc website, -ffast-math is equivalent to: If we're lucky, maybe only one of these is causing all the trouble. Not sure I would count on that though... |
|
I would not count on that either! I think |
ftessier
force-pushed
the
fix-fast-math
branch
2 times, most recently
from
b30d5f7
to
2641e83
Compare
|
Just added |
rtownson
changed the title
ftessier
force-pushed
the
fix-fast-math
branch
2 times, most recently
from
b3a7f71
to
d4c5d10
Compare
|
@ftessier this must be also added to the config GUI! |
|
I think it has, see changes in egs_tools.cpp. Can you check if I missed anything? |
Update the default gcc optimization configuration to -mtune=native instead of -ffast-math. The latter causes various floating-point exceptions on newer cpus and compilers. Note that if everything is compiled and run on identical cpu, then the more aggressive -march=native option should be considered during configuration. Change the default optimization level to -O2 instead of -O3. There have been cases where upgrading to a newer compiler revealed bugs under -O3, and more aggressive optimization does not always lead to increased performance. The -O2 option is a better default, and another level can be selected at configuration time. Also add a test in the Fortran compiler version check to catch the gfortran version string, and fix a duplicate echo for the default fortran debugger flag.
ftessier
force-pushed
the
fix-fast-math
branch
from
d4c5d10
to
b41079d
Compare
|
Also changed the default optimization level from -O3 to -O2 |
Update the default gcc optimization configuration to use -march=native
instead of -ffast-math. The latter causes various floating-point
exceptions on newer cpus and compilers. If the programs are run on a
different cpu, then one should use the corresponding -march option for
that architecture instead of "native", or else use the less aggressive
-mtune=native if the compiling and running cpus are in the same family.
The alternatives -march and -mtune were suggested by @Kawrakow in
issue #174.
See also #85, #91, #174, #204 and #423.