[rc5] Pentium vs. Pentium Pro (renamed)

Brooks Talley Brooks_Talley at infoworld.com
Thu Jul 3 10:50:07 EDT 1997

>> but how much better are they??  obviously they are much better than a
>> 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.
Mind you, the rc5 client is not a valid processor benchmark of any sort.
But FWIW, I'm running it on a bunch of machines including two PII boxes.
Both are PII-233 w/512K cache, and they get 622kkeys/sec and 560kkeys/sec.
Yes, that's really weird and I don't know why the big difference, either,
since subsystems really shouldn't matter when the thing is just crunching

By comparison, a PPro-200 gets 480kkeys/sec (I have 4 or 5 of those
running, and they're all within 1% of each other).   Assuming a linear
scale, a PPro-233 would get 559.5 kkeys/sec -- about even with the slower
of my two PII's, and significantly slower than the other one.

Of course, rc5v2 isn't a real benchmark and only reflects what you want
your system doing in its idle time, not when you're trying to use it.

>> 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"
>> instructions instead of x86 instructions, in which case a P6 optimized
>> 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.

It isn't possible to write directly to the P6's internal, RISC-like core
except by compiling with a mind for what the result will be, which is what
happens when a compiler optimizes for P6.    And you're exactly right about
the very dependant nature of code like RC5.... I wonder if it might be
smart to write the assembler piece (I think rc5v2 uses assembler for the
core of the RC5 code) to try two keys at once, using a slightly different
implementation of the code to prevent the *same* instruction from happening
at the same time for both keys it was working on.

And a final PS regarding someone else's comment about an attachment with a
pic of a little world: that was me.  Not intentionally, mind you, but it's
next to impossible to get Notice Lotes to deal with inet email in a
civilized manner.  Hopefully this message doesn't have an attachment, but
who knows.  It may have 6.

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list