Re: [Libmesh-devel] prof -> oprofile method?

[Roy S. <roy...@ic...>]

On Wed, 28 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:

> Agreed it is trivial on trunk, less so on branch -
> contrib/Make.common and examples/Make.common would each need a new
> set of rules, but look at ./Makefile.am

Ah; the utility programs.  That is a bit messy.  No way to refactor it
without giving each utility its own subdirectory, either, is there?
No loops or pattern-matching variable operations in automake?

> If we can all agree a oprofile-verison of meshbcid or
> output_libmesh_version is pretty worthless,

Agreed.  Likewise for gprof or even devel versions; basically if
everything's working right then we want opt for our utilities; if we
feed them a bad input and something breaks then we want full-on dbg.

> METHODS="opt gprof" is not quite as objectionable.

I'd hope not.  I know I'm probably the only one using oprofile, but I
know I'm not the only one who's benefitted from some of the
optimization opportunities it identified.

There's a meta-question here: "should we remove oprof support if only
Roy is directly using it" is just a special case of "should we remove
features with N users which require maintenance of M lines" - surely
the answer for N=1, M=15 is no!?  If not, what's our M for N=2?  For
N=3?

>> Making users set their own CXXFLAGS and CFLAGS, but not their own
>> CPPFLAGS, seems a bit arbitrary.
>
> I don't see it that way.  I'd like to reserve METHODS for changing
> the fundamental nature of the library, not tweaking some compiler
> flags.   Users are still free to modify CPPFLAGS too, but the point
> is opt is no asserts, devel is with asserts, and dbg is asserts plus
> sometimes some pedantic #ifdef DEBUG stuff.

So should we remove every flag in compiler.m4 which doesn't change the
fundamental nature of the library: take out -O2 -felide-constructors
-g -ansi -pedantic -Wall -Wno-long-long -library=stlport4 -qrtti=all
-ftz (and so on) and just leave CPPFLAGS alone as the difference
between debug/devel/opt?

Would the reaction be "thanks for eliminating the maintenance of
hundreds of lines of m4 code" or "why did my stuff stop working
right"?

> As an aside, I've got some application code which really hates -O3
> with intel, but that doesn't warrant a METHOD=less_opt

No, but it might warrant pinpointing that intel version and switching
opt to use -O2 there.  I'm not suggesting that we want METHOD=opt and
METHOD=opt_for_broken_intel support any more than we want
METHOD=opt_intel versus METHOD=opt_gcc support - multiple METHODS are
for situations where you might want to support simultaneous
compilation of the same code with multiple settings.  It's not
common but not unreasonable to want to debug, optimized-run, and
profile the same code.
---
Roy