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

Comments

Sun's MAJC

[joneshenry]

Ars Technica has a fantastic article comparing and contrasting Sun's future MAJC (Microprocessor Architecture for Java Computing) CPU architecture with Intel's IA-64. It's going to be very interesting to see if Sun can carve out a large enough market to ensure MAJC's viability. My uninformed opinion after reading the article--Sun has been making decisions since its founding that have given it the only chance to survive. By almost totally eschewing both Intel and Microsoft, Sun has been forced to innovate on both hardware and software to compete with these giants. Sun simply had to invent Java--what was the alternative, reselling NT "workstations"?! Now Sun has leveraged Java into strategic partnerships with IBM, Oracle, etc. to create from scratch a major software niche, not to mention Java's future in the embedded markets. MAJC it seems to me is the logical step in hardware once Sun made the commitment to Java and once Sun decided not to become a reseller of Intel chips like say HP. Without having to worry about what Intel wants, Sun can use its traditional RISC approach to registers to once again offer a fantastic alternative--read the Ars Technica article cited above: "MAJC, however, spends so much of its die space on registers that it can have the register states for four different threads loaded at once. Since it doesn't have to save and load register states to switch between threads, its context switches are very fast". In the 1980s HP saved the company investing in PA-RISC. Maybe that was because the engineer founders David Packard and Bill Hewlett were still alive and strong. I believe that it is Sun that has applied that lesson of not surrendering control over the CPU architecture, and that HP will continue to pay a heavy price for deciding to go with Intel. Financing new chip architectures is difficult, but in my opinion there is no future for being a reseller unless one is IBM or Dell. (And note that IBM resells only because it wants to since it already manufactures alternatives, it is beholden to no one. Just who will be able to compete with IBM's Global Services?)

Re:RISC/CISC

[bribecka]

In addition, I beleive that the Itanium CPU itself does no real optimization of the instructions, such as common subexpression elimination, loop unrolling, etc. Instead it relies on the compiler to create highly optimized code.

Is this a good idea though? I mean, using one of today's compilers, ported to a IA64/Itanium architecture, a compiled program might run very slowly, since today's compilers probably let a bit of the optimization (within reason) up to the CPU. This would also mean that it may be a little while until some quality IA64 compilers are released. Or am I misinformed?

MHz not only measure of speed

[IGnatius T Foobar]

Attempting to measure how fast a computer can go by its CPU's clock speed is tantamount to measuring how fast a car can go by its engine's horsepower. There are many more factors at play here.

Let's start with the whole RISC vs. CISC thing. Everyone knows that RISC is more efficient; the only thing that has kept CISC alive this long is backwards compatibility with the Wintel juggernaut. You develop a lean, efficient instruction set, then you write compiler back ends that take advantage of it.

Also keep in mind that Sun's motherboard designs are true performers. The path between the CPU, memory, and bus are designed to move data around in ways that just aren't possible with Intel.

Did you know that SPARC is more or less an "open" CPU design? It was designed to be a multi-vendor instruction set, one that would be 'common' without having one vendor calling all the shots. Read www.sparc.org for more details.

Re:Stop the slaughter

[j7953]

Save the instructions

Actually, this will happen. Current processors are designed so that with each cycle they load and decode the instructions they're going to execute (and, of course, the data the instruction is going to work on). When the instruction is completed, it's thrown away. This is highly inefficient for loops, because the same code is loaded again and again. Think about audio or video decoders -- the same decoding instrcutions are reloaded all the time.

Future processors will, at least partly, be reconfigurable, that is they will load a set of instructions and save it, and then have to load the data only. This is supposed to be the optimum between a hardware-only implementation (fastest, but can't change when, for example, encodings change) and current "software-only" implementations (most flexible, but processors must (re)load instructions in each cycle).

Take a look at, for example, PACT if you're interested in this technology, they're one of the companies developing such processors.