[petsc-dev] PETSc-3.4 PR open at https://github.com/Homebrew/homebrew-science/pull/343

Jed Brown jedbrown at mcs.anl.gov
Sat Oct 12 17:10:25 CDT 2013


Aron Ahmadia <aron at ahmadia.net> writes:

> On Sat, Oct 12, 2013 at 5:18 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>  It would be nice to have a
>> systematic (or at least recommended) place to put that debug library.
>
> /usr/lib/debug
>
> Is standard in Fedora and Debian, good enough for me.

Oh, this is just a place for an identical library built using -O0 -g?

> Here's an interesting discussion on Debian on where this is going in
> the future (automated creation of debug libraries):
> https://wiki.debian.org/AutomaticDebugPackages
>
> PETSc is in an interesting situation because the package itself has
> different levels of "optimizations".  If I recall correctly, the input
> validation only adds overhead on the order of 5%.  I'd suggest leaving
> that in to a prefix build, then stripping/splitting symbols into a
> debug library, as the rest of the open source world seems to be doing.

I was broadly including things like walking the heap to check that all
sentinels are intact after each function evaluation.  It's actually big
overhead, and when combined with the difference between -O2 and -O0,
amounts to 5x or more.  Our debug builds also affect some macros in the
headers that users may be using.  For example, PetscFunctionBegin /
PetscFunctionReturn logs a stack so that PETSc's signal handler can
provide a stack trace (without assistance of a debugger).

Debugging symbols are much more about disk space than performance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131012/8d652e3a/attachment.sig>


More information about the petsc-dev mailing list