Re: [Help-gsl] Strange Issue with ODE2

[ƦOB COASTN]

Greetings Brian,

It is surprising that identical binary [producing the failing Skylake
test] when executed on a
Nehalem system passed the ode2 test.

The binary might reference instruction extensions that operate
inconsistently regarding Skylake and Nehalem architectures.

The msvc floating point behavior contains command line specification option:
https://docs.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior

We have options for precise | except | fast | strict.
Perhaps there exists a combination that produces consistent ODE2 results?

Any thoughts?

Thanks,
Rob


On Fri, Jun 23, 2017 at 12:07 PM, Brian Gladman <address@hidden> wrote:
> When building GSL with Visual Studio 2015 or 2017 on my Skylake system
> the ode2 test fails with the result:
>
> FAIL: bsimp/rk4imp robertson [1] (4.80016693154134428e-07 observed vs
> 4.8006653093199183e-07 expected) [1119]
>
> This is odd since the ode2 code hasn't changed in years and it has
> always worked with previous versions of Visual Studio.
>
> In order to try and find the problem, I have been comparing the results
> produced using Visual Studio 2012 on my Nehalem system with those on
> Skylake with Visual Studio 2017.
>
> But this is proving very difficult because the floating point results
> don't compare exactly and just drift slowly apart as the number of steps
> in the solver increase.  This seemed to suggest that the issue is the
> result of differences in the floating point code being generated by the
> earlier and later Microsoft compilers.
>
> Or, that is what I thought after a lot of fruitless effort in trying and
> failing to find the bug.
>
> But yesterday I just happened to run the failing Skylake binary on my
> Nehalem system and was very surprised to find that it passed the ode2
> test!
>
> So a Visual Studio 2017 built ode2 test binary (linked to a GSL static
> library and static MSVC runtime libraries) produces different results
> when run on Nehalem and Skylake processors.
>
> Maybe I am being naive but I wasn't expecting this.  Can anyone here
> suggest what might be going on here?
>
>    best regards,
>
>      Brian
>
>