AMD's x86-64 Moves Forward 384
MBCook writes "AMD Hammer line is definatly moving forward. The Inquirer has a supposidly leaked memo from MS saying that they have working x86-64 silicon that runs both 32 and 64-bit Win XP. Van's Hardware is reporting that MS is backing x86-64 over Intel's IA-64, and that MS has apparently convinced Intel to move to x86-64! There is an article over at Ace's Hardware from CeBIT that includes some coverage of AMD's Hammer line (including its NUMA). Last but not least is News.com's report that MS is preparing Windows to support NUMA." And it looks like the line will be named Opteron.
Uhmmm ... Ok ... (Score:3, Funny)
To me it sounds like a dinosaur ... look ma, all those wild Opterons running around.
Hmmm ... like a bunch of cows is a "herd" ...
Will a bunch of Opterons be called a "beowulf"?
Re:Uhmmm ... Ok ... (Score:3, Funny)
Re:Uhmmm ... Ok ... (Score:4, Funny)
It also tastes really good spitroasted after a day or two in a sushi vinegar and olive oil marinade.
/Brian
Excuse me??!!! (Score:3, Insightful)
hmmm .. sounds fishy (Score:5, Interesting)
It scares me to see huge companies like this, conspiring in court.
Honestly though, I thought it would have been Intel, not AMD doing this.
Re:hmmm .. sounds fishy (Score:3, Insightful)
Re:hmmm .. sounds fishy (Score:3, Insightful)
Everybody knew Intel wanted to introduce a new instruction set with the Itanium and retire the x86 instruction set for good. It was a noble effort on Intel's part.
AMD saw an oppurtunity. They knew that software development is slow and painful, and porting software form one architecture to another (especially when you never planed for it in the first place) is a long agonizing process. Most windows software is written for x86 32, there is a lot of it, and even with good tools it would take a long time to port everything to IA64. So, AMD did the next best thing and built 64bit extensions on top of the x86 instruction set (still some work to do, but a lot less).
Microsoft of course, not being in this for the higher noble cause, realizs that it is cheaper, quicker, and easier to just extend their tools to use the x86+64 instruction set rather than redoing everything in IA64.
Now, Microsoft, having the power it has tells Intel they don't want to port to the IA64. Intel panics, Microsoft gets its way (again), and we have yet another example of how Microsoft has too much power (when they can strongarm Intel like this, things have gone WAY too far).
Just another day in cyberspace...
Re:hmmm .. sounds fishy (Score:2)
So you would rather that Microsoft be forced to port windows to IA64? What about PowerPC, how about Alpha, should we force them to support those again too?
Re:hmmm .. sounds fishy (Score:4, Interesting)
Re:hmmm .. sounds fishy (Score:2)
Unusual for MS (Score:2)
But microsoft can't compete with AMD. It would take them too long to spin up, and they don't know shit about that industry. AMD, on the other hand, could EASILY compete with microsoft, by the simple expedient of hiring some programmers to work on linux, or some other open source operating system. I just used linux as my example to yank your chain. They contribute code, gain cred, and make a whole bunch of crap work beautifully with their equipment.
Won't happen though, because business as usual is good for everybody - Well, if everybody's a big company. It sucks for us, good thing competition isn't going to go away any time too soon. Even if AMD or intel went under, there would still be other CPUs in the world. But anyway, intel and AMD could conceivably swap places - over time, and they are getting closer, you must admit - but it would just end up being AMD vs. intel with AMD in the position of power. We can play musical chairs, but the tune stays the same.
Re:Unusual for MS (Score:2)
In fact, the only marketing leg-up for GNU/Linux over Windows is the cute Penguin. Everybody loves my Linux Fund credit card, regardless of what they (don't) know about GNU/Linux. =-)
-Paul Komarek
Re:hmmm .. sounds fishy (Score:2)
Hopefully the Judge will be made aware of the back-scratching that is going on and will discount AMD's testimony appropriately. BTW, has there been any pro-Microsoft testimony that hasn't been paid for?
Looks like the gambit paid off. (Score:3, Funny)
Re:Looks like the gambit paid off. (Score:2, Offtopic)
Re:Looks like the gambit paid off. (Score:2)
I want some of the dope the moderator was smoking.
Re:Looks like the gambit paid off. (Score:2, Funny)
Re:Looks like the gambit paid off. (Score:2)
I think Megatron would have been a cooler name.
If you had waited 5 minutes... (Score:5, Informative)
Forget the rumors, go to the source [amd.com]. It's out and it looks to me like they haven't made any major changes to their plans. The big news is the MS support for Windows. Linux and *BSD should have no problems, as the x86-64 simulation code has been out for a while [x86-64.org]. This is a good thing for everyone...
Derek
Re:If you had waited 5 minutes... (Score:2)
next you'll be saying "read the article" and other such rubbish...;)
Re:If you had waited 5 minutes... (Score:5, Informative)
-----
AMD also plans to demonstrate its AMD Opteron dual processor-based server running a developmental 64-bit version of Windows at its annual shareholders' meeting in New York City on Thursday, April 25.
The demonstration features a server running a 64-bit Windows operating system, 64-bit applications, and other standard 32-bit office software, all on the same system. Those applications then are remotely accessed by the 8th-generation AMD Athlon desktop PC running Windows XP, illustrating the compatibility, flexibility and interoperability of AMD's 8th generation processor family.
Re:If you had waited 5 minutes... (Score:2)
That's funny; since when is the K7/Athlon 8th-generation?
Re:If you had waited 5 minutes... (Score:2)
What does it have to do with the CPU? If my X11 applications are remotely accessed by the Intel 486 desktop PC running Debian, does it illustrate the compatibility, flexibility and interoperability of Intel 486 processor family?
5% core performance increase (Score:3, Interesting)
Re:5% core performance increase (Score:2)
Re:5% core performance increase (Score:2, Informative)
Re:5% core performance increase (Score:2, Informative)
AMD is predicting a 20% improvement in performance from their integrated memory controller (I ran some numbers in my head a while back, and came up with slightly more then a 15% improvement on average, so 20% is perhaps slightly optimistic, but definately not out of line IMO). They're also predicting an additional 5% improvement from other minor enhancements to the core, plus they're planning on cranking the clock speeds up.
As for SSEII, I don't think that they're considering that at all at this point. SSEII is used only very rarely, and typically it adds very little to the performance. There are a few limited cases where SSEII can DRAMTICALLY improve performance, but it's pointless to make a general comment based on those rare cases.
Also, some people have been tossing around numbers for performance improvements related to recompiling apps for 64-bits on Hammer chips. Normally recompiling to 64-bits wouldn't add anything to the performance, but one of the important additions to x86-64 is that in 64-bit mode, the chip has twice as many general purpose registers as in 32-bit mode. Since the lack of general purpose registers has long been considered one of the weak points of x86, this should boost performance a bit. Now, by how much, I couldn't say. Some have suggested that it would be as high an extra 15% performance boost, though I think that would be a rather optimistic. I'd guess more on the 5-10% range on average, with some programs actually being slower (64-bit programs need more memory bandwidth then 32-bit ones).
SSE2 (was Re:5% core performance increase) (Score:2, Insightful)
Contrary to your comment, carefully written C code can be auto-vectorized by simple recompilation on at least two compilers for x86, and intel's free (as in beer) compiler for linux is one of them. Intel might have shot itself in the foot by releasing auto vectorizing compiler free of charge for linux, otherwise I wouldn't assume linux would utilize (as opposed to just support) SSE2 in the near future.
Re:SSE2 (was Re:5% core performance increase) (Score:2)
Even the game programmers I've spoke to about multimedia extensions on x86 cpus have had little or no luck getting good performance from these extensions. Granted, some folks (Tim Sweeney?) seem to have done okay, but overall these extensions seem to be pointless.
It seems that Cray is still the only group that has built a truly useful vector machine for use in science.
-Paul Komarek
Re:SSE2 (was Re:5% core performance increase) (Score:2)
GCC wasn't meant to beat vendor compilers. Basically, GCC works for a lot of platforms. x86 is different from many platforms, and as such optimizations that work on it will slow code down on other architectures. Thus, incorporating some of what makes x86 code good on the intel compiler would either slow down other architectures, or be hell to optionally include.
If you want it, you could go do it, and put it into gcc, but it could suck. Especially since gcc ins't necessarily the nicest code-base from whhich to work.
Basically, intel's architecture doesn't play nicely with others, so it'd be hard to make GCC really good for x86. And time-consuming, when you already have a compiler that works for that's free-beer. Why would you wantto change it?
AMD is officially announcing this (Score:4, Informative)
When AMD announced this at a press conference a few hours ago.
AMD nails Microsoft backing for Hammer [com.com]-CNET [com.com]
MS to confirm Hammer support [theregister.co.uk]-The Register, UK [theregister.co.uk]
Microsoft to Support AMD's Hammer [eweek.com]-eWeek [eweek.com]
Webcast of today's conference call (Score:3, Informative)
A webcast of today's conference call announcing Opteron is available here [amd.com]
-Mark
A bit late? (Score:2)
Slashdot's queue must be way deep.
Opteron (Score:2)
For example, using optical chip technology.
I guess that's entirely forgiveable as Intel's "coppermine" implied using copper interconnects.
I really don't buy some of this (Score:2, Interesting)
Van's Hardware is reporting that MS is backing x86-64 over Intel's IA-64
Windows XP has been running on IA-64 for ages now, Nvidia's got drivers for it [nvidia.com], why would they support x86-64 OVER IA-64? Why not both? It appears they're doing both, and I've seen absolutely nothing to say otherwise.
It wouldn't make any sense for MS not to support both ISAs. It's entirely possible (it's been done already), so why not keep them out there?
I think Van Smith's a little off here.
Re:I really don't buy some of this (Score:2)
Hmmm. quid pro quo. (Score:5, Interesting)
Looks like AMD is getting their end of the bargain. Whether windows will even run on intels new chips or not, AMD looks like they have a headstart and the backing of M$.
I suppose I should have expected this. AMD was staking it's whole future on their 64 bit solution support for which might have been iffy. With this they practically guarantee their future, maybe even take the lead from intel. We'll have to see how well prepared intel was with plan B (copying AMD if plan A failed).
Now we can re-do those bill gates phonecalls in the last story and fill in the proper information.
Bill Gates: Hello mr Sanders, I need a favour. How would you like M$ to back amd-64 over intel-64?
Sanders: Ok Bill. What can I do for you?
Bill Gates: We would like you to be our witness in this pesky antitrust trial. What do you think you could say in our support?
Re:Hmmm. quid pro quo. (Score:3, Interesting)
the prosecution was aware of the communications and it's in the court records.
4-level page tables (Score:3, Interesting)
Though, IA-64 is pretty questionable too. The VLIW aspect is cool, but the compilers are a nightmare. Nobody knows how to write compilers to take advantage of speculative execution, for one thing.
I'm not familiar with any other 64-bit architectures, but surely they're better than both of these?
Re:4-level page tables (Score:2)
From what I understand, the 32->64 PPC transition will be seamless, and 32-bit programs will run without a performance hit.
How Fast is It? (Score:2)
Given how well AMD designed and executed the K7 (Athlon) my expectations are to see some seriously good performance for their follow-on chip.
But, past performance is no guarantee of future results. Intel's IA-64 is evidence of that.
Does anyone have any idea how fast the K8 will be in real life?
Everywhere I've looked I haven't seen any performance numbers for the Hammer. How does it compare to say, the Power4?
Noooooooo! (Score:5, Insightful)
Another hacked on extention to the same old architecture that we've been using since the 4004 and 8080 (no, seriously). The basic 8-bit core, the bizarrely segmented registers, the warped-ass extentions, and the CISC instruction set... it all makes me sick. Not to mention that we're still using a fucking BIOS.
Have you ever used something with OpenBoot? It's incredibly nice.
But no, we're still using a system that's basically an overglorified 386DX.
Despite the speed hit, the IA64 architecture was a step in the right direction. A big step. In this case, AMD is going to be setting the industry back.
Re:Noooooooo! (Score:3, Insightful)
Re:Noooooooo! (Score:2)
Re:Noooooooo! (Score:2)
I don't want to be an ass, but you can say something like that for a lot of things. Sure, Microsoft has a lot of marketshare, but if you take them off the list, it sure makes Linux and BSD seem a lot better...
Do you see what I mean?
Re:Noooooooo! (Score:3, Insightful)
Re: (Score:2)
Re:Does X86-64 do anything at all better? (Score:2, Informative)
Basically, they did what they could to make it better while still using the same hardware to decode instructions. I'd have preferred it if they had a second, simpler decode unit to handle the new stuff so that the overcomplicated x86 decode could eventually be phased out, but it didn't make sense business-wise for them to do so.
Re:Does X86-64 do anything at all better? (Score:3, Insightful)
Actually, there is another benefit to 64 bit cpus: punishing programmers who make *stupid* assumptions about pointers =-).
-Paul Komarek
Re:Noooooooo! (Score:2)
You're correct about the overglorified 386DX thing, though. That's why there are a large number of
What bothers me more is this: AMD appears to be on the verge of taking over the standards war from Intel. Fine. It's about time Intel got smacked down by the market instead of the courts. But they're doing it with a hand up from M$... that doesn't bode well for the future, I think.
That said, I won't turn down an Opteron box if I have the opportunity to build one (wouldn't take an Itanic if you paid me though), but I'm running Intel Inside because it cost me $200 when I bought it... moreover, I'm typing this on an iMac.
/Brian
Re:Noooooooo! (Score:2)
If you visit www.x86-64.org, you'll see AMD's efforts to garner open-source support. AMD is relying on MS for an x86-64 port of windows. It's a make-or-break deal for AMD, it helps them tremendously for MS to "validate" their version of 64-bit x86. Whether this relationship continues in the future remains to be seen, especially if Linux ever fulfills its destiny and makes MS irrelevant. Intel and MS were once favorite bed partners.
Don't LAHF (Score:2)
The LAHF instruction loads some of the condition flags into the AH register. The bit positions emulate the flags register of the 8008 processor so LAHF+PUSH AX is equivalent to PUSH A. This instruction was designed to support automatic translation of 8085 code to 8086.
All x86 processors still support this instruction (yes, that includes your latest Pentium)
Success (Score:3, Insightful)
1. Software - the 8086 had a leg up on everyone because it had a translator which allowed the thousands of CP/M applications to be ported to it easily. The killer ap at the time was WordStar.
2. The 8086, and in particular the 8088, were less expensive to build machines around.
3. The 68000 and the Z8000 were comparatively elegant and beautiful designs; the 8086 was strong and ugly. Pick Mike Tyson over Cindy Crawford in a fight. Intel was able to turn marketing from a engineering and software beauty contest into a fight - and it came out on top.
Today the shoe is on the other foot.
1. The Opteron does a much better job of running 32 bit aps than either Merced or Mckinley - similar to advantage 1 above.
2. The Amd processor will be a lot less expensive to build for - reason number 2 above.
3. The Intel processor has the beautiful new architecture - the Opteron the good old strong and ugly one.
The only way Intel is going to come out on top this time is to make an even stronger and uglier 64 bit version of the X86; something which looks like a 64 bit version of the current Pentium 4 - ridiculous pipeline for super high clock speeds etc.
Right now things don't look very good for Intel.
Re:Success (Score:2)
At the time that the 8086 came out Intel also produced a 32 bit processor which was going to use Ada as its 'assembly' language. It was a complete and total failure. No one ever bought any to speak of - it was actually slower than an 8080 eight bit machine!
That older 32 bit flop kind of reminds me of Itanium; a grandiose architecture with no performance and no software; other than those minor flaws they are both fine machines. I expect the Itanium to have about the same level of success in the market place as it did.
Re:Success (Score:2)
I disagree - But what they DO have to do is work out a better compatibility layer. That is not negotiable. You must have 100% compatibility at the hardware level or you are proverbially screwed, blued, and tattooed. Or however that goes.
You're right about the cost thing though. If it's not dramatically better at being a server (which it could be; Anything pushing a lot of data will benefit greatly from 64 bit registers) then it will have NO purpose at all, wither, and die the death of a thousand dogs, amen.
Opteron is optional? (Score:2)
The first thing that comes to my mind is "optional", which is perhaps not so good for the company holding the second place in the market. Maybe they should have called it the "Superon".
Incidentally, I wonder how many people relalize that "durus" means "hard" in Latin, so "Duron" was kind of suggestive...
Rumors Rumors.. (Score:2)
Re:What about Linux? (Score:2)
Re:What about Linux? (Score:2)
I think AMD did pretty well with promoting and supporting x86-64. The x86-64 website [x86-64.org] has soeme decent stuff including emulator, experimental compiler, etc. It was a smart move and got the developers on board early.
Re:What about Linux? (Score:3, Informative)
Re:What about Linux? (Score:2)
Re:The bit stuff, explain to a layman. TIA (Score:5, Interesting)
Intel MMX/SSE are 128-bits already.
But here are a few arguments against it--
1. bus widths at 256-bits are a friggin nightmare to design to run at multi-GHz...
2. To support 256-bits, every path needs to be this wide, which would blot the die so much that you couldn't meet gigahertz timing, not to mention how poor the yeilds would be
most game architectures pump graphics data around at 256,512,even 1k-bit wide busses... not the CPU core. But that kind of precision for the geometry processed in the CPU core is not necessary.
Re:The bit stuff, explain to a layman. TIA (Score:4, Informative)
Cost. The bill of materials on a motherboard is insanely tight -- they count resistors, remember! All of the fancy interconnect to go optical is way to expensive, and has very little benefite: aka, ROI.
Beside, what good does it bring? I agree that copper limits on a motherboard are approaching rapidly: anyone who has ever tried to debug a RAMBUS implementation knows how painful it is to build interface hardware to debug a 1ghz strobed differential bus. However, I would think that until the b/w at the CPU and DRAM _PINS_ vastly exceeds what is possible with a copper trace, the ROI on optical would be nonexsitant.
I need to re-read AMDs point-to-point proposal, I'm not sure I buy their claim that adding additional CPUs doesn't decrease bandwidth.
As for symmetric-MP, et al: there are lots of weird topologies for MP out there in server-land. The first teraflop machine was PentiumPro bus architecture, which is only 4P scalable on Intel arch, but custom chipsets can do anything!
And when I say "crap", I mean, "crap". I firmly believe that if both giants were not chained to their product roadmap and stock-holders, aka profits, then we would see some truly efficient high-performing architectures. A giant can't take a 90-degree turn... that's why all x86 architectures are basically suped up jalopies -- making too sudden a change can be devastating if you don't have the capital. Look at Itanium -- if AMD spent the resources Intel did, it would have broken their bank like the Cold War broke Russia's. Look at AMD bolting on *-64, it's basically a blower on a Chevette!!!
I'm _really_ rambling, I'll stop now.
Re:The bit stuff, explain to a layman. TIA (Score:2)
64-bit in the context of this discussion means address bits. It'll be a long time before console games need 64-bit addressing.
Re:The bit stuff, explain to a layman. TIA (Score:3, Insightful)
So what you have is a SIMD processor, that can work on 16 8-bit operands at the same time (same opeartion, parallel data). The MMX/SSe ALU is 8-bit wide, not 128bits!!!!
The original post asked for wider buses like game consoles. Are you under the impression that game boxes are multiplying 128-bit long numbers together? No. They're working on little pixels and single-precision floating point coordinates.
Very few people need 64-bit integers for math, either. As I said, the big deal is longer address pointers.
Then again most people here have no frigging idea about CPU design, and they speak from their asses.
Rest assured, I know plenty about CPU design.
Re:The bit stuff, explain to a layman. TIA (Score:2)
- Anyone here to give a good reason not to have 128 or 256 bit processors?
SureSeriously, way-back-when, my company outfitted the management staff with the 386/SX-16 desktop models, while reserving the more powerful 386/DX-25 machines for the development staff.
The majority of the business world (you know, Email, word processing) doesn't even need a 64-bit processor, much less 256-bit.
It probably depends on your application. Simply having them for the sake of having them isn't enough.
Do you have a good reason to have them, aside from bleeding edge video games?
Re:The bit stuff, explain to a layman. TIA (Score:2)
In the case of PC processors, thing are a little more sane, in that we're generally talking an x-bit processor to mean it has x-bit general purpose registers and an x-bit address space. Sometimes these processors use more bits in other places, like wider registers for SIMD operations, or wider data busses. No doubt if the Pentium was used in a game console, it would be described as 64- or 128-bit (hmm...just like the Xbox), to keep up with the marketing spin from the other consoles.
Re:The bit stuff, explain to a layman. TIA (Score:2)
And the 2560-bit wide thing is inside the Graphics Synthesiser, between the rasterizer and the memory. It has 4 MB of frame buffer, implemented on the same chip (embedded DRAM), which is why the bus can be that big. It gives for nice-looking bandwidth numbers, if nothing else.
Re:The bit stuff, explain to a layman. TIA (Score:3, Informative)
1) Cost.
If you have to make everything X times wider (eg registers, buses..) you will use approx X times more chip area -> Higher cost. So to keep a constant cost, you have to wait until the silicon guys come up with some process that can make your chip X times smaller.
2) Power consumption (heat dissipation)
A wider bus will need more current to charge it's capacitive load. If the load gets higher your only options to keep a constant power consumption and keeping your processor from melting are these:
* lower probability for bitchange (smarter coding)
* lower frequency (not desired, right?), or
* lower voltage (1990: 5V, 2002: 3.3V. 2010: 1.5V?)
Perhaps 2) is not a real issue wrt bus sizes, I haven't investigated it. Take it for what it's worth; a semi-educated guess.
I guess that in video game consoles they have either the margins to take the higher cost, or they use 128-bits only in parts of the processor and didn't tell the marketing department.
Not the same bits. (Score:2, Informative)
When a CPU is 64- or 128-bit, that means its computational units can crunch on integers 64 bits in size. Roughly speaking, a 32-bit processor can work on integers between 0 and a few billion (2^32 is around 10^9), and a 64-bit processor can work on integers between 0 and a billion billion (2^64 is around 10^18). Think of a pocket calculator with twice as many digits across the display, and you have the right idea. Same old calculator, bigger numbers.
Re:The bit stuff, explain to a layman. TIA (Score:3, Informative)
Those 16 Billion GB of data fill up 64-bit. Say you had a 256-bit processor? You could count to a LARGE number. Whoop-de-frickin'-doo. When was the last time you needed to count to that large a number? Or one of your programs did? Probably very rarely.
SIMD uses aside (which have been mentioned elsewhere in responses to this), you don't need that much. In fact, 256 bits would decrease performance. Why? Because when you tried to pull that information in out of memory to the cache, or from disk to the memory, you'd have more time spent waiting for these bits to be transferred around. In fact, this sucks the most because almost all of those bits will be 0 (unless you're dealing with small negative numbers, in which case they'll all mostly be 1).
Numbers that are this big are used so infrequently that you can use bignums (used in lisp, for example) to represent them without taking much of a performance hit at all in the common case, and the exceptional case (VERY rare) will only be maybe twice as slow, which makes the average case faster.
Thus, if you want a slower computer, go design a 256-bit processor, by all means.
-Dan
Re:The bit stuff, explain to a layman. TIA (Score:2)
Prime numbers, large numerical simulations of gas glouds (yes I know there are other ways of doing this....)
Re:The bit stuff, explain to a layman. TIA (Score:2)
Re:The bit stuff, explain to a layman. TIA (Score:2)
Consider: To process any character in the English language, you need only eight bits. That's it. That's one-quarter a register in a 32-bit machine.
And, unless you or the assembler uses a decent amount of technical trickery, that's all you can get in there.
(Case: Intel processors have four main registers: EAX, EBX, ECX, and EDX. These have a high word and a low word (the low words are AX, BX, CX, DX for reverse compatibility with 16 bit code). Each low word has a high bit [ABCD]H and a low bit [ABCD]L. )
Addionally, for numbers.. There ain't too many folks that need to process numbers on the order of 2 to the 128th power, or floats that have, what? twenty digits? thirty digits of precision?
When the numbers get that detailed, you're better off with a quantum system anyway.
Re:The bit stuff, explain to a layman. TIA (Score:4, Informative)
And a 64 in the processor. IIRC, the processor is based on the Alpha core. And when the alpha came out, it was faster than anything 32 bit. But comparing the X-box and the Nintendo 64, which were released many years apart won't buy you much of a conclusion other than current processors are generally faster than older processors.
All other things being equal, a processors with larger word size (instruction sizes and address sizes) will be faster than those with smaller, though, depending on application, the results can be negligible or even worse, especially if compilers and programs aren't properly optimized.
Of course, I don't really know, I'm just guessing, just like the rest of you ;).
Re:The bit stuff, explain to a layman. TIA (Score:5, Informative)
I disagree from an architectural standpoint. In an ideal world, we'd all have 8-bit machines. All our arithmatic would be insanely fast; we'd be able to use combinational logic to allow two probagation levels for ANY operation (add, sub, mul, div, sqrt, log, etc). That's because it's cost effective to do so; a minimal set of possible outcomes. I'm not completely sure, but I'll speculate that it's possible to arbitrarily generate an arbitrarily sized number from just these 8 bits; though most likely it would be programatically (even if done via micro-code), and thus would be non-optimal for larger than 8-bit data-sets. So obviously, as we've been able to, we've increased the data-length throughout history as we've demonstrated a need.
Contrary to the impression that's given in these posts, a larger word size fundamentally is slower in calculating smaller values. Sticking with higher performance two-stage combinational logic requires an exponentially increasing number of transistors. Breaking the logic up into tiers allows designers to trade the number of transistors for the number of probagation delays. The more delays, the slower the clock; the more transistors, the less practical the design (due to heat, cost, and feasibility of fabrication). Pipelining somewhat helps aleviate the issue of extreme probagation delay, but it's impossible to achieve 100% efficiency, and thus you're practically garunteed slower operation for deeper pipelines. What's more, pipelining requires additional probagation layers for buffering, so you take an immediate performance hit; speculating that you'll achieve greater over-all performance.
In an ideal architecture, you'd minimize the probagation delays for each instructional unit, but practical measures say you must group most, if not all, of the CPU such that the slowest part drives the system. (P4's are nice in that they sub-divide the clock for the simpler integer units).
Combining the two ends, we can better appretiate the trade-off.. If we're performing large-valued arithmetic which is slow programatically (emulated 64bit), then it's worth the extra cost (towards the speed of each operation, and in terms of the number of transistors). In other words, one hardware 64bit add is most certainly faster than than several assembly language instructions that piece together 32bit values. BUT, now all your 32bit arithmetic is slower (unless you have separate 32bit/64bit logic cores).
It's possible to design 32/64bit cores that only take as many clock-ticks to complete as necessary, and thus 32bit arith isn't horribly slower, but there are definately additional probagation delays. The augmentation to 64bit can never increase the speed of a 32bit operation. (Any speed ups must be due to over-all advances in computational efficiency, which should benifit a pure 32bit core even more).
The trade-off must then be a statistical one. We cost out the largest word size that provides benifit. You're going to have arbitrarily large ALU operations (just look at encryption), so choose a cutoff where a certain percentage of all operations occur at that high of a word size. This is how we moved from 8 to 16 bit, and then the painful shift from 16 to 32 bits. And for server-targeted machines, the shift has already been cost-out to adopt 64bits. The desktop has not yet made sufficient requirements to adopt 64bits, though the underlying x86 CPUs are being shared in server-space which is nudging 64bit's acceptance.
Another important factor (which is presumably obvious in concept) is that a higher word-size has a greater probability of wasted space. A 1-bit boolean, for example, wasts 63bits.. Booleans are very common, and though they can easily be consolidated in c-struct's, such is rarely the case, since there are memory alignment issues (and flat-out laziness on the part of programmers). The wasted word-space also affects the instructions. Rarely do you actually see 64bit aligned CPU-instructions (except in VLIW or in places that the data-word-size was irrelevant). Such a situation would have massive implications towards performance. But one serious consideration is that the population of 64bit constants using a 32bit instructional word is expensive. Now you have to perform at least 3 (probably 4 or 5) instructions just to load a constant. Suddenly "a++" starts to look scary (at least when non-optimal compilers are used). In all cases sub-word-size'd instructional arguments are permissable to the delight of compiler designers, but there are still classes of problems that thwart this.. Namely memory addressing...
Memory addressing is arguably the strongest supporter of 64bit architectures. The 4GB limit is already apon us on desk-top machines (I have half a gig on all my home machines, and I don't need it). When you add swap-space, it's entirely possible for modern desk-tops to run enough apps to desire 4+Gig of memory. (Especially considering that large chunks of the address space are wasted). Aside from the various tricks designers have employed over the years to avoid augmenting the address space (8086's segment-registers, 80386's segment-selectors, OS's swapping out apps completely from memory, etc), it's arguably slower to emulate larger address spaces.
In addition to the above arguments against larger address spaces, there is massive cache polution; doubling the word-length, literrally halves the usefulness of a cache-line-load, unless you were previously emulating a larger word-size. You can only load 4 words on a pentium-class cache-line-fill instead of 8. Your bandwidth requirements litterally double (unless you don't standardize at one word-length).
Now in contrast, there are a few advantages. If your minimal word-size is larger, then the number of address pins that you need are reduced. But this is really independent of the core word-size. Pentiums have long required 64bits for their external bus, and use even larger cache-line sizes. Thus most of the advantages attributed to this argument are moot.
Theoretically, an architecture can be designed to split an ALU such that it acts as either 1 64bit unit or 2 32bit units. This is especially true for vector-cores (which are already up to 128bits for main-stream processors). In general, however, there is still the trade-off here, since additional logic-probagations are required which slow down the general case of only a single But comparing the X-box and the Nintendo 64, which were released many years apart won't buy you much of a conclusion other than current processors are generally faster than older processors.
I'd like to address the nature of large bit-sizes with respect to graphics. While this isn't my expertise to the extent of the above, this primarily affects the bus width. In graphics, you commonly have multi-integer structures (red, blue, green, alpha (opacity), Z-depth (the depth into the screen the geometrical object that drew this dot is), stencil, etc). The entire structure is usually just 16bits, 32bits, 64bits, etc. The larger the structure, both the more features you can pack into it, and the more accurate each individual number can be. Thus saying that an architecture is 128bits purely based on this is very misleading. What's even worse are labeling the bus-width numbers (e.g. 128, 256). That's like calling the Pentium I a 64bit CPU, just because it has a 64bit bus (used purely for cache-line burst fills). Yes it makes it go faster, but so does shortening the length of each wire; it's not really innovative. I'll throw this in, but I'm starting to get in over my head; Graphics units (especially the filtering parts) make heavy use of hard-wired combinational logic units. The number of bits going into these units is really meaningless (how many thousands of wires go into the control logic portion of a CPU?). Thus the ability of a custom pieces of hardware to utilize larger bit-depths is unimpressive. What would be impressive would be to say that a Graphics unit does it's integer / floating arithmetic in 128bits so as to minimize error (even though the input/output might only be 8 or 16bits per atomic unit).
-Michael
Re:The bit stuff, explain to a layman. TIA (Score:4, Insightful)
8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit. The CM-1 used 1 bit processors, and could do everything. But why 8 bit?! That's sort of whack.
A) consolidate in c-structs? Programmer laziness?
Don't bash the programmer, at all. That's just cruel. The programmer shouldn't have to. That's the compiler's job. However, that can often slow down the code, when it has to mask all the bits, op, then mask all the bits again. So, just using one word for a boolean makes sense. Surely, though, a compiler could do what it wans.
B) Constants get loaded into a different segment than the code, so they won't be in the code, most likely. Unless they're ints or somesuch, in which case you can just use an add-immediate to move them in, and in almost all cases (as you YOURSELF very specifically state) they won't take up more than one immediate.
C) "a++ looks scary"? Umm, a++ will still take one operation (add $rx, $rx, 1). What are you even talking about? Not to mention that compilers optimize.
D) You can still have 32 bit data values in a 64 bit computer by loading the words from memory differently, so don't think that suddenly EVERYTHING has to be in memory as a 64 bit value just because your architecture is that.
E) On a 32 bit architecture (at least, real ones), the 4 gig memory limit (2 on certain ones, e.g. MIPS) is per process, not per system. Thus, you can have many processors, each of which have 4 gigs of memory allocated and using running on a computer with 512K of memory. It would be slow, but that's the beauty of software.
Re:The bit stuff, explain to a layman. TIA (Score:2)
Nothing magical about 8bits, except that we like multiples of 8. An 8bit add requires two 8bit numbers = 16input bits, and 8 output bits. Ignoring optimization and implementation complexities, that's on the order of 65 thousand transistors for a two-level adder. That's definately do-able in today's technology.
Two 16bit numbers on the other hand, would likewise require on the order of 4 billion transistors, which it not currently possible with today's technology (my guess is that by the time it is, we'll be using 128bit ALU's).
My point was to find the most practical pure combinational logic unit. Thus to suggest a 1-bit machine implies that we miscommunicated.
An alpha has a nice little byte-swapper which relatively efficiently extracts a byte out of a multi-byte word. It's computationally slower to work with than just testing the whole word, but when you take into account bandwidth / cache-space considerations, it's a boon. It can't be easy for a compiler to optimize away:
struct {
int f_flag1, f_flag2;
}
Can it drop the flags down to 1 byte?
While it's not always true for each architecture, you should find higher performance swapping out the int's with char's.
I'm not familiar enough with the state-of-the-art in compiler technology, so perhaps this can be determined. I was just generalizing on this type of point, nothing more.
The points you mentioned here would be included in the sort of tricks that have been devised over the years to avoid upping the word. It just furthers the idea that larger word-sizes are expensive and worth side-stepping.
-Michael
Re:The bit stuff, explain to a layman. TIA (Score:2)
B) That's why people have bool's already. Also, if you only assign 1's or 0's to the ints, then it can drop them down. This is how auto-vectorization works.
E) This isn't a matter of upping the word, it's a matter of virtualization, which is a useful abstraction.
Re:The bit stuff, explain to a layman. TIA (Score:2)
Re:The bit stuff, explain to a layman. TIA (Score:2, Informative)
Re:The bit stuff, explain to a layman. TIA (Score:2)
-Dan
PS: That is, in fact, huge.
Re:The bit stuff, explain to a layman. TIA (Score:2)
"64-bit processors tend to be slower than there 32-bit counterparts"
Depends on the Architecture, if the instruction
sizes are the same, and the 64-bit chip can
also run 32-bit code, then clearly the 64-bit
one will be faster.
Best guesses so far, reckon [aceshardware.com]
that x86-64 code should be about 15% faster than
x86 code, mostly due the doubling of the number
of registers from 8-int 8-fp (SSE) to 16-int
16-fp. This is in additional to a estimated
25% gain in speed over the Athlon at the same
clock speed and however many, more GHz AMD can
squeese out the new core.
Re:The bit stuff, explain to a layman. TIA (Score:2)
Re:64-bit Win XP? (Score:4, Funny)
Re:Nice. M$ once again stifles innovation ... (Score:3, Insightful)
And I'm sure it has nothing to do with the fact that every man, woman, child and manager on the earth doesn't want to re-purchase every piece of software and hardware they own.
Intermediate? (Score:2)
Re:Intermediate? (Score:2)
Re:Intermediate? (Score:2)
Even when you're placing new ones alongside a redundant one? (Say a 64-bit operation of the same type instead of the 32)
What about PPC? (Score:2)
Re:What about PPC? (Score:5, Interesting)
Very simple. Lack of competition.. They held a monopoly on ALL OS / motherboards. The only real competition that I'm aware of were the 3'rd parties that sold the various chips / expansion cards.
When you have a vertical monopoly like that, you can coordinate an architectural shift. If Intel decided to start a new CPU line, and it turned out to not provide the best bang-for-the-buck, then AMD/Cyrix competitors could supply legacy and current MS-products a better alternative. Intel would have lost all that money. From the other side, MS is spread so thin that they don't have the time to rework their core to be optimal on multiple platforms (look at the death of NT on any non x86 platform). The lack of a compelling reason for someone to purcase the alternative platform says that MS shouldn't devote too many resources in that direction, which of course kills it off. Hense platform architects are at the mercy of software people, who must provide killer apps for that platform.. If any major killer app isn't immediately available, then a domino effect of lost support will occur; and more importantly, business people understand this a priori.
This is actually a lot more exciting then it might first appear. On the one hand, you have a controlling hand-of-God who enforces their will. So long as they can project a bottom line that benifits their customer, they can make radical changes (shedding virtually all of it's former self). On the other hand, we have multiple independant organizations, who each act in their own best interest. In monopolized environments, changes are swift and clean (but not always in the best interests of everyone). In independent environments, no organization can squander or otherwise take too great a risk. Efficiency is upheld, since only rational decisions can be made (involving the mutual benifit of progress). The side effects are a slowing of evolution, and an accumulation of "useless appendages". On the other hand, it provides an incredible level of trust on everbody's part that the architecture has staying power; that it'll weather the storm of change, instead of flippantly changing with the current mood; throwing 3'rd party interests aside when it's convinient (read Apple's resinding licences over the years).
Personally, I think an architecture that has "grown" over the years is more remarkable then one that simple borrows the best ideas that come out of universities.
Note that I'm not really advocating x86's. I'm just admiring it's successful history. The proliferation of UNIX and the general ability to recompile source could theoretically alleviate a "better" platforms' lack of killer apps, and thus perpetuate a radical acceleration of architectural designs.. Go Linux!!
-Michael
Re:Nice. M$ once again stifles innovation ... (Score:2)
Aren't these are the same men, women, and managers (children, managers, whatever ;-) who buy new computers and apps every 1.5 years anyway because their previous computers die of Old Windows Disease/Planned Obsolescence/Lack of Support/etc? They re-buy most of their hardware and software over and over again.
Re:Nice. M$ once again stifles innovation ... (Score:2)
They'll probably push one or the other once the market starts leaning in a particular direction. I really hope it's IA-64. I want x86 to die as soon as possible.
Re:Nice. M$ once again stifles innovation ... (Score:2)
The engineer in me doesn't like x86 because it's kludgy, and overly complex (has 4 operating modes of which most folks use 2, for example). Intel and AMD have to waste a lot of silicon that translates x86 instructions into their internal instructions. Seems like it's about time to start using something modern, not built on a legacy ISA.
Admittedly, I haven't done too much assembly work. Perhaps x86 is great. But most of the reading I've done and the system architechture classes I've taken lead me to believe that x86 is just a little too dated.
Re:Nice. M$ once again stifles innovation ... (Score:5, Insightful)
I can't say what's correct myself, but I think you may be jumping to conclusions.
Re:Nice. M$ once again stifles innovation ... (Score:4, Insightful)
It's not what I want, it's not what you want, it's what the MARKET wants. I know. I used to work at DEC/Compaq and API. The market drives technology, not the other way around.
If you read about the architectures, you'll see that when you compare x86, x86-64, IA-64, and Alpha, that -technically-, the Alpha was the best. However, it's applications that call the shots. x86 might not be as "elegant" solution as IA-64, but it allows easy migration to 64-bit computing without the expense of moving to a totally different architecture. It's a low risk solution. You can convince your boss to update your servers to these new fast AMD systems and run your apps as is, then be a hero when you migrate some big database to use 64-bit addressing and memory management without buying a new server!
I fully expect to see Clawhammer-based motherboards and CPU's at around $300 or so LONG before you'll see IA-64 at that price point. That alone will push x86-64 from the ground up.
(And because of architectures like Alpha, Linux will be ready to roll, fully 64-bit) Not to mention laptops running on Clawhammer!
Re:Nice. M$ once again stifles innovation ... (Score:2, Interesting)
What do you suggest replacing it with???? There's always going to be 1 dominant force in any industry. I don't see what other architecture you could replace it with.
Even if you spent gazillions of $$$$$$s to fab something twice as fast for the same price the competition would catch up within 18 months anyway and there's no way your gonna get all those x86 binaries recompiled in time.
The nearest anyone got was Alpha with FX!32 recompling those x86 binaries on the fly. On the other hand how much faster is it now.... (please factor in cost) and where's that chip designer fellow gone... Hmmmmm....
There are many architectures to be chosen from - for now we have a clear winner - hyper pipelined CPUs with a huge instruction decoder chopping up the x86 instruction format. Perhaps stack machines or some kind of programmable logic perhaps logic in memory. 1 thing is clear - it had better be able to keep up with the best x86 CPU whilst running x86 code. It is the dominant binary format.
Matthew
Re:David Cutler has reportedly voiced ... (Score:2)
With x86-64, you can jump to 64-bit computing without having to dump your legacy code altogether. With some careful recompiling, just about all Microsoft apps today should run in 64-bit mode on the x86-64 platform fairly quickly.
Also, Linux support for x86-64 has been around for some time. I'm sure that it wouldn't take much to release an x86-64 compliant version of every major Linux commercial distribution within one year anyways.
Besides, the cost of IA-64 hardware is still somewhere in the stratosphere, to say the least.
Re:David Cutler has reportedly voiced ... (Score:2)
Re:i386 Redhat RPMs for Hammer (Score:2)