On Nov 28, 2012, at 4:56 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> On Wed, 28 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> Oh hell, I really don't care that much and am willing to add >> oprofile (or was it gprof, or what anyway??) > > Both. oprofile gives much better results when you go through the > hassle (special kernel module and daemon tweaked by root) of setting > it up, but gprof (what we were calling METHOD="prof" or > METHOD="profile" before) is much more widely compatible. > >> I'm mostly interested in doing it just once - I'm hopeful the >> libmesh.automake branch multi-method approach is an agreeable one, > > So far I'm quite happy with it. > >> and I'll do it there. > > Actually, if you're busy I can just do it myself; it's the least I can > do after nagging you so badly, and it'll be a good excuse for me to > better familiarize myself with the new stuff in branch. By all means! $ grep devel_ `find . -name Makefile.am -o -name Make.common -o -name "*.m4" -o -name "*.sh"` $ grep _DEVEL `find . -name Makefile.am -o -name Make.common -o -name "*.m4" -o -name "*.sh"` should show you what you're in for. not too bad, and there's some repetition in that output. Also, if you want to cheat, you can use libcontrib_opt.la when building libmesh_oprofile.la as a stopgap While we can profile contributed stuff, I don't see us rewriting it to optimize. Sufficient to know how long e.g. Metis took. -Ben ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
