The Battle in 64-bit Land, 2003 and Beyond
An anonymous reader writes "Paul DeMone has an excellent article up at Real World Technologies on the future of 64bit computing. Find out where MIPS, HP, Intel, AMD, Sun, Fujitsu, and IBM are headed."
← Back to Stories (view on slashdot.org)
The article is very detailed on many points, but doesn't seem to have much mention of environmental aspects like heat dissipation. I can remember when this was a big issue with every new CPU, but lately it seems to have been swept under the rug. What's changed?
I'm certainly interested in the speed of CPUs, but heat production in the embedded space happens to be a bigger issue for me.
Could I interest anyone in some toast?
Lousy I/O?
A few weeks ago, I was looking into buying a $35,000 Sun system. I needed a machine with better memory bandwidth than a PC could offer. The machine in question interleaved its memory 8 ways, if you had all of the processers!
Then, I noticed that each bank ran at 75 MHz. Boy, was I shocked. That means that all 8 banks together run at the equivalent of 600 MHz. The new Granite Bay chipsets, with dual DDR 333, give you the equivalent of 666 MHz.
Both systems use PCI to connect to the outside world. The PC has a 533 MHz front-side bus, and an AGP port. I can't think of anywhere that the Sun would have had any better I/O.
Now, when you get into 8-way systems, the I/O between processers is better on the "high end" machines. But before you can come up with more I/O than a modern PC, you have to spend about 6 figures. In other words, two ORDERS OF MAGNITUDE HIGHER!
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
In and of itself, a 64 bit processor with a 64 bit operation system really doesn't mean better performance. You've really got to have application which leverage that kind of platform. And there aren't many. On my SPARC servers (which all have 64 bit CPUs), going from a 32 bit OS to a 64 bit OS so no real improvement or degradation regarding performance in a wide variety of applications. Going 64 bits for most people mean nothing.
The main selling point for SPARC, which most people who aren't dealing with Sun don't understand, is not the CPU itself or the speed of a uniprocessor box.
It is the total package. (Admittedly, the lower part of that is the uniprocessor performance.) On the upside, Sun has some very compelling benefits. Almost all major UNIX programs (commercial) are developed for SPARC, often as the primary development platform. The binary compatibility is awesome. The binary tat I compiled on my workstation (with 5 years old technology that is several CPU generation behind) will containue to run the most modern hardware. There's no recompiling for different/newer architectures (unless you're looking to gain a specific advantage of a new processor and your compiler can do it). And probably one of the best features is an awesome scalability story. If your code does threads, or uses more than a processor at a time, you can scale from a 1 CPU to 100+ CPU configuration. No special programming to worry about clusters or to take advantage of new hardware. Additionally, because the hardware is (majority) single vendor, you gain a great deal of relaibility over platforms which has an incredible amount of diversity (wintel). Okay. That's a double edge sword, admittedly.
That said, it is too bad that Sun just can't keep up in the uniprocessor world. But it has quite a number of real-world advantages beyond performance which keep it afloat, which may surprise people.