Avogadro 0.8 branched

Development
#1

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can tell
there are no major issues aside from some funky problems with over
optimisation I think (using -O3 can cause some crashes in the draw tool
here). Personally I don’t think that -O3 is something that should be
used globally as the optimisations are not always safe and that appears
to be the case here. It also often results in larger binaries that don’t
always run faster…

Unless I hear about any major issues I intend to tag the 0.8 branch
tomorrow at noon (EST => GMT-5 I think). I think that it would be worth
backporting fixes to this branch as necessary to make 0.8.1, 0.8.2
releases as necessary. This release will also be placed in Kalzium as a
snapshot to be used in KDE 4.1 in a simplified editor.

Thanks,

Marcus

#2

On Sunday 18 May 2008 02:11:15 Marcus D. Hanwell wrote:

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can tell
there are no major issues aside from some funky problems with over
optimisation I think (using -O3 can cause some crashes in the draw tool
here). Personally I don’t think that -O3 is something that should be
used globally as the optimisations are not always safe and that appears
to be the case here. It also often results in larger binaries that don’t
always run faster…

This makes me react, as in Eigen 2, I am relying heavily on O3. Are you sure
that O3 allows itself to do unsafe things? I thought that it only did costly
(in terms of compilation time and compiler memory usage) things, and also, as
you point out, costly in terms of binary size. Because of the increased
binary size, it is true that in some cases the performance can be lower (e.g.
if code gets flushed out of the CPU’s instruction cache). But in any case I
really didn’t think that O3 would do anything unsafe. From GCC’s man page:

   -O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2
       and also turns on the -finline-functions, -funswitch-loops, -fpre‐
       dictive-commoning and -fgcse-after-reload options.

I don’t see any of these options being unsafe? But yes, it is true that they
increase binary size. In Eigen 2, the function inlining is very important for
performance, as the code consists mainly of deeply nested, trivial functions.

So, if you get instability with -O3:

  1. are you sure that it is not because of some other option you enabled?
    E.g. -ffast-math is certainly unsafe (breaks IEEE754).
  2. if you didn’t enable any unsafe optimization, and drawtool crashes
    with -O3, either you discovered a bug in GCC, or I am wrong claiming that O3
    is safe, or there is a real bug in drawtool. It already happened to me that a
    bug only manifested itself with -O3, e.g. certain bad memory accesses. E.g.
    imagine a situation where a bad memory access becomes “safe” when the bad
    data is deep-copied into a temporary (e.g. as return value of a function) and
    when enabling -O3 this bad data is no longer deep-copied (e.g. the function
    got inlined) and therefore the bad memory access gets exposed.

Sorry for being such an a** (yeah I’m in North America right now so catching
up with the slang) it doesn’t matter to me whether Avogadro packages are
compiled with O2 or O3, I just wanted to clarify that technical point.

Cheers,
Benoit

Unless I hear about any major issues I intend to tag the 0.8 branch
tomorrow at noon (EST => GMT-5 I think). I think that it would be worth
backporting fixes to this branch as necessary to make 0.8.1, 0.8.2
releases as necessary. This release will also be placed in Kalzium as a
snapshot to be used in KDE 4.1 in a simplified editor.

Thanks,

Marcus

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

#3

From: http://www.gentoo.org/doc/en/gcc-optimization.xml

-O3: This is the highest level of optimization possible, and also the
riskiest. It will take a longer time to compile your code with this
option, and in fact it should not be used system-wide with gcc 4.x.
The behavior of gcc has changed significantly since version 3.x. In
3.x, -O3 has been shown to lead to marginally faster execution times
over -O2, but this is no longer the case with gcc 4.x. Compiling all
your packages with -O3 will result in larger binaries that require
more memory, and will significantly increase the odds of compilation
failure or unexpected program behavior (including errors). The
downsides outweigh the benefits; remember the principle of diminishing
returns. Using -O3 is not recommended for gcc 4.x.

I had heard this before… But neither the page itself, or resources
listed below explain why program behaviour would be altered (error).

Tim

On Mon, May 19, 2008 at 3:14 PM, Benoît Jacob jacob@math.jussieu.fr wrote:

On Sunday 18 May 2008 02:11:15 Marcus D. Hanwell wrote:

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can tell
there are no major issues aside from some funky problems with over
optimisation I think (using -O3 can cause some crashes in the draw tool
here). Personally I don’t think that -O3 is something that should be
used globally as the optimisations are not always safe and that appears
to be the case here. It also often results in larger binaries that don’t
always run faster…

This makes me react, as in Eigen 2, I am relying heavily on O3. Are you sure
that O3 allows itself to do unsafe things? I thought that it only did costly
(in terms of compilation time and compiler memory usage) things, and also, as
you point out, costly in terms of binary size. Because of the increased
binary size, it is true that in some cases the performance can be lower (e.g.
if code gets flushed out of the CPU’s instruction cache). But in any case I
really didn’t think that O3 would do anything unsafe. From GCC’s man page:

  -O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2
      and also turns on the -finline-functions, -funswitch-loops, -fpre‐
      dictive-commoning and -fgcse-after-reload options.

I don’t see any of these options being unsafe? But yes, it is true that they
increase binary size. In Eigen 2, the function inlining is very important for
performance, as the code consists mainly of deeply nested, trivial functions.

So, if you get instability with -O3:

  1. are you sure that it is not because of some other option you enabled?
    E.g. -ffast-math is certainly unsafe (breaks IEEE754).
  2. if you didn’t enable any unsafe optimization, and drawtool crashes
    with -O3, either you discovered a bug in GCC, or I am wrong claiming that O3
    is safe, or there is a real bug in drawtool. It already happened to me that a
    bug only manifested itself with -O3, e.g. certain bad memory accesses. E.g.
    imagine a situation where a bad memory access becomes “safe” when the bad
    data is deep-copied into a temporary (e.g. as return value of a function) and
    when enabling -O3 this bad data is no longer deep-copied (e.g. the function
    got inlined) and therefore the bad memory access gets exposed.

Sorry for being such an a** (yeah I’m in North America right now so catching
up with the slang) it doesn’t matter to me whether Avogadro packages are
compiled with O2 or O3, I just wanted to clarify that technical point.

Cheers,
Benoit

Unless I hear about any major issues I intend to tag the 0.8 branch
tomorrow at noon (EST => GMT-5 I think). I think that it would be worth
backporting fixes to this branch as necessary to make 0.8.1, 0.8.2
releases as necessary. This release will also be placed in Kalzium as a
snapshot to be used in KDE 4.1 in a simplified editor.

Thanks,

Marcus

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

#4

On May 19, 2008, at 9:14 AM, Benoît Jacob wrote:

I don’t see any of these options being unsafe? But yes, it is true
that they
increase binary size. In Eigen 2, the function inlining is very
important for
performance, as the code consists mainly of deeply nested, trivial
functions.

Then you may want to do -O2 -finline-functions as your optimization
flags.

  1. if you didn’t enable any unsafe optimization, and drawtool crashes
    with -O3, either you discovered a bug in GCC, or I am wrong claiming
    that O3
    is safe, or there is a real bug in drawtool.

I can say that with plenty of experience, -O3 is sometimes scary.
There are often more GCC bugs with -O3 than at lower levels. Consider,
for example, that GCC bootstraps itself with -O2, but not -O3. The
higher level optimization passes are considerably more complex, and so
it’s much harder to find bugs.

Many of the quantum chemistry packages in fact, have carefully picked
optimization flags to avoid potential optimization bugs. Very few of
them find numerically correct code with -O3 in all GCC versions.
Certainly newer GCC versions are better, though.

Cheers,
-Geoff

#5

On Monday 19 May 2008 15:45:14 Geoffrey Hutchison wrote:

On May 19, 2008, at 9:14 AM, Benoît Jacob wrote:

I don’t see any of these options being unsafe? But yes, it is true
that they
increase binary size. In Eigen 2, the function inlining is very
important for
performance, as the code consists mainly of deeply nested, trivial
functions.

Then you may want to do -O2 -finline-functions as your optimization
flags.

OK, I see. Indeed, probably the only important thing for me in O3 over O2 is
-finline-functions. I will try and benchmark that.

  1. if you didn’t enable any unsafe optimization, and drawtool crashes
    with -O3, either you discovered a bug in GCC, or I am wrong claiming
    that O3
    is safe, or there is a real bug in drawtool.

I can say that with plenty of experience, -O3 is sometimes scary.
There are often more GCC bugs with -O3 than at lower levels. Consider,
for example, that GCC bootstraps itself with -O2, but not -O3. The
higher level optimization passes are considerably more complex, and so
it’s much harder to find bugs.

Many of the quantum chemistry packages in fact, have carefully picked
optimization flags to avoid potential optimization bugs. Very few of
them find numerically correct code with -O3 in all GCC versions.
Certainly newer GCC versions are better, though.

OK, I trust your experience. I don’t understand what -fgcse-after-reload
really does, perhaps that is what makes O3 dangerous. I could also understand
that -fpredictive-commoning might be done wrong.

Thanks for your replies,
Benoit

#6

I agree with you and Tim : moreover, the speed gain is almost
negligible, even for very long QM calculations. Even for Fortran
codes.

Cheers,
Louis

Le 19 mai 08 à 15:45, Geoffrey Hutchison a écrit :

On May 19, 2008, at 9:14 AM, Benoît Jacob wrote:

I don’t see any of these options being unsafe? But yes, it is true
that they
increase binary size. In Eigen 2, the function inlining is very
important for
performance, as the code consists mainly of deeply nested, trivial
functions.

Then you may want to do -O2 -finline-functions as your optimization
flags.

  1. if you didn’t enable any unsafe optimization, and drawtool crashes
    with -O3, either you discovered a bug in GCC, or I am wrong claiming
    that O3
    is safe, or there is a real bug in drawtool.

I can say that with plenty of experience, -O3 is sometimes scary.
There are often more GCC bugs with -O3 than at lower levels. Consider,
for example, that GCC bootstraps itself with -O2, but not -O3. The
higher level optimization passes are considerably more complex, and so
it’s much harder to find bugs.

Many of the quantum chemistry packages in fact, have carefully picked
optimization flags to avoid potential optimization bugs. Very few of
them find numerically correct code with -O3 in all GCC versions.
Certainly newer GCC versions are better, though.

Cheers,
-Geoff

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

#7

Benoît Jacob wrote:

On Sunday 18 May 2008 02:11:15 Marcus D. Hanwell wrote:

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can tell
there are no major issues aside from some funky problems with over
optimisation I think (using -O3 can cause some crashes in the draw tool
here). Personally I don’t think that -O3 is something that should be
used globally as the optimisations are not always safe and that appears
to be the case here. It also often results in larger binaries that don’t
always run faster…

This makes me react, as in Eigen 2, I am relying heavily on O3. Are you sure
that O3 allows itself to do unsafe things? I thought that it only did costly
(in terms of compilation time and compiler memory usage) things, and also, as
you point out, costly in terms of binary size. Because of the increased
binary size, it is true that in some cases the performance can be lower (e.g.
if code gets flushed out of the CPU’s instruction cache). But in any case I
really didn’t think that O3 would do anything unsafe. From GCC’s man page:

   -O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2
       and also turns on the -finline-functions, -funswitch-loops, -fpre‐
       dictive-commoning and -fgcse-after-reload options.

Being a developer for Gentoo and observing many new bugs and unstable
systems when everything is compiled with -O3 I in general do not believe
it is worth it. I just had -O3 using GCC 4.2.2 using your RELEASE_MODE.
I tracked the issue and it looks like it was -O3 causing the issues - I
do use x86_64 here and not x86.

I would just turn on the compiler options you want. I don’t have all the
links, Tim has pointed out a few, but using -O3 globally is often not
advisable and Gentoo has found that it often causes errors that are
likely compiler issues. I have changed our build scripts but I would
much rather you just turned on the compiler function you wanted and
would be happy to add -finline-functions to our CXXFLAGS when in release
mode.

Hope that helps. If you know better certainly let me know. There may
well still be bugs in the draw tool too - AddHydrogens is quite strange
in that it locks the app if I try to put a write lock around it. I think
we are in good shape to tag though. Just wasn’t feeling too good over
the weekend and so was less productive than I had hoped. Also got caught
up in what are probably compiler bugs.

Thanks,

Marcus

#8

On May 19, 2008, at 9:58 AM, Benoît Jacob wrote:

OK, I trust your experience. I don’t understand what -fgcse-after-
reload
really does, perhaps that is what makes O3 dangerous. I could also
understand
that -fpredictive-commoning might be done wrong.

Remember that in different GCC versions, different optimizations are
enabled. So ‘-O3’ is shorthand for a set of optimization passes which
may differ from version to version. One difficulty for GCC in general,
is that the higher degrees of optimization make it much harder for
developers to track down bugs.

Some amounts of inlining happen at lower optimization levels too.

I’d be sure to not only BENCHMARK eigen, but also test that results
are correct at given optimization levels.

Cheers,
-Geoff

#9

On Monday 19 May 2008 16:37:58 Geoffrey Hutchison wrote:

I’d be sure to not only BENCHMARK eigen, but also test that results
are correct at given optimization levels.

Yes. So far, tests have been succeeding regardless of the optimization level
and compiler version (gcc 3.x, gcc 4.x, icc, msvc).

Cheers,
Benoit

Cheers,
-Geoff

#10

Hi Marcus,

thanks for the explanation, now i understand that O3 wasn’t a good idea.
Somehow I got an habit of using it without thinking about it, and it hadn’t
bitten me so far.

Cheers,

Benoit

On Monday 19 May 2008 15:59:14 Marcus D. Hanwell wrote:

Benoît Jacob wrote:

On Sunday 18 May 2008 02:11:15 Marcus D. Hanwell wrote:

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can tell
there are no major issues aside from some funky problems with over
optimisation I think (using -O3 can cause some crashes in the draw tool
here). Personally I don’t think that -O3 is something that should be
used globally as the optimisations are not always safe and that appears
to be the case here. It also often results in larger binaries that don’t
always run faster…

This makes me react, as in Eigen 2, I am relying heavily on O3. Are you
sure that O3 allows itself to do unsafe things? I thought that it only
did costly (in terms of compilation time and compiler memory usage)
things, and also, as you point out, costly in terms of binary size.
Because of the increased binary size, it is true that in some cases the
performance can be lower (e.g. if code gets flushed out of the CPU’s
instruction cache). But in any case I really didn’t think that O3 would
do anything unsafe. From GCC’s man page:

   -O3 Optimize yet more.  -O3 turns on all optimizations specified

by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpre‐
dictive-commoning and -fgcse-after-reload options.

Being a developer for Gentoo and observing many new bugs and unstable
systems when everything is compiled with -O3 I in general do not believe
it is worth it. I just had -O3 using GCC 4.2.2 using your RELEASE_MODE.
I tracked the issue and it looks like it was -O3 causing the issues - I
do use x86_64 here and not x86.

I would just turn on the compiler options you want. I don’t have all the
links, Tim has pointed out a few, but using -O3 globally is often not
advisable and Gentoo has found that it often causes errors that are
likely compiler issues. I have changed our build scripts but I would
much rather you just turned on the compiler function you wanted and
would be happy to add -finline-functions to our CXXFLAGS when in release
mode.

Hope that helps. If you know better certainly let me know. There may
well still be bugs in the draw tool too - AddHydrogens is quite strange
in that it locks the app if I try to put a write lock around it. I think
we are in good shape to tag though. Just wasn’t feeling too good over
the weekend and so was less productive than I had hoped. Also got caught
up in what are probably compiler bugs.

Thanks,

Marcus

#11

Hi List,

I thought I’d update you now that I experimented a little more, with Eigen 2
benchmarks.

a) When I was relying on the compiler to spontaneously inline functions, -O3
was much faster than -O2. Now that I added a lot of “inline” keywords to
Eigen, -O2 is just as fast as -O3.

b) -O2 -finline-functions is actually slower than -O2 (!!!)

c) -O1 is 2-3x slower than -O2. With no optimization at all, it is really
unbearably slow.

d) Debug information (-g) almost doesn’t slow down things at all.

e) Removing asserts (-DNDEBUG or -DEIGEN_NO_DEBUG) almost doesn’t increase
speed, unless one does a lot of individual-coeffs access, and even there
Eigen provides alternate methods not doing asserts.

This all means we really can optimize AND still have debug info. Something
like -O2 -g gives almost optimal speed and still get full debugging.

Cheers,
Benoit

On Monday 19 May 2008 19:47:28 Benoît Jacob wrote:

Hi Marcus,

thanks for the explanation, now i understand that O3 wasn’t a good idea.
Somehow I got an habit of using it without thinking about it, and it hadn’t
bitten me so far.

Cheers,

Benoit

On Monday 19 May 2008 15:59:14 Marcus D. Hanwell wrote:

Benoît Jacob wrote:

On Sunday 18 May 2008 02:11:15 Marcus D. Hanwell wrote:

Hi,

Just to let you know that Avogadro 0.8 is branched now. Any fixes for
the 0.8 release should be merged into this branch. As far as I can
tell there are no major issues aside from some funky problems with
over optimisation I think (using -O3 can cause some crashes in the
draw tool here). Personally I don’t think that -O3 is something that
should be used globally as the optimisations are not always safe and
that appears to be the case here. It also often results in larger
binaries that don’t always run faster…

This makes me react, as in Eigen 2, I am relying heavily on O3. Are you
sure that O3 allows itself to do unsafe things? I thought that it only
did costly (in terms of compilation time and compiler memory usage)
things, and also, as you point out, costly in terms of binary size.
Because of the increased binary size, it is true that in some cases the
performance can be lower (e.g. if code gets flushed out of the CPU’s
instruction cache). But in any case I really didn’t think that O3 would
do anything unsafe. From GCC’s man page:

   -O3 Optimize yet more.  -O3 turns on all optimizations specified

by -O2 and also turns on the -finline-functions, -funswitch-loops,
-fpre‐ dictive-commoning and -fgcse-after-reload options.

Being a developer for Gentoo and observing many new bugs and unstable
systems when everything is compiled with -O3 I in general do not believe
it is worth it. I just had -O3 using GCC 4.2.2 using your RELEASE_MODE.
I tracked the issue and it looks like it was -O3 causing the issues - I
do use x86_64 here and not x86.

I would just turn on the compiler options you want. I don’t have all the
links, Tim has pointed out a few, but using -O3 globally is often not
advisable and Gentoo has found that it often causes errors that are
likely compiler issues. I have changed our build scripts but I would
much rather you just turned on the compiler function you wanted and
would be happy to add -finline-functions to our CXXFLAGS when in release
mode.

Hope that helps. If you know better certainly let me know. There may
well still be bugs in the draw tool too - AddHydrogens is quite strange
in that it locks the app if I try to put a write lock around it. I think
we are in good shape to tag though. Just wasn’t feeling too good over
the weekend and so was less productive than I had hoped. Also got caught
up in what are probably compiler bugs.

Thanks,

Marcus