[rc5] Pentium vs. Pentium Pro (renamed)

root marcus at dfwmm.net
Thu Jul 3 12:31:19 EDT 1997

Brian Hechinger wrote:
> but how much better are they??  obviously they are much better than a Pentium,
> but what if i only want to run 32-bit stuff, how does a Pentium-II stack up
> against a PPro of the same clock rate??

I have not seen many PII benchmarks, but for now, I bet on the Ppro.
>From what I _have_ read, the pentium mmx is obsolescent at least.
The new chips from AMD and Cyrix outperform it every which way. The
ppro outperforms the p/mmx everywhere but 16 bit code. The PII is in
a race with the K6 and M2 in all the benchmarks. So whatever you _do_
buy, _don't_ buy a p/mmx because something else beats it everywhere.
If you like your motherboard and want to stick with Socket 7, go with
the k6 or m2. If you want to spend the bucks for intel's new and
improved(?) slot form factor, go PII.

I say improved(?) because according to their own benchmarks, the PII
does _not_ beat a PPro at the same clock speeds. See the last two
editions of PC-Week for intel ads that reveal this. These are ads
_for_ the "new", "improved" PII mind you, and they compare a PP200
with 256k cache to a PII at 233 and 266 with 512k cache. Guess what?
If you do nothing more than scale up the PPro numbers from
200->233->266, the ppro beats the PII, never mind the cache.

IOW, ppro233 is(would be) faster than pII233, and a ppro266 is faster
than pII266. So I have some doubt if the PII improvements are anything
more than boosts in clock speed and a "new" (read expensive) package.

> if the PPro has to break down the x86 instructions, how much optimization can
> be done with the exception of using an assembler that talks in "native" PPro
> instructions instead of x86 instructions, in which case a P6 optimized binary
> won't run on a P5 or lower.  i don't even know if something like that is
> possable anyway, i'm just taking a guess at what could be done.

Regardless of the whether it "breaks down" complex instructions
or not, the first optimization when pipelines are used is to try
to keep the pipes full and avoid stalls due to references to
unfinished instruction results, bus contention, or whatever
bottlenecks might be produced by the implementation. Next, if you
have more than one pipe, you try to make things mesh together in a
parallel form. As it is, the pipes are troubled with simple loads,
and stores since most of the the algorthim is really a sequence of
"simple" operations. Rotate, shift, add, xor, array indexing and so
forth. It's tough to keep things going in pipes and in parallel
because a lot of the ops in rc5 are immediately dependent upon
previous results as in:

      A = ROT(X, B);
      B = ROT(X, A);
      A = ROT(X+1, B);
      B = ROT(X+1, A);

Sometimes this is not a problem because you can do things like
increment the array index, store a previous result, or do
_something_ useful while waiting for the results of an op to
complete like this(assume 2 cycle pipeline):

1      A = ROT(X, B);
2      Y = X + 1;		//A is not ready
3      B = ROT(X, A);		//A is ready, Y is not
4      if (Y > limit) branch	//Y is ready so check loop limit
5      X = Y;			//copy new index
6      A = ROT(X, B);		//pipeline stall because X is not ready
7      ----                     //B is ready, X is ready, finish op 6
8      Y = X + 1;		//etc.
9      B = ROT(X, A);
10     ...

if all we did was swap a couple of instructions we could get an
improvement from the previous example:

1      A = ROT(X, B);
2      Y = X + 1;		//A is not ready
3      B = ROT(X, A);		//A is ready, Y is not
4(5)   X = Y;			//copy to X first!
5(4)   if (Y > limit) branch	//Y is ready so check loop limit
6      A = ROT(X, B);		//NO pipeline stall because X IS ready
7(8)   Y = X + 1;		//etc.
8(9)   B = ROT(X, A);
9(10)  ...

Admittedly, this is a simplified example, but is shows what is
going on when people talk about "optimization". This example
produces a reduction in the loop cycle count from 6 to 5 and
that's a significant improvement for a section of code that
gets executed a few million times a second while checking keys.
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list