Path: utzoo!attcan!uunet!dg!Publius
From: Publius@dg.dg.com (Publius)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <640@dg.dg.com>
Date: 13 Jul 90 19:46:07 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com>
Reply-To: publius@dg-pag.webo.dg.com (Publius)
Organization: Data General, Westboro, MA.
Lines: 34

In article <64045@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes:
>In article <628@dg.dg.com> publius@dg-pag.webo.dg.com (Publius) writes:
>
>>Many "large" programs spend most of the CPU time in one or a few relatively
>>"tiny" routines.
>
>This is an often stated.  Is there any evidence for this?


The best known example is probabily the LINPACK benchmark (although it is
not big).  It spends over three quarters of the CPU time in a tiny routine
called daxpy() (saxpy() for the single-precision case).  The same daxpy()
routine, though coded a little differently, is also responsible for most of
the CPU time of one of the SPEC 1.0 Suite benchmarks (matrix300, to be exact).
Actually, many numerical analysis programs spend big chunks of CPU time in
this daxpy() routine.

Many years ago, Donald Knuth stated that most of the CPU time in batch
business application environment was spent in doing sorting.

In practice, the better a large piece of software is modularized, the easier
it is to identify the time-consuming routines.  Also, it is not difficult to
understand that the programs written with the re-usable code in mind tend to
spend much CPU time in the same routines.





-- 
Disclaimer: I speak (and write) only for myself, not my employer.

Publius     "Old federalists never die, they simply change their names."
publius@dg-pag.webo.dg.com