gfortran: the good news and the good news

[Hans Horn-2]

Folks,

I've made the jump from gcc3/g77 to gcc4/gfortran on a large C/f77
quantum chemistry project and like to report great success. Not only
does the code compile & link (after a few initial burps) but the
resultant binaries are on average 10% faster while producing identical
results (that is on my Intel core duo laptop under cygwin/WinXP).

gcc (GCC) 4.3.4 20090804
GNU Fortran (GCC) 4.5.0 20091014

Congrats to y'all!!!

These are the optimization flags I used for fortran (basically carried
over from g77):

-O3
-fno-strict-aliasing
-Winline
-fexpensive-optimizations
-finline-functions
-finline-limit=100000
-fstrength-reduce
-fgcse
-fgcse-lm
-fgcse-sm
-funroll-loops
-fforce-addr
-fomit-frame-pointer
-malign-double

Are there any I should NOT be using?
Did I omit any important one?

Kindly,
H.

[Andrew Pinski-2]

On Thu, Nov 5, 2009 at 9:45 AM, Hans Horn <hannes@...> wrote:


> -malign-double

You should not be using that option really. Since it changes the ABI.

Thanks,
Andrew pinski

[Toon Moene-3]

Andrew Pinski wrote:

> On Thu, Nov 5, 2009 at 9:45 AM, Hans Horn <hannes@...> wrote:

>> -malign-double
>
> You should not be using that option really. Since it changes the ABI.

It might not even be necessary anymore.

 From  the man page:

            On x86-64, -malign-double is enabled by default.

Hans didn't mention whether he runs his Core Duo laptop in x86-64 mode
or just plain 32 bit mode (which is soooo last millennium).

Oops - he said "Cygwin/WinXP" - now *that's* Stone Age material ....

--
Toon Moene - e-mail: toon@... - phone: [phone]
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

[Hans Horn-2]

Toon Moene wrote:

> Andrew Pinski wrote:
>
>> On Thu, Nov 5, 2009 at 9:45 AM, Hans Horn <hannes@...> wrote:
>
>>> -malign-double
>>
>> You should not be using that option really. Since it changes the ABI.
>
> It might not even be necessary anymore.
>
> From  the man page:
>
>            On x86-64, -malign-double is enabled by default.
>
> Hans didn't mention whether he runs his Core Duo laptop in x86-64 mode
> or just plain 32 bit mode (which is soooo last millennium).
>
> Oops - he said "Cygwin/WinXP" - now *that's* Stone Age material ....

Toon,

yup - its just plain 32 bit mode (don't I feel like a dinosaur now?).

H.

[Toon Moene-3]

Hans Horn wrote:

> Toon Moene wrote:

>> Oops - he said "Cygwin/WinXP" - now *that's* Stone Age material ....

> yup - its just plain 32 bit mode (don't I feel like a dinosaur now?).

Well, what you *should* feel is the pain that you don't get *another* 20
% performance increase when running your laptop in 64 bit mode (I've
been using laptops like that - under Debian - since mid-2005).

64 bits gives you more integer and floating point registers, SSE
instructions by default (you didn't enable them on your compilation),
hence vectorization (at -O3), etc.

Cheers :-)

--
Toon Moene - e-mail: toon@... - phone: [phone]
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

[Tim Prince-4]

Hans Horn wrote:

> These are the optimization flags I used for fortran (basically carried
> over from g77):
>
> -O3
> -fno-strict-aliasing
> -Winline
> -fexpensive-optimizations
> -finline-functions
> -finline-limit=100000
> -fstrength-reduce
> -fgcse
> -fgcse-lm
> -fgcse-sm
> -funroll-loops
> -fforce-addr
> -fomit-frame-pointer
> -malign-double
>
> Are there any I should NOT be using?
> Did I omit any important one?

Depending on your CPU model and application, -funroll-loops may have
become excessively aggressive.  For Core i7, I limit unrolling to 4, as
well as avoiding flags whose effect I'm not sure of.
-fno-strict-aliasing tells the compiler not to assume that your code is
standard compliant as to overlapping function arguments.

[Janne Blomqvist-3]

On Thu, Nov 5, 2009 at 19:45, Hans Horn <hannes@...> wrote:

> Folks,
>
> I've made the jump from gcc3/g77 to gcc4/gfortran on a large C/f77 quantum
> chemistry project and like to report great success. Not only does the code
> compile & link (after a few initial burps) but the resultant binaries are on
> average 10% faster while producing identical results (that is on my Intel
> core duo laptop under cygwin/WinXP).
>
> gcc (GCC) 4.3.4 20090804
> GNU Fortran (GCC) 4.5.0 20091014
>
> Congrats to y'all!!!
>
> These are the optimization flags I used for fortran (basically carried over
> from g77):
>
> -O3

> -fno-strict-aliasing

Fix the code to not rely on broken aliasing assumptions, and you can
remove this option and potentially go faster.

> -Winline

I'm not sure this does anything with gfortran. Generally, gfortran's
inlining is pretty limited at the moment; the hope is that the
maturing of the whole-file and LTO stuff will improve this area.

> -fexpensive-optimizations

Enabled at levels -O2, -O3, -Os.

No need to specify explicitly

> -finline-functions

Enabled at level -O3.

No need to specify explicitly

> -finline-limit=100000

This _might_ help, or it might not due to increasing cache usage.
Unless I have benchmarks that say otherwise for a particular app with
a particular compiler version, I wouldn't use it. Also note the above
remark about deficiencies in gfortran's inlining functionality.

> -fstrength-reduce

I can't find this in the manual, actually. Perhaps it has been removed.

> -fgcse
> -fgcse-lm

Enabled at levels -O2, -O3, -Os.

No need to specify explicitly

> -fgcse-sm

Not enabled at any optimization level.

Suggests that, again, without specific benchmarks telling otherwise,
might not be a good idea.

> -funroll-loops

This is commonly used for numerical code, OTOH like excessive inlining
it might also make the code larger for little gain.

> -fforce-addr

Not found in the manual; does it do anything?

> -fomit-frame-pointer

Enabled at levels -O, -O2, -O3, -Os.

No need to specify explicitly

> -malign-double

As already mentioned, should not be used since it breaks the ABI.

> Did I omit any important one?

Generally, you shouldn't be using any of these "exotic" non-default
options unless you have benchmarked them. They might, or might not,
help. And of course, the further you stray from the normal -ON
options, the bigger chance for hitting compiler bugs.

You could try

-march=core2 -mfpmath=sse

to see if using SSE math and vectorization (enabled by default at -O3) helps.

-ffast-math

will often make numerical code substantially faster, but _unless_ you
understand what these options do, and how they affect your program,
stay away.

-mrecip

Same issues as with -ffast-math really.

If profiling shows a hot loop, check with

-ftree-vectorizer-verbose=N

that the loop is vectorized, and if not, see if there is a simple way to fix it.

Finally, as you mentioned this is a quantum chemistry program, it's
likely heavily dependent on linear algebra. An optimized BLAS library
can make a huge difference here, if you for some strange reason aren't
using such a thing already.


--
Janne Blomqvist

[Tim Prince-4]

Toon Moene wrote:

> Hans Horn wrote:
>
>> Toon Moene wrote:
>
>>> Oops - he said "Cygwin/WinXP" - now *that's* Stone Age material ....
>
>> yup - its just plain 32 bit mode (don't I feel like a dinosaur now?).
>
> Well, what you *should* feel is the pain that you don't get *another* 20
> % performance increase when running your laptop in 64 bit mode (I've
> been using laptops like that - under Debian - since mid-2005).
>
> 64 bits gives you more integer and floating point registers, SSE
> instructions by default (you didn't enable them on your compilation),
> hence vectorization (at -O3), etc.
>

With one of the sse enabling options (even -march=pentium-m),
auto-vectorization would be enabled under -O3 , even under cygwin.