🚀 go-pugleaf

In article <85593@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>In article <28594@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
>:In article <34058@mips.mips.COM> mash@mips.COM (John Mashey) writes:
> 
>:| 	I'm always nervous about micro-level benchmarks.  Now, I hate to have
>:| 	to defend SPARC :-), but I must: realistic integer benchmarks
>:| 	that I know [like the SPEC ones] simply don't correlate with
>:| 	the results claimed below, at least not very much.
>:| 	The RISC machines are noticably faster on actual integer programs....
>:
>:The benchmarks over-emphasize integer modulus.  For example, the
> 
>Huh? I don't see multiple modulus operations in the loop below. I see ONE.
>How can one modulus operation inside a loop "over-emphasize" integer
>modulus?

Sorry, I should have been clearer, and said:
"The benchmarks over-emphasize integer modulus compared with the
dynamic frequencies of most programs."

Consider 3 kinds of benchmarks:
	1) Real programs, of substantial size.
	2) Micro-level benchmarks that measure specific operations (like
	+, -, *, /, %, etc), and labele their results that way.
	3) Small synthetic mixes (which is what the benchmark under discussion
	is doing).

I prefer 1), but 2), is OK, if it's carefully labeled, and can provide useful
information, although one must be careful to avoid compiler effects. For
example, if one has those numbers, and if one has applications that are known
to use integer *,/,% (as you do!), it would be pretty clear which machines
would be good or bad, in this case.

However, I don't like 3), when the results are misinterpreted (and they
usually are).  It picks a specific relative frequency of operations,
and then people run around claiming that this predicts integer performance.
This is nonsense:
	1) Programs differ widely in their frequencies of operations.
	2) If one wanted a simple loop that approximated the frequencies
	of UNIX C programs (like nroff/diff/grep....) and CASE/CAD integer
	tools (like ccom, as, ...espresso, etc), you'd look at the statistics
	of these things, and make up a loop that approximatecd this.
	You'd want something whose relative frequencies were:
		+
		-
		* (some mixture of * by constants & by variables)
		  (and definitely many fewer *'s than +'s)
		/ (less than *)
		% (less than /)
	3) Now, for a variety of reasons, I wouldn't myself make up such a
	benchmark as a predictor, but it would certainly be better than
	the statistics of the benchmark being discussed.
Anyway, I agree that SPARC performs poorly if you have the kind of program
(like multiple-precision integer work, especially, or various others
we've run across) where integer mul/div/modulus are inescapable,
and where it doesn't even have a divide-step to help out.  This does
illustrate the nature of tradeoffs, and the care needed when selecting 
instructions: you should use the statistics of real programs, as many as
possible, and you have to be careful that you don't leave out something
that can make a huge difference, even if many programs don't need that.
Remember: we put *, /, % in hardware,
even though our predecessor Stanford MIPS and many other RISCs didn't,
so I'm hardly arguing against them :-)  I'm delighted to see SPARC dinged
for not having them :-)  But it's not fair to claim that an arbitrary mix
of operations proves that SPARC (and then other RISCs, as though SPARC = RISC)
has bad overall integer performance.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086