Re: Checks off for release code - was Re: Size code Ada and C

Re: Checks off for release code - was Re: Size code Ada and C

[Robert I. Eachus]

In article <dewar.899387741@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > One more comment on polls with respect to checks off for the release code.
 > Here again, market input is important. If one found that everyone turns
 > off checks for delivery, then an implementor might decide to put in less
 > effort in removing redundant checks. I think for example that Alsys,
 > anticipating that everyone would keep checks on, put huge effort into
 > removing redundant checks that might have been better expended in retrospect
 > on better optimization in general.

    I've worked on several embedded projects which got to the point of
having the "checks on/checks off" debate.  My usual suggestion was to
recompile with all checks off, and do a quick test.  (Usually this
code obviously failed several key tests.)  At the same time we
profiled the code, then chose particular high CPU time units and did
differential testing to determine the improvement in each from turning
checks off.

   After a week or two, in every case less than a month, we had a
version with checks off in about 5% of the units which outperformed
the version with all checks off.  This eventually became the baseline
for formal testing.

   Usually what we saw was five to ten percent performance changes in
individual units, and by choosing all of the tested units with no
harmful effects from turning checks off and a net positive effect on
the performance, we could get a 3% or so overall performance
enhancement.   About ten to fifteen percent of all units should not be
compiled with checks off because the logic will fail.

   With earlier versions of GNAT, this behavior was skewed by the slow
handling of what used to be Numeric_Errors.  So there were a very few
units compiled with -gnato.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Checks off for release code - was Re: Size code Ada and C

[William Clodius]

Robert Dewar wrote:
> <snip>
> 
> In the Ada 83 world, and in the Ada 95 world, different compilers use
> different approaches here. Why on earth did you choose an Ada 83 compiler
> that used implicit heap allocation? and once you had done so, why on earth
> did you use constructs that caused implicit heap allocation? Sounds like
> a case of the customer not being sufficiently well informed of this issue
> (which is a bit surprising to me, it is an issue that has always been a
> high profile one).
> 
> <snip>

As I understand earlier messages, his team chose a compiler precisely
because it did not use implicit heap allocations, and then the vendor
changed the implementation so that it used implicit heap allocations.
The vendor had "lost sight of the best way". Quoting the earlier
message:

> As an example I give the use of implicit heap allocation in Ada83 compilers.  
> Back in 1983 and 1984 my company compared the few compilers that existed for 
> embedded applications using a given processor.  One of the compilers used heap 
> allocation for unconstrained records; one did not.  We picked the one that did 
> not.

> It might have been the next update to the compiler in which they started using 
> heap.  When we complained, we were told that they had had many complaints that 
> people were getting Storage_Error when they had unconstrained types. ...

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Checks off for release code - was Re: Size code Ada and C

[Tom Moran]

I note in the news once again an internet security hole due to
allowing input data to run off the end of an array.  One assumes this
is C code, not Ada with the checking turned off "because it's been
thoroughly debugged and is correct".