Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!jvm
From: jvm@hpfcso.FC.HP.COM (Jack McClurg)
Newsgroups: comp.benchmarks
Subject: Re: Which benchmarks are useless?
Message-ID: <21720006@hpfcso.FC.HP.COM>
Date: 30 Apr 91 16:36:42 GMT
References: <2502@spim.mips.COM>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 20

/ hpfcso:comp.benchmarks / patrick@convex.COM (Patrick F. McGehearty) /  4:51 pm  Apr 29, 1991 /
> A similar thing happened to the getpid system call.  Some people at Berkeley
> wanted to know how fast a trivial system call was, so they could tune the
> syscall interface.  They wrote a loop to call getpid() many times.  This
> test was appropriate for their purposes.  Later, this test (and many others)
> was made generally available.  Some vendors chose to speed up this test by
> caching the process id in user space on the first getpid(), and avoiding the
> system call overhead for subsequent getpid()'s.  There is nothing wrong with
> that optimization, just that it does nothing for real user programs.

While I agree with just about everything else that Mr. McGehearty says in his
response, the statement above is (As far as I know about HP) just speculation.
The getpid system call is not cached on HP-UX,  but the performance on getpid
was so much better than expected (anomalously) that the trick above was
assumed by the author of a paper comparing operating system performance with
performance on common benchmarks.  I cannot remember the name of the paper,
but it pointed out some disconcerting (to me) areas where OS performance does
not keep up with what should be expected from benchmarks.

Jack McClurg