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)
For those who want the article all on one page.
Sorry, but my karma just ran over your dogma.
I think Intel made this change. With the emphasis on speed speed speed, MHz is everything, Intel spent all of its money on clock-cycles and lost sight of efficiency.
Now this is partially coming back to bite them. They can't market the Itanium 1 successfully at 800 MHz, even if it compares with a 2 GHz chip because of the perceived differential. The Itanium 2 fares better, but it's still a power hog. The companies that focuses on a balance between clock-cycles and efficient design are the only winners (namely IBM) because their chips have a wider application. You won't see an Itanium 2 in a laptop, but you might see a PPC 970.
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.
Heat dissipation, in watts, is listed in the table near the end. I believe it was mentioned a couple times, especially in conjunction with the PPC 970 processor.
This article didn't address the embedded space. Who in their right mind is going to stick a CPU with a die size about that of a pack of playing cards in an embedded device?
Notice the absence of the XScale and Hitachi lines of embedded processors? This was a preview of the direction of 64-bit SERVER and WORKSTATION processors.
While you are right, power is a concern, it is way down on the list for the target audience of that article.
Learning HOW to think is more important than learning WHAT to think.
You're not likely to see 128- or 512-bit general-purpose computers in your lifetime, I'm afraid. The increase from 32-bits to 64-bits isn't for performance reasons, it's for memory addressing.
A 32-bit computer can address up to 4 gigs natively. Intel has some extensions to allow up to 64 gigs, but with a performance penalty.
By moving to a 64-bit computer, the address space becomes astronomical - it is 4 billion time larger than the 32-bit addressing space. In the last twenty years, the average amount of memory in a computer has gone from about 512k to 512 megs - it's increased by about a thousand times. At that growth rate, a 64-bit address space would easily last through our lifetimes.
When you see video cards and dedicated gaming hardware that has a 128-bit (or higher) processer, it's done for different reasons. Usually, they need to perform complex mathematical operations that are very repetitive and easily parallelizable, which is not generally the case with a general-purpose CPU.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Wrong. IA64 is not based on x86 at all.It's an entirely new instruction set. x86 compatibility is retained by three extra optional decode stages in the pipeline that dispatch to an x86 blocking RS. They are dynamically grouped into bundles and then dispatched into the normal IA64 instruction stream.
Wow. You could get FOUR P970 from the transistor count of ONE Itanium 2. But the Itanium 2 isn't four times faster than one P970s, its not even as fast as two P970s.
Seems that IA64 is dead. People will go x86-64 for compatibilties sake, and IBM P970 if efficiency is important..
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.
Vertical is the floating point spec score.
/. reader...
Horizontal is the int spec score.
I thought that was pretty clear given the context of the graph and the mentioning of those scores throughout the article.
I guess this article is simply aimed above the heads of the typical
AMD's x86-64 cleans up the x86 instruction set a bit. Everything is still there for compatiblity, but you don't use the stupid x87 for floating point, you use SSE. You don't stick with 8 registers you use 16.
/. crowd knows about computers.
Intel's IA64 is in no way based on x86.
I am amazed how little the
Actually Very Long Instruction Word machines were in vogue about ten years ago. Yale built a 512-bit machine. The compiler technology ended up being the most interesting stuff however, it was bought by cray and resold to various companies ending up in the Intel compilers.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
That was my fault, not Paul's. I cut them off when I converted to HTML. :-(. I've replaced the graph with the correct labels.
Regards,
Dean Kent
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.
I contest that. First of all, 5 years of backwards compatibility is not an argument for SPARC, it's an argument for x86. x86 has 20 years of backwards compatibility.
Second of all, there are only so many application that people really buy "server hardware" for, and as soon as you put more than 3 Gigs of memory in the machine, you gain performance from 64-bit hardware.
The performance gain is particularly big for databases and applications like full text search that have a large working set. Also, crypto software can in many cases reap substantial gains from the native 64-bit arithmetic. In layman terms that means: 64-bit is good for databases and web servers. And, believe it or not, those are the applications people buy server hardware for.
Application servers are cheaper and more reliably done using a cluster of el-cheapo off-the-shelf x86 machines than one big iron, independent of the number of bits.
Integer / Buffer overflows in Microsoft operating systems are horribly overplayed. Many will simply use this excuse to say that Linux is better than Windows, but the arguement has really been misunderstood for a long time.
The reason these errors became popular is because of Win95. Advertised as the "most stable home computing experience yet," it had several issues with overflows, the two most glaring were buffer overflows (which is still present in Windows, but being fixed with new security updates daily from MS), and ye olde integer overflows. The more problematic of the two was the latter, as it would cause blue screens and, later, the "A fatal exception in OE has occurred [...] Now closing the program" error message.
Almost all of the integer errors were fixed from Win98SE on, and are hardly a problem anymore Since 2k/XP (no, I never bothered to waste my time testing WinME). Nowadays it takes a really horribly coded program to get one of those errors, and yet the arguement lives on.
Wow, I guess that could be considered pro-Microsoft, but I've recently aquired some spare karma. Yay! Time to have a karmacue!
Work sucked, until it became unemployment, when it became slightly more tolerable. -Tet
Only the bus interface was 64-bit.
i860 was very innovative for the time, I'm not disputing that, but a 64-bit CPU it was not.
I won't switch until my favorite BSD operating system is supported. It's BSD that's important to me, not the underlying architecture.
Wrong. IEEE floating point is IEEE floating point whether on a 32-bit or 64-bit processor. And it's the FP that matters for scientific programming
> servers are cheaper and more reliably done using a cluster of el-cheapo off-the-shelf x86 machines than one big iron
That depends on the application. Some applications don't cluster well, if at all. Others are so expensive that you can't afford to cluster them. I run apps on workstations that cost up to $600k for a single license. The cost of the host is practically noise.
The Fireplane backplane in a Sun Fire server is a switched crossbar architecture (I guess that's redundant .... any crossbar is a switch).
Max. throughput per address line is 9.6GBps (that's gigaBYTE), with the potential for 18 address lines (That's on a Sun Fire 15k)
Sun's benefits don't come into play really until you hit the high-end. Once you see an E10k or these days, an SF15k kick ass and take names, you understand just why scalability is so damned important!
--NBVB
Actually, it does include the caches, and cache takes up inordinate amounts of transistors. Madison has very large caches, which explain the 440 million transistors (and the 660 million in the Power4 chip).
A deep unwavering belief is a sure sign you're missing something...
We're not talking about the same thing, but the x86 stuff isn't as bad as you say.
d ge _3_pedge_4600.htm
http://www.dell.com/us/en/biz/products/model_pe
-- excerpts
6 x 64-bit/100MHz PCI-X (supports 3V or Universal PCI Adapters); Legacy: 1 x 32-bit/33MHz PCI (supports 5V or Universal PCI Adapters)
See the 100MHz?
512MB - 12GB 200MHz ECC DDR (Double Data Rate) SDRAM Features four-way memory interleaving for higher performance (requires DIMMs to be added in set of four of equal capacity)
--- end excerpt
And that's maybe USD15K (add 4GB etc). How much is that Sun you're talking about? USD37K?
Comparing the price, IO, Mem bandwidth, SPEC scores, it looks pretty attractive compared to the entry level SunFire (2x900MHz 4GB).
I've seen benchmarks on Sun vs x86s and so far my impression is the Suns get slaughtered easily in the low to low-mid end ranges.
As for 64GB RAM X-way concurrency stuff, you could get that if AMD Opteron succeeds.
I don't count Itanium as x86 because so far it isn't - you might as well be running POWER/Alpha/SPARC and an x86 emulator.