Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!im4u!rutgers!mtune!codas!usfvax2!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: brash micros versus the Big Iron: not yet
Message-ID: <1251@pdn.UUCP>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: pdn.1251
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Sat, 5-Sep-87 18:10:53 EDT
References: <622@winchester.UUCP> <12953@amdahl.amdahl.com> <630@winchester.UUCP> <1202@pdn.UUCP> <640@winchester.UUCP> <1221@pdn.UUCP> <649@winchester.UUCP>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 69

In article <649@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes:
 >Again, this is not to denigrate cycles/instruction as something architects
 >use: I just have trouble when people start throwing the numbers around
 >with insufficient precision. I've even seen things published by people
 >comparing CPI of their systems and our systems, where we still cannot figure
 >out how they derived the numbers for our systems [or their systems, either].
 >I just have this strange fondness for numbers where I can know where they
 >come from, and where I can measure them without magic.

Of course, the more accurate the data, the better.  However, in the real
world...

  >>[I offer to mail John Motorola's Benchmark Report]
  >Yes: please.  It would be useful to understand what they're saying.

Done, provided there is a Snail Mail address somewhere in your article
I can use :-).

  >>>[I assert that the native Cycles Per Instruction ratio is better
      than a normalized CPI]

>I must be missing something.  What is wrong with cycles / (unit of work)?
>If two CPUs (34010?) have the same CPI, but differ in cycles/(unit of work),

The 34010 is Texas Instruments "Graphics Processor"--although it could
be used as a "general purpose" CPU (whatever that is :-) ).  

>then it must be that one of them is executing a lot more instructions on
>a given benchmark.  This was the original anti-RISC argument: "yes, the

Aha!  "on a given benchmark"!  Precisely!  Normalizing  to "units of
work" NECESSARILY involves using a (set of) "given benchmark(s)".  It is
a virtual certainty that any set of benchmarks you choose skews the
measurement of work so that some CPU's will either suffer or benefit
to an extreme degree in their percieved performance using normalized
instructions to measure work accomplished.  Eventually, of course,
one must decide on a benchmark suite, but that "binding" should be
delayed for as long as possible, so that the performance numbers
are not "skewed" before they have to be.

>>Obviously, it is necessary to find the optimum balance between these to
>>conflicting constraints.  I would like to see a mathematical proof
>>or theory that could demonstrate or discover just what that balance is.
>>Without it, machine designers are little more that artists, not
>>engineers.

>I doubt there is a closed mathematical solution to this problem, (if there were,
>the optimal machines would be designed already!), but there is an iterative
>process that has been used at various places, and is by now pretty
>well-known:
>>[John describes a process of tweaking a simulated machine's
architecture until the numbers look good]

There is, then, no way to absolutely determine what instructions should
be included and which ones left out.  Trial and error methods are of
course useful when nothing better is available, but I have to question
whether this gives people the right to make general statements about 
what sort of architecture/instruction set represents the optimum that
can be achieved.  Experimentation of the sort that John describes to
discover a better instruction set than one started out with should
be also aimed at discovering the general principles by which such things
should be designed, with an eye towards eventually deriving a
comprehensive and predictive theory.  Failing that, one can never
know that one is not missing something important and/or following
a dead-end path.  I, for one, would rather not change CPU architectures
as often as I buy new clothes, especially when there is no guarantee
that something ten times better won't be announced tomorrow.

--alan@pdn