<div dir="ltr">On Sat, May 4, 2013 at 6:40 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dharmendar Reddy <<a href="mailto:dharmareddy84@gmail.com">dharmareddy84@gmail.com</a>> writes:<br>
<br>
> There is no CHKMEMQ statements.<br>
<br>
I meant inside the VecScale() implementation.  It turns out that<br>
PetscStackCall(), which is used around all BLAS/Lapack functions, among<br>
others, currently includes CHKMEMQ.<br>
<br>
CHKMEMQ walks all allocations to check for memory corruption.  It can be<br>
rather time consuming when many objects (or other small allocations)<br>
occur.  If you run with '-malloc 0', the performance problem will go<br>
away.  When PETSc is configured --with-debugging=0, CHKMEMQ does nothing<br>
unless you pass '-malloc' (so it'll be fast by default in optimized<br>
mode).<br>
<br>
petsc-dev, is this performance degradation of multiple orders of<br>
magnitude really tolerable?  Should we turn off malloc checking around<br>
BLAS/Lapack functions unless the user passes an extra flag (but leave<br>
sentinel checking around user functions because that's where almost all<br>
the memory bugs are)?<br>
</blockquote></div><br>I was for eliminating these before.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>