error checking macros with optimization

Lisandro Dalcin dalcinl at gmail.com
Fri Nov 23 10:16:27 CST 2007


On 11/23/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>       There are actually two separate concerns: optimized builds and
> error checking.
> --with-errorchecking and --with-debugging I would like to keep them
> separate.

Me too.

> Currently --with-errorchecking has an on or off value and --with-
> debugging has an on or off value
>
> If you are proposing an intermediate --with-errorchecking that simply
> returns the
> error codes that is fine with me.
>
> --with-errorchecking=<on,intermediate,off>

That is exactly what I was thingking about...

> I still want by default --with-debugging=0 to leave on the full error
> checking.

Sorry, I just realized this. Full error checking is alway enabled by
default, unless '--with-errorchecking=0' is passed, even when
'--with-debugging=0' was passed.

Then forget my proposal, I was confused. Sorry for making noise.

> Reason:
> most programmers are morons and develop code with optimization on
> (why? because
> they are dumb as stones and no matter how many times you tell them it
> is a bad idea
> they just ignore it, they prefer to spend hundreds of hours tracking
> down bugs without
> debug symbols then waste 1/1000 of a second on slower code while
> developing.)

That was one of my motivations, and because 'petsc4py' depend on
error-checking for generating Python exceptions.

If error-checking is always enabled by default unless explicitely
disabled, then the current status of things is just perfect for me.

Regards, and sorry again. I had the work figure in my mind.


> On Nov 23, 2007, at 9:25 AM, Lisandro Dalcin wrote:
>
> > I would to propose some changes to error checking macros for
> > optimized builds.
> >
> > 1.- SETERRQXXX: define them as
> >
> > #define SETERRQ[1|2|..](ierr,...)   return ierr
> >
> > 2.- CHKERRQ: define them as
> >
> > #define CHKERRQ(ierr)  if (ierr) return ierr
> >
> > For (1), it should be no performace impact. For (2), the extra check
> > at almost every line of PETSc source code could impact performace, but
> > any of you have a clear idea of how much?
> >
> > --
> > Lisandro Dalcín
> > ---------------
> > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> > Tel/Fax: +54-(0)342-451.1594
> >
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594




More information about the petsc-dev mailing list