Re: Polyhedron b'marks | Linux vs Windows

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jun 2, 2014 at 4:28 PM, Evan Cooch <evan.cooch@gmail.com> wrote:
>
>>> So (the question) -- why? I have a couple of ideas, but I was wondering
>>> if there is a short-form 'correct answer' (correct, as in, better than
>>> my 'couple of ideas').
>>>
>>> Thanks in advance...
>>
>> Differences that large would make one suspect you didn't clean out
>> competing Windows processes,
>
>
> Meaning, I suspect, competing OS process, since the Polyhedron benchmark was
> the only user-initiated task. My next experiment will be to run the PB after
> booting Windows straight to the command line (i.e., absolute bare minimum of
> Windows functioning -- more or less 'straight to DOS', in the classical
> sense of a bygone era).
>
>> or you have ridiculously small RAM,
>
>
> 64 GB.  So, probably not this.  ;-)
>
>> or something is wrong with your Windows gfortran.
>
>
> Hmmm --- interesting.  I'm not sure what would be wrong with gfortran under
> Windows that wouldn't also be wrong under GNU/Linux, but, stranger things
> have happened.
>
>> To a smaller extent, your excessive unrolling (as you didn't set e.g.
>> --param max-unroll-times=...) could hurt more on Windows.
>
>
> Easy enough to try -- thanks.
>
>> Failing to set -march=native ought not to incur many differences if both
>> are set the same.  If  -march=native incurs failures, gfortran 4.9 might be
>> a fairer test (assuming it has corrected those failures).
>>
>
> I suppose worth a try.
>
> What is interesting (and largely what motivated my original post) is that I
> have a number of colleagues who report more or less the same thing (and that
> it has been the case since at least gfortran 4.4).

I suspect the main difference is the system supplied math library,
glibc libm in the Linux case and whatever Windows provides.  This
can make a tremendous difference for the benchmarks that call
transcendental functions.

Richard.

>
>
>