Re: [boost] C++ Performance

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-11-26 04:39:34

On 11/25/07, Lars Gullik Bjønnes <larsbj_at_[hidden]> wrote:
> Stefan Seefeld <seefeld_at_[hidden]> writes:
>
> | Lars Gullik Bjønnes wrote:
> >
> >> Which brings be to a nother point: It is _very_ bad of a library to
> >> require of the application to define NDEBUG to work properly.
> >> (The application should be able to decide for itself how NDEBUG/assert
> >> should be used.)
> >> Ublas should stop using NDEBUG and create their own BOOST_UBLAS_DEBUG
> >> or similar and use that instead.
> >
> | Are you saying library code may not use the standard 'assert' macro,
> | then, at least not in headers ?
> >
> | I don't quite agree with your statement. In fact, whenever you are using
> | libraries that are mostly implemented in headers, it becomes very hard
> | to encapsulate behavior the way you seem to request.
>
> Still, forcing the application to not be able to use standard assert
> as it'd like is not really acceptable.

Amen to that! We are using using ublas in some important production code and
we have to compile the entire application with NDEBUG, even if we (and
external libraries) have important assert code that we would like to
keep even on a running system. Unfortunately the sparse vector
functionality in ublas in 1.32 doesn't even compile with NDEBUG not
defined (and even if it did it would have abissimal performance).

I think that NDEBUG should only be used for checks that are meant for
production use (i.e. they won't slow down your program more than 5%).
I like a lot that boost::shared_ptr and boost optional assert when
deferencing in debug builds, and the cost is so small that I like to
keep it even for production builds.  For example the standard libary I
use  doesn't force you to use the checked iterators variant if you
build with assert on: you have to use another explicit preprocessor
define.

>
> And if I am not mistaken something similar to my imagined
> BOOST_UBLAS_DEBUG is used for almost all other boost libraries.
> (At the very least the do not use NDEBUG as a switch for anything)
> (I see that other libs also use NDEBUG/ASSERT, and think that too is
> bad. But for ublas the implications are a lot worse. 3 magnitudes of
> performace is not to shrug at.)

In my experience the use of assert (or BOOST_ASSERT) in all other boost
libraries has been very well thought out. I never felt the need to
explicitly disable asserting for a specific library for performance
reasons.  The only offender so far has been ublas.

--
gpd