comp.lang.ada
 help / color / mirror / Atom feed
From: g_harrison@vger.nsu.edu ((George C. Harrison) Norfolk State University)
Subject: Re: LRM 4.1.3 paragraphs 17-19
Date: 12 Feb 91 09:48:28 GMT	[thread overview]
Message-ID: <631.27b781ac@vger.nsu.edu> (raw)
In-Reply-To: 2704@sparko.gwu.edu

In article <2704@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> What I figure could start a new thread is this: in your experience, what are
> the sequential Ada constructs that (may) lead to _better_ optimized code
> than the "old way" would?

What do you mean by "_better_ optimized code?"  If you mean what constructs
_might_ lead the compiler to produce more optimized code than the "Brute Force"
methods like in the example of this original posting, I'd agree with your
assessment below.  "Optimized" to programmers generally means what the compiler
(and often the linker) does to make a faster, smaller executable.  These
constructs, I believe, leave their implementations better open to
these optimizations.

> IMHO aggregates, universal assignment (i.e.
> assignment operator for structured types) and universal equality are three
> such things. 


The other kind of optimization is that which saves the programmers time and
makes him/her more effective.  These include generics, separate compilation,
exceptions, overloading, and other supports for abstraction.  The problem is
that this kind of programmer optimization does not necessarily lead to
executable optimization.  

As an example...  Suppose I have a generic package "MATRIX_OPS" that performs
operations on matrices with elements from an instantiated field of elements. 
By using (and "withing") this package I can solve the system of linear
equations "Coefficient_Matrix * Unknowns_Vector = Constant_Vector" by simply
doing    

       Unknowns_Vector := Coefficient_Matrix ** (-1) * Constant_Vector

That CERTAINLY can save a programmer a lot of time, and with some guarantees of
correctness, it will save his/her job.  However, the implementation of the
exceptions involved, the operators * and **, the hidden implementation of the
underlying field, etc. may have been done by someone else with only abstraction
in mind.  

Ada, unlike most other languages, seems to be (or is getting to be) very
programmer-dependent.  That is, as the compilers and program libraries start
maxing out on optimization, then programmers can really take great pride in
using abstractions effectively.  

I hope I havn't changed Mike's change-in-thread topic, but I thought it
important to make a note on the two kind of optimizations.

-- George C. Harrison -------------- || -- My opinions and observations --
---|| Professor of Computer Science  || -- Only. -------------------------
---|| Norfolk State University, ---- || ----------- Pray for Peace -------
---|| 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
---|| INTERNET:  g_harrison@vger.nsu.edu ---------------------------------

  reply	other threads:[~1991-02-12  9:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-02-08  6:34 Ada Test Tools Scott Layson
1991-02-09  2:39 ` LRM 4.1.3 paragraphs 17-19 Joe Vlietstra
1991-02-11 14:57   ` Michael Feldman
1991-02-12  9:48     ` (George C. Harrison) Norfolk State University [this message]
1991-02-12 19:13       ` Michael Feldman
1991-02-12 21:44         ` Billy Yow 283-4009
1991-02-13  4:32           ` Michael Feldman
1991-02-13 16:32             ` jncs
1991-02-15  4:11     ` Jim Showalter
  -- strict thread matches above, loose matches on Subject: below --
1991-02-14  3:41 Michael Feldman
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox