On Thu, Nov 14, 2013 at 12:55:57AM +0100, Ian Hinder wrote:
This is likely due to the Exact thorn. It also fails on Stampede. I
have added an EinsteinExact version of this test, and this passes on
my laptop, on datura, and on stampede. I propose we remove the Exact
version of this test, since the tested functionality is available in
EinsteinExact, and Exact is anything but…
I agree, we should remove these testsuites after the release.
Why not before the release? It is distracting to have certain tests which fail on some machines; since we know the reason for the failures, and there are other tests which test equivalent functionality, I think we should simplify the testing process and eliminate the Exact tests which are failing for which we have EinsteinExact versions.
Is your workstation optionlist in simfactory? What optimisation settings are you using?
Yes. It's debian.cfg and debian-intel.cfg.
-Ofast
-O3
This uses -O2 without very special options. However, it uses -xHost (to
be general and somewhat fast). According to the man-page this defaults
to -no-prec-div on some systems. Maybe we should add -proc-div to this
option list.
Quote:
With some optimizations, such as -msse2 (Linux* OS) or /arch:SSE2
(Windows* OS), the compiler may change floating-point division
computations into multiplication by the reciprocal of the denominator.
For example, A/B is computed as A * (1/B) to improve the speed of the
computation.
I found this section of the manual page very confusing, but in the end interpreted it differently; i.e. that this would happen with -no-prec-div but not with -prec-div. -prec-div is the default, and it would be very odd for the compiler to make these changes when -prec-div was set. Can you try running one of the tests with -prec-div and with -no-prec-div to check which is being used? There should also be a compiler option to output the effective flags that are being used.
I think -xHost should be fine, and is probably the best way to choose the CPU-specific optimisations; I don't think it changes the numerical results (but compilers can always surprise us!).