[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
>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.
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
keys.

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"
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.

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.
-b


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



More information about the rc5 mailing list