Sun's Zippy New Chips
Mark the Revelator writes: "Reuters has a story about Sun unveiling it's latest and greatest UltraSparcIII chips. The new chips are being made by TI and are the first UltraSparcs to use copper instead of aluminum for transistor connections. Although they're supposed to compete with Intel's Itanium chips, they only run at 900MHz ... for now."
Duh!
Your Servant, B. Baggins
The Itanium achieved some truely awesome SPEC-FP scores that made Sun look pretty bad. At FP, Itanium whales.
Itanium suffers from the same problems as the Pentium 4, in some ways, in that you can't ever branch. If you can find code that does this, and doesn't have many NOPs, the Itanium will perform very well. That doesn't describe much general-purpose code in the real world.
So, the crux of this is that Itaniums are faster at some things, just like the Pentium 4 is faster at some things. The risk is that these Intel processor applications are becomming highly specialized, and better general-purpose processors are available.
Ther're so much more to buying Sun kit than CPU cycles.
You get (IMHO) the best OS you can run on a server (*incomparably* more reliable than Linux in my experience).
You get a better build quality than with PC class gear. (not so with the low-end Ultras I know, but have you tried carrying an E450 around lately?) I've worked with Sun boxes (mail hubs, NIS servers etc.) that haven't been swtiched off in 8 or 10 years.
You get excellent support - hardware or software. It costs, but it's worth it.
You get as much SMP as you could want.
You get insane amounts of addressable RAM and faster bus speeds.
In short kids, you get *proper computers* running a *proper OS*.
Although they're supposed to compete with Intel's Itanium chips, they only run at 900MHz ... for now.
Just becaue it runs "only" at 900mhz doesn't mean anything compared to an Itanium running at a higher clock speed. There are many more factures like pipelines, cache, and over all archetecture. A 900mhz sparc could beat an Itanium at a higher clock speed just like Athlons and PIIIs can beat P4s in certain benchmarks while running at lower clockspeeds. (not saying it will or will not, but you can't discount one processor based only on clock.)
--------
It's OK to be social, just don't tell anyone about it.
They make all of Sun's UltraSparc chips, and also manufacture other, more esoteric things - like dual core chips (DSP and ARM, known as OMAP).
All in all, TI is much, much more than calculators.
Windows is bloated because MS piles feature onto feature. The features don't work together, so there's a lot of implementation redundancy. If something goes wrong, a kludgy fix is added, making things worse. Everything gets totally redesigned every 6 months, so there's a lot of backward-compatibility support -- more implementation redundancy.
Part of Sun's success is how well they address the bus/throughput issue, as opposed to 'other' computer architectures. And that's why JUST comparing MHz is like comparing apples and oranges.
Or perhaps a better anology is comparing a Formula 1 Racing car stuck in down-town NYC Traffic, versus a 6 cylinder Honda Accord on flat, wide-open highway in Montanta, during the daytime when the weather is perfect.
healyourchurchwebsite.com - WWJB?
Those terms don't apply well with modern processors. Pentiums class processors are primarly CISC with some RISC features/ideas (not many though). The Sparc family has been RISC with a lot of complexity thus making them be more CISC than say the Alpha. That has historically been why their clockspeed is lower than alpha, but still performs about the same for general purpose computing.
The Itanium is a branch off of a different tree, Very Long Instruction Word, which is a branch off of RISC. VLIW let's a compiler pack multiple commands to multiple execution units into a single long word. The idea is to use very RISCy commands to keep a superscalar set of execution units more fully utilized. Great idea, if your compiler can do it.
Really? By what measure? CISC is generally much more efficient with respect to code size, an important consideration in embedded systems.
I'll assume you were talking about the performance domain. Be careful with your categorizations. There are no "pure" RISC or CISC designs anymore. O-O-O superscalar architectures have pretty much killed any simplicity in so-called RISC designs. Now it's true that uniform instructions make O-O-O much easier. But vector processing and multimedia operations don't really qualify as RISC in the classic sense.
Sun has made some obvious mistakes in the past: fixed-size register windows and delay slots come to mind. Like Intel/HP they have in the past made the mistake of thinking that the compiler can do more than it really can (at least at this point). Parallelism is hard enough to extract at run time. It's much more difficult at compile time. Some of this has to do with maintaining the separate compilation model and speed/memory complexity issues (many compiler algorithms are NP-complete).
And of course, all CPU vendors except Intel/HP have made the mistake of having an inadequate number of general-purpose registers. Ironic, eh? :)
That's not to say the compiler can't do more. It can do a lot. Unfortunately, CPU vendors have not provided the necessary hardware to make this possible. In the future you will see a style much more similar to IA-64: the hardware and compiler conspiring together to extract parallelism, save power, etc.
Here's something to think about: the original intent of RISC was to allow simpler pipeline stages and higher clock speeds. So why does a CPU implementing a CISC-ish ISA have a 50% higher clock rate than a RISC-ish ISA implementation? Deeper pipeline, sure. But don't let labels fool you. There is much more going on in the architecture world.
I do agree with you on the scalability issues of SPARC systems. That's their bread and butter.
As you implied, SMP performance is extremely important to people who buy Sun.
In this case, you wouldn't care much how an individual processor performed; you are most concerned with the performace of, say, a 32-way system and it's ability to quickly shuttle data between processors, memory, and disk.
Our beloved Athlon only scales to 2-way, and it's SMP architecture is now being entirely redesigned with the NUMA hypertransport.
Sun probably suffers in raw MHz and SPEC scores because they put so much effort into the SMP aspects.
And, of course, Sun outsells some (arguably) better technology (Power, Alpha) because they are much more open and their service organization is superior.