Re: Run-time checking and speed

[dsmith@clark.net (Doug Smith)]

In article <3f3deb$4us@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> T.E.D. says
> 
> "As for constraint checks, try to leave them in until your product is
> THOROUGHLY debugged. They are worth their weight in gold during the
> debugging phase."
> 
> [snip]
> 
> [snip...]to meet processing efficiency [...] you may have to abandon the
> checks, but do this only when you have to [...snip]
> 
> The penalty of run time checks can run anywhere from 5-50% depending on the
> code. [snip]
> 
> [snip]
> 
> Another situation where it is quite appropriate to turn off run time checks
> is in verified safety critical code where part of the verification ensures
> that the checks are not needed. You have to be *very* sure of your 
> verification technology to depend on this!

OK, some personal experience which has been verified countless times by
fellow engineers. A small percentage (10%) of the code accounts for (90%)
of the processing. In case after case, a dynamic analysis tool identifies
the code executed the most, the engineer optimizes and gets almost an order
of magnitude speed improvement.

In the old days (i.e. early compilers), I measured executable size differences
that showed half of the code was constraint checking (Today's compilers do
a much better job). By redesigning the code to explicitly check for and
raise the correct exceptions, I could then suppress the compiler generated
constraint checking.

Formal verification was helpful in increasing the confidence level of me and my fellow engineers; but since this was not a safety critical application, there weren't many arguments when they saw the performance results.

-- 
Doug Smith
dsmith@clark.net