Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!apple!bionet!agate!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Benchmarking
Message-ID: <23225@amdcad.AMD.COM>
Date: 12 Oct 88 19:04:56 GMT
Article-I.D.: amdcad.23225
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
Sender: news@amdcad.AMD.COM
Reply-To: tim@crackle.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 21
Summary:
Expires:
Sender:
Followup-To:

In article <3285@pt.cs.cmu.edu> lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes:
| Next, the Generator should write the code to fill an array with pointers
| to these functions. Similarly, we need a data array.
| 
| Next, we need a portable routine which generates pseudo-random numbers.
| (Portable mostly means that it avoids arithmetic overflow.) The quality of
| the randomness is unimportant, as long as it doesn't get stuck at 0 or
| other such silliness.  The generated program will use the randoms to form
| subscripts, either into the data array, or into the function pointer array.
| In this way, we may control the size of the working sets.

I once received a benchmark program that was similar in nature to this. 
It used a very large number of functions in separate source files, and a
big switch statement that selected a function to call based upon a
random number.  I ran this benchmark, then I profiled it.  It turned out
that 30% of the runtime was in calculating the random number to use for
the function selection!

	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)