compiler ignores them and does not
complain when they disagree with the
code; therefore, experienced program-
mers do not trust them either. Docu-
menting assumptions so the compiler
pays attention to them is a much better
strategy. All this “pointless checking”
grinds a certain kind of performance
aficionado up the wall, and more than
one has tried stripping Varnish of all
this “fat.”
If you try that using the standard-
ized -DNDEBUG mechanism, Varnish
does not work at all. If you do it a little
bit smarter, then you will find no rel-
evant difference and often not even a
statistically significant difference in
performance.

Asserts are much cheaper than they used to be for three reasons:

˲Compilers have become a lot smarter, and their static analysis and optimization code will happily remove a very large fraction of my asserts, having concluded that they can never trigger. That is good, as it means I know how my code works.

˲ The next reason is the same, only the other way around: the asserts put constraints on the code, which the static analysis and optimizer can exploit to produce better code. That is particularly good, because that means my asserts actively help the compiler produce better code.

˲ Finally, the sad fact is that today’s CPUs spend an awful lot of time waiting for stuff to come in from memory—and performing a check on data already in the cache in the meantime is free. I do not claim that asserts are totally free—if nothing else, they do waste a few nanojoules of electricity— but they are not nearly as expensive as most people assume, and they offer a very good bang-for-the-buck in program quality.

intentional Programming
In the long term, you should not need
to use asserts, at least not as much as
I do in Varnish, because at the end of
the day, they are just hacks used to pa-
per over deficiencies in programming
languages. The holy grail of program-
ming is “intentional programming,”
where the programmer expresses his
or her exact and complete intention,
and the compiler understands it.
Looking at today’s programming lan-
guages, I still see plenty of time before
progress goes too far and we are no
longer stuck on compilers, but rather
on languages.

Month : Integer range 1.. 12;

 

This could be a pretty smooth and easy upgrade to languages such as C and C++ and would provide much-needed constraints to modern compiler analysis. One particularly strong aspect of this format is that you can save space and speed without losing clarity:

 

Door _ Height: Integer range 150..400;

 

This fits comfortably in eight bits, and the compiler can apply the required offset where needed, without the programmer even knowing about it.

Instead of such increased granu-
larity of intention, however, 22-plus
years of international standard-
ization have yielded <stdint.h>
with its uint_least16_t, to which
<inttypes.h> contributes PRIu-
LEAST16, and on the other side <lim-
it.h> with UCHAR _ MAX, UINT _
MAX, ULONG _ MAX, but, inexplicably,
USHRT _ MAX, which confused even
the person who wrote od( 1) for The
Open Group.

Related articles on queue.acm.org

Reveling in Constraints

Bruce Johnson

http://queue.acm.org/detail.cfm?id=1572457

Sir, Please Step Away from the ASR- 33!

Poul-Henning Kamp

http://queue.acm.org/detail.cfm?id=1871406

Coding Smart: People vs. Tools

Donn M. Seeley

http://queue.acm.org/detail.cfm?id=945135

References

1. dijkstra, e. W. Programming considered as a human activity (1965); http://www.cs.utexas.edu/~e Wd/ transcriptions/eWd01xx/ eWd117.html.

 

Poul-henning Kamp ( [e-mail]) has programmed computers for 26 years and is the inspiration behind bikeshed.org. his software has been widely adopted as “under-the-hood” building blocks in both open source and commercial products. his most recent project is the varnish httP accelerator, which is used to speed up large Web sites such as Facebook.