Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: comp.sw.components
Subject: Re: Using components (LONG)
Message-ID: <2927@cps3xx.UUCP>
Date: 10 May 89 17:17:50 GMT
References: <11293@bloom-beacon.MIT.EDU>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 111
In-reply-to: tada@athena.mit.edu's message of 10 May 89 15:07:23 GMT

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".   |
+---------------------------+------------------------+-------------------+