On Sat, May 4, 2013 at 6:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Dharmendar Reddy <dharmareddy84 at gmail.com> writes: > > > There is no CHKMEMQ statements. > > I meant inside the VecScale() implementation. It turns out that > PetscStackCall(), which is used around all BLAS/Lapack functions, among > others, currently includes CHKMEMQ. > > CHKMEMQ walks all allocations to check for memory corruption. It can be > rather time consuming when many objects (or other small allocations) > occur. If you run with '-malloc 0', the performance problem will go > away. When PETSc is configured --with-debugging=0, CHKMEMQ does nothing > unless you pass '-malloc' (so it'll be fast by default in optimized > mode). > > petsc-dev, is this performance degradation of multiple orders of > magnitude really tolerable? Should we turn off malloc checking around > BLAS/Lapack functions unless the user passes an extra flag (but leave > sentinel checking around user functions because that's where almost all > the memory bugs are)? > I was for eliminating these before. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130504/723d583f/attachment.html>
