Elaboration checks

Elaboration checks

[Martin Dowie]

about 15% of our executable appear to be made up of elaboration checks
(this is the size difference after inserting configuration pragma
suppress (elaboration_check)).

this is pushing us over our 50% memory usage requirement. our plan is
now to have 2 builds - one with elaboration checks the other without
(which would become our deliverable). is it true to say that if no
elaboration checks fail in the 'full' build, that our 'small' build is
also safe?

we plan to ensure that each of our packages provides an 'Initialise'
routine to assign package-local initial values. all our tasks currently
block on an 'accept Initialise' already.

anything else we can do?

environment is Rational Apex 3.0.0b (3.2 being evaluated as i type)
targeting PowerPC. Rational have also informed us that we *can not*
switch on any level of optimization as "it won't work"(!).

Re: Elaboration checks

[Robert Dewar]

In article <38A6BB10.560D973A@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> about 15% of our executable appear to be made up of
> elaboration checks (this is the size difference after
> inserting configuration pragma suppress (elaboration_check)).

Sounds like your compiler is doing absolutely NO optimization
of elaboration checks at all, which can indeed lead to pretty
gruesome code. If you used GNAT, then the checking is typically
done at compile time, and you have static safety plus almost no
overhead from elaboration checking.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration checks

[Martin Dowie]

nice plug :-)

i'm not sure that switching compiler vendors this far in will be viewed
with much enthusiasm from the project cost control managers, esp. if we
can do this optimization ourselves...

Robert Dewar wrote:

> In article <38A6BB10.560D973A@dowie-cs.demon.co.uk>,
>   Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> > about 15% of our executable appear to be made up of
> > elaboration checks (this is the size difference after
> > inserting configuration pragma suppress (elaboration_check)).
>
> Sounds like your compiler is doing absolutely NO optimization
> of elaboration checks at all, which can indeed lead to pretty
> gruesome code. If you used GNAT, then the checking is typically
> done at compile time, and you have static safety plus almost no
> overhead from elaboration checking.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Elaboration checks

[Samuel T. Harris]

Martin Dowie wrote:
> 
> nice plug :-)
> 
> i'm not sure that switching compiler vendors this far in will be viewed
> with much enthusiasm from the project cost control managers, esp. if we
> can do this optimization ourselves...

Have you investigated the application of the Apex RCI
(Remote Compilation Integrator). You can use GNAT as
your target compiler and still keep Apex as your
development environment. Once configured, Apex will
perform Code and Link operations using GNAT.

Indeed, you can control any number of other target
compilers and still keep a single development
environment. With the exception of debugging,
all the library and compilation management
functions are performed automagically by Apex.

> 
> Robert Dewar wrote:
> 
> > In article <38A6BB10.560D973A@dowie-cs.demon.co.uk>,
> >   Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> > > about 15% of our executable appear to be made up of
> > > elaboration checks (this is the size difference after
> > > inserting configuration pragma suppress (elaboration_check)).
> >
> > Sounds like your compiler is doing absolutely NO optimization
> > of elaboration checks at all, which can indeed lead to pretty
> > gruesome code. If you used GNAT, then the checking is typically
> > done at compile time, and you have static safety plus almost no
> > overhead from elaboration checking.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Elaboration checks

[Jeff Creem]

Martin Dowie <martin@dowie-cs.demon.co.uk> wrote in message
news:38A6BB10.560D973A@dowie-cs.demon.co.uk...
> about 15% of our executable appear to be made up of elaboration checks
> (this is the size difference after inserting configuration pragma
> suppress (elaboration_check)).
>
> this is pushing us over our 50% memory usage requirement. our plan is
> now to have 2 builds - one with elaboration checks the other without
> (which would become our deliverable). is it true to say that if no
> elaboration checks fail in the 'full' build, that our 'small' build is
> also safe?
>
> we plan to ensure that each of our packages provides an 'Initialise'
> routine to assign package-local initial values. all our tasks currently
> block on an 'accept Initialise' already.
>
> anything else we can do?
>
> environment is Rational Apex 3.0.0b (3.2 being evaluated as i type)
> targeting PowerPC. Rational have also informed us that we *can not*
> switch on any level of optimization as "it won't work"(!).
>

Please someone from Rational please respond to this last sentence.

I have gone around few times the past few years with Rational related
to the size of Apex executables and the speed at which the compiled
code executes. Just when I think that after several years things are getting
better I hear something like this.

 At times in the past I was told I was the only customer who ever complained
about
the poor quality of generated code and that  I had too narrow a focus
 (Yes Mr. Manager, I know it will cost $4000 extra per
delivered unit because we need an extra processor and more RAM and flash
but look at how well Apex is integrated with Clear case...Woops..bad
example,
I mean look at how cheap the tools and support are...Woops...Ok but they are
getting in good with Microsoft these days..That has to be worth something).

Re: Elaboration checks

[Matthew Heaney]

In article <38A6BB10.560D973A@dowie-cs.demon.co.uk> , Martin Dowie 
<martin@dowie-cs.demon.co.uk>  wrote:

> we plan to ensure that each of our packages provides an 'Initialise'
> routine to assign package-local initial values. all our tasks currently
> block on an 'accept Initialise' already.
>
> anything else we can do?

Here's an idea.  Each tack entry consumes run-time resources.  An
Initialize task entry is called only once, yet continues to consume
resources for the duration of the program.

If you're using Ada95, you can get rid of the Initialize entry by using
a Suspension_Object.  This may or may not reduce storage costs (it
depends on how SOs are implemented).

So instead of

package body P is

  task TO is
    entry Init;
    entry E;
  end TO;

  procedure Init is
  begin
    TO.Init;
  end;
...

  task body TO is
  begin
    accept Initialize;
    ...
  end TO;

end P;

You can replace the task entry with a suspension object:

with Ada.Synchronous_Task_Control;  use Ada.STC;
package body P is

  task TO is
    entry E;  -- note no Init entry
  end TO;

  Initialization : Suspension_Object;

  procedure Init is
  begin
    Set_True (Initialization);
  end Init;
...
  task body TO is
  begin
    Suspend_Until_True (Initialization);
  end TO;

end P;


You can also use a protected object, that is shared by all the tasks in
the system:

package Task_Initialization is

  protected Signal is

    entry Wait;

    procedure Send;

  private

    Initialized : Boolean := False;

  end Signal;

end Task_Initialization;


Now instead of every task having its own initialize entry, it simply
waits on the global task initialization signal object:

with Task_Initialization;
package body P is
...
  task body TO is
  begin
    Task_Initialization.Signal.Wait;
    ...
  end TO;

end P;

Now during startup, you only have to call one task initialization signal
object, instead of every task separately.  It's basically a way of
implementing a broadcast in Ada95.

These days, explicit Initialize entries for tasks are rarely necessary.
You can eliminate (all!) task entries by using protected objects, and
you can eliminate protected object entry queues by using suspension
objects.


--
The purpose of the system is what it does.

Stafford Beer

Re: Elaboration checks

[Tucker Taft]

Martin Dowie wrote:
> 
> about 15% of our executable appear to be made up of elaboration checks
> (this is the size difference after inserting configuration pragma
> suppress (elaboration_check)).

You should definitely talk with Rational about this.
If you are placing the suppress pragmas properly, then there
should be no overhead for elaboration checking.
Because the suppress pragmas have relatively "loose" semantics,
some compilers handle them better in certain contexts than in others.
I suspect the engineers at Rational know where to put the
pragma to make sure that all elaboration checks are removed...

For example, it may be essential that the suppress pragma is on
the spec rather than the body, or perhaps on both.  Rational should know.

> this is pushing us over our 50% memory usage requirement. our plan is
> now to have 2 builds - one with elaboration checks the other without
> (which would become our deliverable). is it true to say that if no
> elaboration checks fail in the 'full' build, that our 'small' build is
> also safe?
> 
> we plan to ensure that each of our packages provides an 'Initialise'
> routine to assign package-local initial values. all our tasks currently
> block on an 'accept Initialise' already.
> 
> anything else we can do?
> 
> environment is Rational Apex 3.0.0b (3.2 being evaluated as i type)
> targeting PowerPC. Rational have also informed us that we *can not*
> switch on any level of optimization as "it won't work"(!).

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Elaboration checks

[Robert Dewar]

In article <38A85CC1.8E5DF76@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> You should definitely talk with Rational about this.
> If you are placing the suppress pragmas properly, then there
> should be no overhead for elaboration checking.

But that's what he reported! He said that the program got 15%
smaller once he put in the suppress pragmas, his concern is
with the overhead when the checks are NOT suppressed!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration checks

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <38A85CC1.8E5DF76@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> 
> > You should definitely talk with Rational about this.
> > If you are placing the suppress pragmas properly, then there
> > should be no overhead for elaboration checking.
> 
> But that's what he reported! He said that the program got 15%
> smaller once he put in the suppress pragmas, his concern is
> with the overhead when the checks are NOT suppressed!

Good point.  I totally misread the original posting.

I suppose if there is one check I feel comfortable suppressing
after testing, it is Elaboration Checks, in that they generally
die in every execution of the program (independent of input), or
not at all.

Certainly a static approach to elaboration checks is a direction
we should push for Ada 200X -- perhaps just a standardized library-wide
configuration pragma?

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA