Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!usc!petunia!news
From: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <269b7b9d.5643@petunia.CalPoly.EDU>
Date: 11 Jul 90 19:18:53 GMT
References: <268462df> <39400111@m.cs.uiuc.edu> <114@smds.UUCP>
Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407
Lines: 48



In an article rh@smds.UUCP (Richard Harter) wrote:
>We now have to deal with the layering effect...  
>...ordinary programs are often built in
>layers.  Each layer extracts its own toll in overhead.  Moreover this
>toll is not easily spotted or analyzed with ordinary profiling tools.
>One can be nibbled to death by ducks as well as eaten by man-eating tigers.

What you call the "layering effect" is a negative aspect of what is the
otherwise highly desirable goal of decomposition of a problem into
cohesive, loosely-coupled chunks.  The more we can increase the
independence, generality, and ultimately the reusability of our code,
the more advantages we gain in terms of programmer efficiency on the
long term, maintainability, etc.  On the other hand, each layer of
abstraction involves adding a layer of indirection to the code.

>And then there is the question of "Is increased speed worth the effort
>necessary to achieve it?"  It all depends.  My estimate is that the average
>program of size can be speeded up by a factor of 2-10 times.  That seems
>drastic (and surely worthwhile.)  However the next generation of machines
              ^^^^^^^^^^^^^^^^^
>is always cheaper than the current round of optimization.

Creating software that meets the users needs, is robust and
maintainable, and is delivered in a timely manner is worth the overhead
of the ineffeciencies that may be incurred by reuse.  Of course if the
*user's needs* include requirements for response time, throughput, or
other efficiency-related factors, and if the reuse of code doesn't
allow those requirements to be met, then there is reason to address the
issue.  However, when the requirements are met, it isn't correct to say
that it is "surely worthwhile" to hand-optimize a design at the expense
of destroying the abstractions that permit code to be reused.

This brings up the importance of the compiler in being able to do global
optimizations.  This is what is going to save us in the end.  We need to
be able to program at a high level of abstraction, and let the compiler
figure out how to make an efficient executable out of it.

I think rather than bashing the concepts that promise a solution to our
most pressing problems, we should be working towards perfecting the
techniques that will let our machines effectively put these concepts into
practice :^)

-- 
John Dudeck                                 "I always ask them, How well do
jdudeck@Polyslo.CalPoly.Edu                            you want it tested?"
ESL: 62013975 Tel: 805-545-9549                               -- D. Stearns