FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: April 3, 2003 3:14 PM
> 
> My background is DOS (not DoS :) ), Windows, Linux ... for O/S and
> BASIC, Pascal, ASM, (C), C++ ... for language. I like 
> performance and I
> prefer the use of assert in DOS/Windows. In DOS/Windows assert are
> disabled by default while in many Unix programs assert are enabled by
> default. 
> This is why I don't like assert that much.

I hope you'll forgive me for trying to change your mind.  :-)

My background is similar.  My first C compiler was from a company called
Computer Innovations.  It was a 4-pass compiler for DOS, translated directly
from the unix to the floppy.  I used to say the compiler was so flexible, it
would compile anything, even English.  It wouldn't *run* of course, but bad
pointers in DOS can produce spectacular video effects if they happen to be
in the vicinty of 0xB0000!  

That compiler included libc source, which we took advantage of: we added '$'
as a format specifier for money to [sf]printf, formatting the output with
commas where God intended them.  Very very helpful, if you're working for a
bank.  Years later, the bank moved to Windows of course, and CI went afaik
out of business, and my old colleagues had to pore over their sources for
every '$' used as a format specifier.  

An early lesson in standards.  

I don't have any negative experience with assert() on any platform; I've
never heard of 4X degradation.  That much would be very hard to explain,
because assert() -- even if enabled -- doesn't do very much.  It's hardly
more expensive than an if statement.  Here's the a bit of the assembly code
generated by gcc for my test program (optimization turned off, comments
mine):  

.L9:
        cmpl $0,-4(%ebp)        ; the comparison
        jl .L10         ; call assert()
        jmp .L11                ; don't call assert()
        .align 4
.L10:
        pushl $.LC0
        pushl $10
        pushl $.LC1
        call __assert
        addl $12,%esp


How can that be costly?  I wonder if what you saw might not have been a
function of compiler optimization settings or a poor compiler
implementation?  

I think a lot rests on what you mean by "enabled by default".  According to
http://www.opengroup.org/onlinepubs/007908799/xsh/assert.h.html, NDEBUG has
been defined to defeat assert() for many years (particularly given that the
standards ratified existing behavior).  We, and many other free software
projects, don't generate Makefiles that define NDEBUG.  Maybe we should, but
I suspect the reason it's not a problem is that assert(), whatever its cost,
is more helpful than not, even in released code.  

Can you measure its effect in this program?

#include <stdio.h>
#include <assert.h>
int main ()
{
        int i;
        for( i=0; i < 1000000; i++) {
                assert(i>=0);
                printf("%d", i);
        }
        return 0;
}

When I time that on my machine, I get 0m16.939s without NDEBUG and 0m16.719s
with.  I'd be interested in contrary data.  

> #if defined(__GNUC__) && __GNUC__ >= 2
> #define COMPILE_CHECK(name,check) \
>     extern int name[(check)?1:-1] __attribute__ ((unused))
> #else
> #define COMPILE_CHECK(name,check) \
>     extern int name[(check)?1:-1]
> #endif

If I were writing a very performance-sensitive application using a compiler
whose handling of assert() was as bad as you say, I would doubtless do
something like that.  Given that the vast majority of FreeTDS users use GNU
gcc, and given that of those that don't most are using competent compilers,
I think we should reward intelligence.  If someone insists on using a
compiler with very bad assert() handling, it's quite trivial to replace the
macro's definition locally.  

(Besides, FreeTDS is not compute-bound except for data conversion.  From the
application's point of view, the server is the slowest thing on four wheels.
Every database application is I/O-bound, at least some of the time.  We've
even seen situations here on the list where changing the packet size made a
huge difference, more than could have been achieved if FreeTDS were made
infinitely fast.)  

Better to adhere to standards and expect them to be adhered to.  Always
assume the other guy knows what he's doing, because that way, you can't be
wrong.  

Regards, 

--jkl



The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.