🚀 go-pugleaf

In article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:

   my experience so far has been that the more general a component is, the
   slower it runs.  for example, given a routine to sort objects, you have
   to give it a criteria.  somehow, the sorting routine has to make a
   function call to compare two elements.

Not necessarily true.  Given a good enough development system, the
compiler can inline the function call (even to the point of it
becoming a single machine instruction!).  This leads to a slower
compile, so for test runs it's easier to leave the function call in
(at the expense of speed).

   for another example, some languages have arrays as their basic data
   unit. "+" becomes an array operator.  but if all you need to do is add
   two scalar quantities, you're hit with a performance penalty.

I don't know any languages with arrays as their basic data type (maybe
APL?).  In most languages where "+" can be used on arrays, it's
just overloading, and the compiler generates the appropriate code
based on the type of the objects.

   [ trends have been largely toward larger, more complex components, both
     in software and hardware ]

   but recently, the hardware trend has reversed -- use very simple
   components, with a much more complicated "compile" phase; let the
   compiler have access to all sorts of little details it didn't have
   before. (i'm referring to RISC of course.)

Well, there are problems with this.  Take an HP-9000, which doesn't
have an integer multiply instruction (DISCLAIMER: at least, it didn't
when I read a paper on it, if I'm thinking of the right machine).  Now
suppose that somebody comes up with an extremely fast (hardware)
integer multiplication unit.  No programs will take advantage of it,
because they're all compiled into code to do repeating additions.
  Similarly on the software end of things, it makes sense to abstract
the function of a component at as high a level as possible, so that
new algorithms can be effectively used with existing software.  (Of
course, it's also important to make the components flexible, which
complicates things somewhat.)

   there's still a lot of room for growth in compiler technology,
   particularly with global optimization, but this is assuming a few
   things: 

   1) the compiler needs to have access to the source code for the
   component you're using. [ thus purchased components are a problem ]

No, you don't need source code.  You need some kind of intermediate
form, though.  A generalized RTL, perhaps.

   2) the additional time required for the compile phase isn't a problem.

You only need to do global optimization when producing the final
version.  Development versions can probably get by with only local
optimization.

   3) ability to recompile everything that uses a component if the
   implementation of a component changes, even if the interface remains the
   same.

This is a problem.  However, if you're storing the intermediate code
(see my response to point 1), you don't need to do a full compilation:
just the optimization (admittedly slow).  Code generation can be done
ahead of time, essentially.

   with the current trends in hardware and software (backlog of software
   applications, steady and fairly rapid growth in processing capability
   per cost), saving time building the application is more important than
   reducing the running time of the application.  

I think this is true.  It can take two or three years to build a
fairly small microcomputer program, where the difference between (say)
5 minutes and 10 minutes to generate a report can be annoying, but not
critical (in many applications).

   but my experience on applications has led to the conclusion that a lot
   of performance is being sacrificed for the decrease in application
   building time.

Depends.  Using 4GL, object-oriented, etc. tends to hurt performance,
at least in my experience.  But I spent a few years working at a place
with a nice component library (based around VAX Pascal), and we never
had performance problems.  Going to new languages (4GL/OO) seems to
hurt performance if you don't have specialized hardware, especially
when the compilers aren't well-done.
  The first version of TeleSoft Ada I used took 15 minutes or so to
compile a small program, and execution time was over three minutes for
the 8-queens (if I'm remembering right).  The last version of it I've
used took about 10 seconds to compile, and executed in 3 seconds.  It
takes a while for compiler technology to catch up.

   do others agree that this is a problem in the software industry, or it
   is just me?  if it is a problem, how should we face it and fix it
   before it becomes worse?

Which problem?  Performance?  I don't think it's a serious problem yet
(then again, most companies haven't switched to 4GL or whatever yet).
I think people need to start spending a *lot* more time figuring out
what they need in environments and languages than they are right now.


		Anton

+---------------------------+------------------------+-------------------+
| Anton Rang (grad student) | "VMS Forever!"         | VOTE on	         |
| Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! |
+---------------------------+------------------------+-------------------+
| Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu".   |
+---------------------------+------------------------+-------------------+

I'll read this group for a while.  It was beginning to sound like an
Ada buzzword group for a while.  (Sorry, I once came from big software
projects, and I'm feeling punchy.)

In a nice article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu 
by Michael Zehr:

>Most of the discussion so far seems to be directed at retrieving
>components, but there's been very little said about using them.
>
>background: i haven't done any programming in ADA, so if there's a
>definition of component that only applies to ADA, i don't it.  i'm
>basing this on my "feel" of component -- namely a group of code that's
>intended to for reuse.  

Any tool which is so specialized that it can't be used with any other
language has serious problems.  It would deserve to die quietly
in a corner (there are exceptions of course).  The problem with SOME of
the Ada people (those that don't code, but manage) is that they expect
their programmer's language to solve all of THEIR problems.

>my experience so far has been that the more general a component is, the
>slower it runs.

This is part of the reason why Unix developed.  No Unix flame wars please.
See my defense below.  The point is we see that performance is sort of
the main reason for using computers (not completely).

>for another example, some languages have arrays as their basic data
>unit. "+" becomes an array operator.  but if all you need to do is add
>two scalar quantities, you're hit with a performance penalty.

Small point of order: this is typically a compilation, not an execution
time function, you you are typically not penalized for this.  (Called
overloading, neat stuff.)

>so far, the trend has largely been towards larger and larger components:
> ..... abstraction from s/w to h/w
>
>hardware trends have been similar: emergence of CISC
>
>but recently, the hardware trend has reversed -- use very simple instructions
>(i'm referring to RISC of course.)

You are not alone in thinking about this.  The problem is: How to
build something that has never existed before?  I am refering to tools.
The problem is the management of complexity.  We are discussing this
in a local ACM/SIGGRAPH group, we call it TIGSV: Technical Interest Group
in "Scientific Visualization" [here's a buzzword I can introduce]....

Components are one thing, reuse is another.  There is the issue of
making them and maintaining them.  In the Beginning, there were scientific
libraries (seems the reuse-people forgot about these, oh well, how else
to go from stone wheel to steel-belted radials).  Now, these were good.

The came Unix and its software tools philosophy.  I began as an MVT hacker.
And at first it was strange to me.  People mistook the command (filenaming)
as bad and discarded without seeing and understanding the functionality
[BTW: LISP has goods as well, but not as wide spread].  They also created
other problems based on their closed, non-flexible  thinking about computers.

It was a philosophy of minimalism, but it was a simple, but very subtle,
logical next step.  See to use libraries, you had to edit, compile,
and then link a call to usage.  Unix introduced co-routines and parallelism
for the masses (and other things).  So instead of edit, compile, link, run,
you did:
	troff filename or to an extreme:
	chem filename | pic | refer | tbl | eqn | troff
Yes you learn a lot of commands, but then we want to do lots with computers.
You can learn lots of little commands or learn lots of little options.
But each of the above only takes a few minutes to learn (except troff
or tex, or Scribe, etc.... ok a generalization) [this is the learning problem]
But getting back, its not just text.  It graphically started as
	graph | plot
but if you wanted more you could do
	spline | graph | plot and so on.
This is actually better documented in two of CACM's Jon Louis Bentley
Programming Pearls column a couple of years back.  Unfortunately neither
appeared in the books PP or More PPs.  The one column was entitled:
Little Languages (Aug 86) and the other was a face off by two guest
Oysters: Don Knuth and Doug McIlroy (June 86).  The latter column is the more
important.  I recommend them if you have not read them.

Then there was the Xerox/SRI ARC/Apple/NeXT line of work.  This looks
good.  How can 10K words say it? ;)

So what's next?  THAT is where the real challenge is.  I think it
will have to deal with parallel architectures.  But there are some major
intellectual hurtles there.  Using Sequents and Crays and Connection Machines
are kind of neat in this regard.  Its the limits of Silicon.  Its only
going to get harder before it gets easier.

>saving time building the application is more important than
>reducing the running time of the application.  
>but my experience on applications has led to the conclusion that a lot
>of performance is being sacrificed for the decrease in application
>building time.
>
>do others agree that this is a problem in the software industry, or it
>is just me?  if it is a problem, how should we face it and fix it
>before it becomes worse?
>
>(sorry for the length of this)

True. (on time and loss of some performance, by faster machines.)
You cannot expect gains in performance and functionality at this time
with combined gains in both hardware and software.  Just ask Xerox
or Apple or NeXT.  There are many similar analogies in the physical world.

The real question is how much a user, builder is willing to change.
Change is what software is all about.

You have no reason to be sorry,  you only get rid of those short-sighted,
short-attention spanned people which our country is so notorious for
producing (bad managers). ;)

Longish signature follows "Type 'n' now"

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

From article <11293@bloom-beacon.MIT.EDU>, by tada@athena.mit.edu (Michael Zehr):
% my experience so far has been that the more general a component is, the
% slower it runs.  for example, given a routine to sort objects, you have
% to give it a criteria.  somehow, the sorting routine has to make a
% function call to compare two elements.  (in a recent article, someone
% said that this is how they'd like to see a sorting routine
% implemented.  that function call can DOUBLE the time it takes to
% perform a sort!)

    Depends on the quality of the compiler being used...

> for another example, some languages have arrays as their basic data
> unit. "+" becomes an array operator.  but if all you need to do is add
> two scalar quantities, you're hit with a performance penalty.

    Ada allows you to "overload" operators; thus, "+" can be defined
    both as an array operator and as an integer operator, as well as
    any other types you are capable of dreaming up.  The precise function
    to be applied is determined at compile time, through analysis of the
    types of parameters involved.  Thus, algorithms optimized for one data
    types can coexist with algorithms optimized for other data types.

> 1) the compiler needs to have access to the source code for the
> component you're using.  no problem if you built all the components
> (although it might mean having to open several 1000 files to look at all
> the components!) but if you're using components produced by someone else
> and sold as a package, you won't have this option.  (it also impinges
> on the abstraction level which the component is supposed to be hiding.)

   Not necessarily.  The vendor can provide you with a sublibrary which
   contains the vended components in compiled form, compiled under global
   optimization mode.  The knowledge of the component is stored in the
   compiler's "notes" which were encoded into the sublibrary.  When it is
   time to globally optimize the final product, the compiler reads its notes
   in order to obtain the relevant information, and finally the binder binds
   everything together, and you're done.  No source code required; you just
   have to specify to the vendor which Ada compiler you're using.
 
> 3) ability to recompile everything that uses a component if the
> implementation of a component changes, even if the interface remains the
> same.

   This isn't necessary if the interface remains the same.  Just
   re-bind the executables; no recompilation required.  (In Ada, at least)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

In article <3579@eos.UUCP>, eugene@eos.UUCP (Eugene Miya) writes:
> In a nice article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu 
> by Michael Zehr:
> >saving time building the application is more important than
> >reducing the running time of the application.  
> >but my experience on applications has led to the conclusion that a lot
> >of performance is being sacrificed for the decrease in application
> >building time.
> >
> >do others agree that this is a problem in the software industry, or it
> >is just me?  if it is a problem, how should we face it and fix it
> >before it becomes worse?
> 
> True. (on time and loss of some performance, by faster machines.)
> You cannot expect gains in performance and functionality at this time
> with combined gains in both hardware and software.  Just ask Xerox
> or Apple or NeXT.  There are many similar analogies in the physical world.
> 
> The real question is how much a user, builder is willing to change.
> Change is what software is all about.
> 
> You have no reason to be sorry,  you only get rid of those short-sighted,
> short-attention spanned people which our country is so notorious for
> producing (bad managers). ;)


EXTREMELY true!! A recent project I worked on had exactly this problem.
The project was years underway, and "almost" to beta, before someone
noticed "hey! this runs like a slow, fat pig!" So a performance czar
was appointed to magically fix everything. Naturally, he didn't since
the problems were built in to the design methodology. The attitude during
construction was "let's make it run; we can make version 1.1 run fast."
In spite of trying to get it shipped ASAP, we designed almost everything
from scratch, rather than using anything off-the-shelf that might save
us development time. This ended up contributing to our demise...

At this same company, after at least 10 years in the software business,
management (at least a small part of mgmt) was convinced that maybe we
ought to have a software library so the technology we created for one
project could be transferred to the next. This idea also died.

BTW, for an interesting perspective on those short-sighted, short attention
span bad managers, this month's Scientific American had another good article
on the state of american manufacturing and industry. One of the authors'
main points was that business today does not look toward long-term gains
and productivity, but toward short-term make a fast buck. While the article
covered all businesses, the analogy to much of today's s/w engineering is
obvious. How many times is the first (if not ONLY) priority to GET IT
SHIPPED! How ironic that these same managers often can't see the utility
in reusing existing tools.

Well, I've rambled long enough. Gotta earn that paycheck somehow...

Andrew L. Duane (JOT-7)  w:(508)-685-7200 X122  h:(603)-434-7934
Samsung Software America	 decvax!cg-atla!ginosko!duane
1 Corporate Drive			  uunet/
Andover, MA.   01810

Only my cat shares my opinions, and she's still learning "lint".

A couple more thoughts (from sitting in a meeting) and a clarification:
Clarification:  oh, I forgot to mention the really neat thing I thought
about Unix software tools was they kept much of the library function
while also being executable programs.  There was the spline program
and the spine function.  Few systems do that, and it also lacks what
others call "user friendly interfaces"  in favor of getting the job done.

The thoughts:  I was thinking about tool (component success)
and these go for hardware as well as software:
1) very important is who gets out there first.
2) cost, cheap, free-ware
3) good reasonable quality

Sort of in this order.  Consider we are still using Fortran, Cobol, etc.
I contact Backus about once every 6 months and it totally amazes him
Fortran is still alive ;) (it's neat, one can ask him "why column major?"
and he comes back and says "Oh, 704 storage handling, easy to check ends of
rows in H/W.").  Witness the success of Convex being the first in that
market place (and FPS).  Being first defines the terminology, creates the
concept, sets the standards. (timing is important, too, you can be too far
ahead).

Cheap free software (hardware): that's how Unix made it $150 for the first
licenses to Universities.  I think Steve Jobs noted how powerful and incentive
this was.  Contrast that to certain LISP AI packages held by companies,
as well as specialized programs.  Can you imagine paying $100K for such
a package?  (Hope so, short of custom software.)  This BTW is what separates
CS from other sciences, no communications without cost.  If you want
to succeed, make it free or cheap, except...

It has to be reasonably well made.  The quality much be fairly good.
One hopes one does it right the first time.  Fortran had lots of "Oops!"
If its cheap maybe you won't be able to give it away.  If its big
and expensive, maybe too big.

Longish signature follows "Type 'n' now"

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

In article <2927@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>In article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>   2) the additional time required for the compile phase isn't a problem.
>
>You only need to do global optimization when producing the final
>version.  Development versions can probably get by with only local
>optimization.

This isn't quite true.  You can get by with only local optimization for MOST
of the development cycle, but when you change over to the globally optimized
version, you WILL find more bugs.  You had better figure on spending some
time doing debugging on that version.

And, of course, if the compiler/global-optimizer is new, you will likely find
some bugs in *it* when you start using it, too.

Frank Adams				adamsf@turing.cs.rpi.edu

In article <3594@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>... the really neat thing I thought
>about Unix software tools was they kept much of the library function
>while also being executable programs.  There was the spline program
>and the spine function.

Yes, this is a `really neat thing' but not something I usually think
of as a feature of UNIX.  If anything, this isn't done anywhere nearly
often enough.  The contents of libc probably contain only 5-10% of
commonly useful funtions that are reimplemented or cut/pasted all over
the system.  The integrated environments like lisp and smalltalk are
better for reusability, since the fire-wall that separates programs and
library-functions isn't present, but even these suffer from re-invention
of the wheel when programmers don't bother to research existing code.

Too often I've wanted to lift a function or two out of some random UNIX
utility only to find that the interface was all boogered up with
references to global data structures.  To this day, I'm shocked at how
many programmers blithely put pages full of global variables in their
programs...

A few years ago I found a real jewel.  (I think it was System-V.0) 
The library function getwd(3) was implemented by calling
popen("/bin/pwd", "r")!  Long live US{G,DL}.

-- Greg McGary
-- 4201 University Drive #102, Durham, NC 27707       voice: (919) 490-6037
-- {decvax,hplabs,seismo,mcnc}!duke!gm                 data: (919) 493-5953
--                                  gm@cs.duke.edu

| In article <3594@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
| ... the really neat thing I thought
| about Unix software tools was they kept much of the library function
| while also being executable programs.  There was the spline program
| and the spine function.

In article <14479@duke.cs.duke.edu> gm@romeo.UUCP (Greg McGary) writes:
| Yes, this is a `really neat thing' but not something I usually think
| of as a feature of UNIX.  If anything, this isn't done anywhere nearly
| often enough.

   Hmmn.  
   If memory serves, that was a carry-over from Multics.  The mutlicks
 standards manual strongly suggested you write a set of functions which
 fit a standardized external interface, and directed you to something
 called the subsystems utility package, which would ease the writing
 of such an interface.

   To return to the present, a standard interface package for either
 a line-of-text style or an icon-and-menu style might make a component 
 which would make writing framework for other components easier....


 --dave (7 more days until monomania!) c-b
--
David Collier-Brown,  | {toronto area...}lethe!dave
72 Abitibi Ave.,      |  Joyce C-B:
Willowdale, Ontario,  |     He's so smart he's dumb.
CANADA. 223-8968      |

In article <2927@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>In article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>
>   my experience so far has been that the more general a component is, the
>   slower it runs.  for example, given a routine to sort objects, you have
>   to give it a criteria.  somehow, the sorting routine has to make a
>   function call to compare two elements.
>
>Not necessarily true.  Given a good enough development system, the
>compiler can inline the function call (even to the point of it
>becoming a single machine instruction!).  This leads to a slower
>compile, so for test runs it's easier to leave the function call in
>(at the expense of speed).

	You're both right.

	Inlining can help for very small functions, or larger ones at the
cost of a lot of program size (and even speed, in a paging or cached
hardware environment).

	The original poster is right though: 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).

	Take a program like omega.  Massive unix game written in C, >1Meg
of source.  It would run much faster and be smaller if written (well) in
assembler.  However, it would never have come close to being completed.
We trade off efficiency of execution/size for cost of production (programming).
The same thing occurs in the ever-higher level toolboxes we use in costruct-
ing programs, like XWindows, databases, "software ICs" (still not really
well-understood or very useful yet, though they may well be eventually),
and things like nExt's Interface builder.

	This has happened from the very beginning of the computer industry,
and there have been no indications this will stop in the forseeable future.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup

> Inlining
This is very easily tested.  I wrote a paper about this: Usenix
Supercomputer Workshop Sept. 1988.  Basically, very few machines (compiler)
do this.  No one tests to make certain they do it.  So it tends to
be a lot of hot air.  It seems to get lots of lip service.  I won't
name the compilers which claim to do it but don't.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.