Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!uxc!deimos.cis.ksu.edu!unmvax!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.sw.components
Subject: Abstraction vs. optimization?
Message-ID: <5667@hubcap.clemson.edu>
Date: 2 Jun 89 02:26:36 GMT
References: <7037@cbmvax.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 27

From article <7037@cbmvax.UUCP>, by jesup@cbmvax.UUCP (Randell Jesup):
> as the hardware becomes faster, and the programs we write become more 
> complex, we are moving to higher levels of abstraction to keep the 
> complexity from overwhelming us (or making it too expensive to do).  [...]
> We trade off efficiency of execution/size for cost of production 

   While this is certainly true, it should also be kept in mind that
   good optimizing compilers can and should violate levels of abstraction
   in search of improvements.  Telesoft's TELEGEN 2 Ada compiler, for
   example, exploits this extensively in its global optimization mode,
   optimizing across package boundaries by eliminating the aspects of
   general-purpose packages which are not actually used by a particular
   application.  Similarly, all the techniques of interprocedural 
   optimization can be extended to procedures which are separated by 
   impenetrable walls as far as the programmer is concerned, but which 
   live in glass houses from the compiler's point of view.

   It may well be that in large projects, no amount of hand-coding
   will ever result in the levels of efficiency which can result from
   the global optimizations performed by a compiler while still 
   preserving correctness; above a certain point, human cognitive 
   limits force us to abandon hand-coding as a viable technique,
   even assuming that we could afford to continue using it. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu