9/26 Sun released USIII released today. It seems to kick major ass
(of intel/amd/mot/dec) Anyone have a system yet?
\_ You're deluded. It doesn't beat alpha 21264 and only barely bests
Intel. It only excels in multiprocessing. --PeterM
\_ You're deluded. It doesn't beat alpha 21264 and only barely
bests Intel. It only excels in multiprocessing. --PeterM
\_ I bet Sun does a better job of selling their crap than Compaq
ever will. Compaq still doesn't understand all the gems
they have from that purchase they made a while ago. Compaq
weenies only understand NT and PC servers.
\_ Intel kicks the ass of every processor we have benchmarked
it against except for the new HP-PA chips. That does not
include USIII, but it was so much faster for our (intensive
number crunching) application than an USII 450 as to be
laughable. USIII would have to be twice as fast or more to
beat Intel, and these are only Intel 750's. --dim
MAYBE BECAUSE THEY CAN'T?
\_ Sun is selling 900Mhz USIII's now. SPECmarks
match a 1Ghz Intel on int and toast intel on FP.
\_ urlP
\_ I'll believe it when I see it. I don't trust SPEC
except as a very rough guide. So SUN's new processor
matches a 6 month old Intel chip, huh? That's supposed
to be impressive for the prices they charge? --dim
\_ 6 month old Intel chip? There are about as many
1GHz PIIIs in circulation as USIIIs.
\_ I've never seen intel kick any ass. MHz per MHz Intel
needs more than double to match PowerPC and Sparc.
\_ Duh! So why don't they DOUBLE THE CLOCK SPEED to
what Intel can do and BEAT INTEL INTO THE DUST?
MAYBE BECAUSE THEY CAN'T? Duh! CPUs have to be
DESIGNED to clock fast! Duh! MHz is MEANINGLESS.
\_ Okay I should have said it this way, they need
more clock cycles to execute the same number of
instructions because while US/PPC can execute 4
int instr./cycle and 2 fp instr./cycle Intel can
only do 2 and 1 (I believe). Bascially CISC is
wasting your time by doing less in more time.
\_ But RISC takes multiple instructions
to do what CISC does in 1. Comparing
instruction counts is as much as waste
of time as comparing Mhz.
\_ A RISC chip can introduce greater instruction
parallelism than a CISC chip can thus time
per instruction execution becomes important.
\_ Yeah, and they can't clock their complex (4/2)
RISC CPU fast enough to match Intel's relatively
simple CISC (2/1) in performance. Why is that?
It is because they failed to design it to
clock fast. Intel's is a superior implementation.
\_ No RISC is better. The only way that Intel can
keep CISC in the game is to keep ramping up the
speed. They can't improve performance in any
other way because of thier horrible design. Now,
\_
You seem to think that ramping up the clock
speed is trivial. You are wrong. The
CPU has to be designed from the ground up
to be highly clockable.
The MORE WORK PER CLOCK TICK, the longer
the logic stage, the less you can increase
the clock! It's a tradeoff. Designing
something to clock fast was a smart choice.
A winning choice. Intel designed
in such a way as to achieve high clocks.
Other vendors did NOT, or else you'd
see 1GHz PA-8500 uber alles. But the
fact is, no one can clock a PA-8400
at 1GHz precisely because it was never
designed to go that fast.
Only the 21264 is demonstrably "better" at
int stuff, and only barely. The PIII
and the K7 with their CISC are holding
up just fine.
RISC chips can get the same perf at lower speeds,
giving them room to expand perf in all aspects.
The high end RISC chips can run at similar speeds
as Intel's fastest but they can run thorugh more
instructions in the same time. The other problem
with x86 is the bad assumptions about uniform
memory fetch latencies. Intel has made some
pretty bad assumptions about how cache fetching
works and have spend a lot of time improving thier
pipeline, while the bottleneck is really the time
it takes to satisfy a memory fetch from either
l1,l2,mm,vm. It doesn't matter what your pipeline
is like if most of the time its empty.
\_ what a stupid measurement. That's like saying a particular
car is slow because it revs higher. -tom
\_ stop it Tom, you're making sense. :) -mtbb
\_ Retail cost should be a factor too
\_ I've had a SunBlade prototype on my desk since June (before it
was a SunBlade) - what do you want to know? -alan-
\_ Is the binary compatibily still there? There some problems
when moving to 64bit mode on USII (esp 200 MHz ones in the
UE2) and does it still run the 32 bit Solaris kernel (I
gather that 32bit kernel is faster than 64bit kernel).
\_ Yep. Complete binary compatibility (I have no idea
what problems you're referring to with the USII - it
was binary compatible as well.) No 32-bit kernel
though, 64-bit only. Which is faster depends on what
you're doing. -alan-
\_ For server work loads (ie non-compuational, non-db)
doesn't the amount of time required to search for a
given memory page in the 64bit address space cause a
noticable slowdown? And the problem with USII was
something to do with main memory fetch sometimes
failing on sub 200 MHz chip when the 64bit kernel
was running.
\_ Not that much of a slowdown, and on the plus side,
all 64-bit code is compiled with full UltraSparc
optimizations, while most 32-bit code is not.
\_ The only problem I heard of with < 200 Mhz Ultras
was the one where a bad instruction that no compiler
or assembler would ever generate could stall the
processer. That's a bug, not a compatibility
problem. (And fortunately for Sun, the actual
instruction was never publically leaked, unlike
the Pentium F00F.) -alan-
\_ Dont make old men run sprints or marathons |
http://csua.com/feed/