Re: Explicit vs implicit checks (was Pre-condition vs. Post-condition)

[carters@ajpo.sei.cmu.edu (Scott Carter)]

In article <98063@tut.cis.ohio-state.edu> Joe Hollingsworth <holly@cis.ohio-state.edu> writes:
>In article <jls.669368339@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>[ use built-in checking via CONSTRAINT_ERROR rather than explicit test ]
>>Note that in the second case the procedure is faster, since it doesn't
>>have to do the check first. 
>
>I figured I'd see this argument, but I don't buy it.
>
>1) Refering back to Kernighan & Plauger's "The Elements of Programming
>Style," I'll quote another rule:
>
>"Write clearly - don't sacrifice clarity for 'efficiency'."

" - at first, until you find the real cpu burners [if they are localized].
Recode them for efficiency (document it!), so you have more slop to make most
of the code clearer and more maintainable."
POP is an example of a system utility for which the tradeoffs push more for
efficiency than in most of the code (maybe).
>
>
>2) Ok, so you think that the second version of Pop is faster
>because it is not doing the test.  Well there may not be an explicit 
>test, but there sure has to be an implicit one.  The compiler has
>to generate code to test to see if a constraint error needs to be
>raised, i.e. there is run time checking going on here.  And you 
>sure can't use the SUPRESS pragma to get rid of it.

Don't be so sure about this, or assume that the check has the anywhere
near the same cost as the explicit test.  A constraint test for < 0 is
a single instruction in some machines (e.g. TBNDU on the 88000, or
on any machine which has a trap on bit instruction), and further
that instruction has more slop as far as where in the canonical order
it must go compared to the explicit test.

A really snazzy compiler which is inlining Is_empty() might reduce the
explicit check cost down to about three cycles (and introduce a block
boundary), but we just aren't there yet.
>
>Joe 
>holly@cis.ohio-state.edu

Scott Carter - McDonnell Douglas Electronic Systems Company
carter%csvax.decnet@mdcgwy.mdc.com (preferred and faster) - or -
carters@ajpo.sei.cmu.edu		 (714)-896-3097
The opinions expressed herein are solely those of the author, and are not
necessarily those of McDonnell Douglas.