Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch
Subject: Re: Benchmarking
Message-ID: <6183@june.cs.washington.edu>
Date: 23 Oct 88 01:03:39 GMT
References: <2220003@hpausla.HP.COM> <46500026@uxe.cso.uiuc.edu> <6683@nsc.nsc.com> <6684@nsc.nsc.com> <4263@wright.mips.COM> <6729@nsc.nsc.com> <10498@reed.UUCP> <4655@winchester.mips.COM> <6868@nsc.nsc.com> <1988Oct9.011633.13259@utzoo.uucp> <4853@winchester.mips.C
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 24

peter@stca77.stc.oz (Peter Jeremy) writes:
>[ prevent/classify function inlining ]

Inlining a given function on a given machine may speed the computer
while inlining the same functin on another machine -- or even the same
machine, but with a different level of optimization -- may *slow* the
observed performance.

In particular, I can hypothesize machines/situations in which calling
getc() as a function is *faster* because the whole thing stays
in-cache and lets other code stay in-cache too.

In running a "real" system it is the effective speed that bothers me,
not fast hardware/slow software or slow hardware/fast software.
Conclusions:

* Ultimately, benchmarking is very hard.
* Even with a benchmark that tests a particular feature and a very
  good description of the workload, it may not be possible to
  extrapolate the combined performance from the individual
  performance.
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo