Slashdot Mirror
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)
Intel will release a 64 bit processor first, but 2 months later AMD will come out with a 61 bit processor that runs twice as fast. Don't ask me how, or even why speed is relevant to the computing power, but they will do it.
Then, 6 years later, China will come out with their own.
Work sucked, until it became unemployment, when it became slightly more tolerable. -Tet
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?
Hah! My Commodore 64 has 64 BYTES! Hah!
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.
Microsoft is eagerly awaiting 64 bit processors, as they will "greatly decrease the incidence of Integer overflow exceptions, and memory overwrites"
TOKYO, March 2, 1999 -- Sony Computer Entertainment Inc. is pleased to announce the co-development with Toshiba Corp. of the 128 bit CPU ("EE", or "Emotion Engine ") for use in the next generation of PlayStation . In order to process massive multi-media information at the fastest possible speeds, data bus, cache memory as well as all registers are 128 bits; this is integrated on a single chip LSI together with the state of the art 0.18 micron process technology. The development of a full 128-bit CPU is the first of its kind in the world.
"Where's the power?"
Easy. It's in the PC.
Yeah, I know. Some of the super-expensive RISC chips blow away PC's on floating point. But look at your FLOPS per dollar. Chances are the PC will be at least an order of magnitude lower.
It's been trendy to bash PC's for quite a while. However, if you've been "in the business" for two decades, and had your eyes open, you've realized that things have been slowly changing.
In the "bad old days", PC's sucked hard. Companies like Sun, DEC, and IBM were the only choices if you needed more computing power than an average automobile.
Because of the economies of scale in the economy market - and the competition - PC chip makers like Intel, AMD, Cyrix, etc. kept improving their products steadily. Now, a modern PC chip compute with "big iron" chips very well in integer work, and are fast approaching (in some cases, BEATING) them in floating point work - and all at a tenth to a hundredth of the price.
Back in the bad old days, it didn't matter how fast of a computer you bought, it still wouldn't run a desktop at an acceptable speed. These days, it practically doesn't matter how SLOW of a chip you buy, it'll still run a desktop at an acceptable speed.
There will always be a market for the big iron and specialty hardware, but as time goes on, the PC technology has improved by leaps and bounds over the years.
Now, don't get me wrong. There's still room for massive amounts of improvement. I would love to see the x86 architecture, and all of the legacy crop dropped like a hot potato. I'm not confident that it will happen in this decade, but it sure would be nice if it was.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Holy cow... I didn't know microprocessor features were still so freaking huge! Methinks the author needs to remember that there is an HTML entity readily available as µ. :) Unfortunately it seems slashdot is stripping out most of my entities so we can't see it here . 0.13 mm is 130 microns, which is roughly where IC technology was in the mid- to late-1980's if I'm not mistaken. That can't possibly be right. If use of the entity is out of the question (just as it seems to be on ./), maybe they could have said 0.000013 mm or even spelled out the word "micron" right out.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
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.
Most users won't need more than 32bits for years. By 2010 normal people will probably want 64bit desktops so they can have more than 4 gigs of ram (although Intel may be able to trick them with their 36bit extension).
128bits is a LOT.
Don't be fooled by the emotion engine in the PS2. It is 128bit in the sense it can handle 4 32bit floating point numbers at once. Guess what? So does Altivec, SSE, etc!
Calling systems 128bits is like calling the Atari Jaguar 64bit when it was powered by the good old 68000 that powered the 16bit Gensesis, 16bit Amiga, etc.
Typically the number of bits something is referrs to how much memory it can address (2^32bit=4gigs for example). Marketting likes to calling things 128bit (PS2 can handle multiple 32bit numbers at once), 64bit (Jaguar had a memory bus capable of moving 64bits at once), or 24bit (The Neo Geo had a 16bit 68000 and a 8bit z80) to get your attention.
The instruction set and register layout is irrelevant. All modern X86 CPUs translate the inctruction stream on-the-fly to an internal RISC-like architecture with multiple parallel execution units. Using register renaming, all modern X86 CPUs have dozens of general-purpose physical registers that can be simultaneously mapped onto the legacy logical registers.
There is no need to expose the internals of any particular CPU generation to the software because the details change with each new design. The CPU's on-the-fly recoding knows how to optimize for the details of its particular internal implementation better than a C compiler. (Exposing the implementation details to the compiler is one reason why I think that the whole Itanium concept is a bad idea in the long run.)
The floating point performance is a function of the target market. If a CPU manufacturer was so inclined, they could create an X86 with world-record FPU performance. It's just not needed for the majority of places where X86's get used today.
PCs do not even today have lousy I/O. In fact, because the PC architecture has less registers, code needs to store stuff in memory more often, which lead to PCs outperforming RISC machines in memory bandwidth over the years. Sun and IBM in particular have been outperformed in RAM bandwidth for over a decade. They mad up for it in good floating point performance, but now the PCs are catching up there as well.
;-)
By the way, AMD's HyperTransport and Hammer memory infrastructure is quite similar to the "perfect scalability" Alpha memory hardware that has been making headlines recently. I expect Hammer to rule the planet here. Madison also has huge memory bandwidth, but it wastes most of it reading NOPs and instructions that are predicated away or otherwise discarded.
Also, if you actually read the article, you will notice that even the PowerPC translates their ugly and complex instruction set to an internal instruction set, which is more RISCy. This is the very thing that RISC afficionados have been using as argument against x86 for years!
The world isn't that black and white.
Have you even looked the IA64 ISA? It is a significant departure from x86. IA64 supports x86 instructions through emulation only (which is why x86 perf on IA64 is lagging.) It is not a 64-bit extension of IA32, which is an extension of IA16.
With IA64, there are 128 integer and floating point registers, 64 1-bit predication registers, eight branch registers, instructions are fixed length, every instruction can be predicated, speculative execution is supported at the instruction level, registers are preserved across function calls with register stacks, and register rotation can help prevent explicitly prevent antidependencies in tight instruction loops. Each of these is a departure from x86
I'm not too sure of this fact (and I am too lazy to double check) but I'm pretty sure IA64 requires a 64-bit operating system to even boot, unlike x86 which boots to 16-bit real-mode, and then is switched to 32-bit protected mode by the OS.
Actually, the IA64 performance is very bad in the real world. True, their benchmarks look impressive, but I haven't been able to reproduce that.
;)
I had the opportunity to log in to an 4-way 900 MHz itanic-2 box, which was outperformed by my lowly 900 MHz Pentium 3 notebook by a factor of 4 (single CPU benchmark). I did some mp3 en- and decoding and compiling on the box.
Also, ia64 is spectectularly bad for MPEG-4. Go ask google for ia64 and xvid and you will find a computer science class in Germany trying to optimize ia64 and they found that after their optimizations (which yielded a big speed-up) ia64 still was handily outperformed by their el-cheapo desktop Athlons.
Take those benchmarks with a grain of salt. I basically think that IA64 is a big flop. Intel needs a miracle to make people buy this crap. But, as they say, your mileage may vary.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
With advances in medicine, regeneration, nanotech, and cybernetic replacements/augmentations, I fully expect to live at least 200 years. Did you take that into consideration when making your prediction? :)
-Thomas
It is such a shame to see good CPU architechtures die, and crap live on.
The Motorola 68K family were a joy to work with - lots of registers, and a very orthoginal instruction set - you could use any A register for pointers, any D register for data - none of this "ECX is for loops, EDI for destination pointer, ESI for source pointer" crap of the x86.
It's dead now, save for use as a microcontroller.
The Alpha was a ass-kicking, name-taking monster. While I never seriously programmed on it, it was 64 bits long before anybody else knew how to spell it - it had well established software and compiler technology. It is STILL one of the leaders.
But for all intents and purposes, it's dead, Jim. Yet Itanic, with an unproven design concept, is flourishing (sorry, having worked with DSPs that implemented the VLIW idea, I have doubts about the real-world performance of VLIW in a multitasking environment).
As Billy Joel said, "Only the good die young...."
www.eFax.com are spammers
I recompiled it with EPIC, of course.
The x86 emulation mode is so bad, nobody in their right mind will use it. IIRC it is slower than a 200 MHz Pentium Pro.
Unfortunately, none of the current crop of 64 bit processors deliver: the cost of true 64 bit systems (those capable of actually using more than 4 Gbytes of memory) generally starts somewhere upwards of $10000, and for that you do not get anywhere near 10 times the performance of a $1000 PC.
The main reason right now to get a 64 bit system at current prices is because the applications just cannot be shoehorned into a mere 2-4 Gbytes. If AMD can change that equation and deliver comparable bang-for-the-buck to current PCs, with 64 bit addressing being icing on the cake, they have a winner. None of the other players seem to be capable of doing that--they have tried and failed miserably so far.
With advances in medicine, regeneration, nanotech, and cybernetic replacements/augmentations, I fully expect to live at least 200 years. Did you take that into consideration when making your prediction? :)
What you fail to realize that these replacement/ augumentations will not be possible until research labs have access to 128- or 512- bit general purpose computers.
Tor