Slashdot Mirror
AMD's 64-bit Plot
ceebABC writes "In a long interview with eWEEK, AMD's CEO Hector de Ruiz talks about struggling to compete with Intel, but more importantly about their upcoming 64-bit processors. He says that AMD's 64-bit chips will be comparatively priced to the 32-bit ones, and backwards compatible. He also thinks there will be a market for desktop 64-bit systems. Skip to the last page for the most interesting stuff."
Is there really much consumer (not business) application for 64-bit processors? If so, where would desktop computing benefit?
slashdot!=valid HTML
Will the processors run cooler than the current 32 bit offerings from AMD?
As much as I love AMD, my box is far too loud, and I'm too damned cheap to shell out another $100 for decently quiet fans.
Oh please.. it might have not been the best joke, but there was no need to mod it down.
Didn't AMD announce that they were no longer going to compete for the desktop CPU? And now they say that there *IS* a market for the 64 bit CPU on the desktops!!! Well, are they, or are they not competing then?
I confused!
The only itanium2's avalable are hp's offerings (I think its the rp2600 and rp5670), they have a two way and four way that should have been shipping since August. Considering that HP is the co-developer and only one selling them, might tell you something. Although there have been rumblings that IBM and Dell will be adopting the architecture. I think Dell is waiting for a better chipset from someone besides HP. It seems like AMD is trying hard to move into the low end server business with these, but planning to sell a cut rate model to consumers to help cover their development costs.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
64 bits is useful for databases accessing gigantic datafiles and other I/O intensive operations. High performance computing loves moving 64 bit values around. Ever do a "file" on /sbin, /usr/bin, /usr/sbin on Solaris? 32 bits all the way. The only reason I downloaded a trial copy of Sun's C compiler was to compile lsof for Solaris 9, which, since it talks to file structures, needs to be 64 bit.
I think having 64-bit Linux without buying a SPARC, RS6000 or PA-RISC box will be huge for the enterprise. The rest of us will wonder why our apps still suck.
Just wondering, if Linux already runs on 64bit, which I think it does, and I have not heard of microsoft having anything ready for this market, does this mean that just as gamer's buying games pushed the video card (and in my opinion, the os) market, will we see linux be increasing adopted since it will run 64bit and MS does not?
Just a question.
Thanks for the replies
Sigs are dangerous coy things
Yes it will, due the larger register file of x86-64. Epic ported UT2K3 to x86-64 and said they saw a 15% perf increse vs. IA32-version running on same CPU.
I'm amazed to read the discussion, wether or not 64 bit will succeed over 32 bit processors.
...
This is 10 years after DEC has introduced the Alpha Architecture (in spring 1992).
The Alpha was fun to work with, not only because of it's 64 bit architecture, but because of the clean orthogonal instruction set and it's outstanding performance.
Rest in peace
RE: "If you have a 64-bit 2 GHz processor and a 32-bit 2 GHz processor, the 64-bit processor is going to be much faster."
That is not true. What is your argument for this?
It sounds like you mean in an otherwise equal machine, for a start you are going to have cache problems. Many 64-bit machines use 32-bit instruction formats, but data will be 64-bits and obviously fewer words fit in the data cache than with 32-bit data words. Potentially, that alone can give you a massive slowdown.
Please supply your reasoning for this claim..
OK, a comparison of 32 and 64 bit processors running at the same speed would probably NOT show that much of a difference...
... there might be other areas where 64 bits are better. But 'speed-wise' is not one of them.
/AC doing 64b CPU design for food.
Assuming that the memory subsystem is the same then the 64-bits processor would only have an edge when:
a) Using lots of address space.
b) Doing 64 bits integer arithmetic (floting point arith is the same for 32 and 64).
'Code-wise' probably isn't either as most 64 bit'ers use 32 bit instruction words.
I actually read a primer on AA-64 and instruction words are still 32 bits (actually they are variable length) and the fpu doesn't seem to benefit from 64 bits in the integer units.
Note: What is this stuff about 128 bit graphics? N64 actually had a 64 bit CPU (MIPS).
No this is the interesting stuff
"eWEEK: What does it mean to you personally, though, when a Gateway or an IBM not just stop, but announce that they'll no longer be offering AMD as an option?
Ruiz: I think it's terrible, obviously. It's terrible. I think if you were to talk with Ted Waitt at Gateway, and ask him, "Why'd you do that?" and if he would really tell you why, it's a question of he's being bribed to do it. Now, he's got to look out for his own hide and the company that's probably in great difficulty has got to listen to the huge amounts of money that can help him do that.
But you know what I find amazing, think about the power, is that despite all that, which obviously we really get emotional about the fact that somebody like Gateway gets bribed into doing that, is that despite that, according to Dataquest last week, we're still holding a 19 percent share of the market. That to me tells me we're in the throes of breaking this open"
Hey Intel, see you in court! Of course now that Intel is along with Microsoft backing a group to outlaw opensource in the government, I think its time for the opensource community to boycott Intel. Why should our money go to a company which is now attempting to hurt Linux and opensource? I know because these recent actions, I will NEVER buy Intel ever again!
If you wanna get rich, you know that payback is a bitch
I see many posts here wondering about porting Linux to 64 bit...
Remember the Alpha? 64 bit goodness all the way. Has been running Linux for years.
And for those old enough to remember... Microsoft did support Win NT on the Alpha just a few years ago.
As far as the software goes, both Linux and Microsoft are ready for 64 bit computing.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
A major advantage, especially to the Open Source community of 64 bits on the desktop is software development.
Remember, many (most?) open source developers are private individuals and not huge corporations. Allowing individual open source developers to own an affordable 64 bit desktop machine will allow them to more effectively develop and debug the code that runs on the 64 bit servers.
It only seems natural that a developer, given a 64 bit system to develop and debug code on, is going to produce better 64 bit code. And we all want Linux (and the BSD's!) to be the best 64 bit platform it can be, right??
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
wouldn't the chance of cache misses depend on the caching policy? How does the data size matter? If your policy is good, when your misses will be rare. Otherwise you're screwed even if it is 8-bit
The gain with 64-bit processors is one of address space and nothing more.
Which includes better behaviour for those programs that have to fake larger address space. That would be a speed increase.
I've been eagerly waiting for Hammer ever since it's announcement. High-bandwidth interconnects, 8-way SMP support, and AMD's incredibly high IPC all team up for a chip that sounds like a winner.
However, each chip is only going to get a single DDR333 memory path. With all of this time and effort, and so much at stake for AMD, you'd think that they'd make sure that they did it right, and move to a dual-channel solution, or at the very least, a DDR400 solution - which will be a pretty standard offering when the Opteron/Hammer/Athlon64/Whatever is released.
Sure, it'll perform pretty well with a single channel of DDR333. But I'll bet it would perform MUCH better with more bandwidth. And compared to all of the design and development that they've already done, implementing a dual-channel memory controller really wouldn't have been any significant challenge.
So, I'm not nearly as optimistic. On the other hand, I'm not a skeptic yet. When they come out, I'll see how they perform. But I'm certainly not as excited as I used to be.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
A system starts to "feel" faster when it is about twice as fast. You won't get your work done any faster, but it is a much more reactive and enjoyable machine to work with.
If CPU performance is the _only_ differentiator, maybe. Back in the PII days, I had a 166MHz Alpha (21066) for a personal machine and at work, a PII, 300MHz, both systems ran Windows NT 4.0.
In just about every way, the PII was supposed to be two times or more times better, but the Alpha system actually felt "snappier", despite the computation performance and bandwidth of the PII being tested as 2x faster.
A 64-bit may be great but a 64-bit OS is needed to fully utilize that power. Windows may not be prepared yet for a 64-bit processor and linux will also need an over haul also. Is the world ready to accept a 64-bit processor? for now it is not. Only time will tell if it is.
Talk to the right people and you'll find a beta of win2k server for the alpha cpu. At the time neither intel or AMD had a ready for prime time cpu and MS needed to keep a working 64 bit codebase.
Only the State obtains its revenue by coercion. - Murray Rothbard
Dave_bsr's Law: Governing "when computers will be fast enough":
.05 seconds (button click speed now now), no, I mean _instantaneous_, like when I push on my door and I see movement. When I write on paper and _instantly_ there is writing. Then, computers will be fast enough. And I don't just mean speed for mozilla, i mean processing real-time 3d bump-mapped, whooseyourdaddy environments. Yeah.
Computers will be fast enough, when, for every conceivable operation, system delay between user requests and proper system response is less than the human ability to resolve, eg, instantaneous.
Not instantaneous, as in
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
If you find you need that sort of mega addressing the chances are the app you need already runs on 64 bit Solaris. After that point it's up to the vendor (Think Avanti Corp /Apollo) Wheither it's worth their while.
Remember, You need their application. Unless your app is home
grown or you have some signifigant pull with a vendor the port isn't
going to happen.
The desktop is an afterthought. This chip was designed to be sold in quanties of 8 and higher in single large servers. Once they cut into that market the economies of scale just happen to make it cheap enough for the desktop market to pick it up. They have a much better chance at getting it down with their builtin backwards compatibility and keeping costs down. Alpha never hit that "sweet spot" for the volume to really bring down the price..
Now, Don't think Intel is going to sit on its hands while AMD eats their lunch. They're more likely to drop an Itanium instruction decoder into an Alpha EV7 core and push that than follow with an x86-64 processor line. Itanium is just to big and costs too much to at this stage of development to make inroads fast enough stop AMD in gaining marketshare but more importantly, mindshare. Intel would never take up x86-64, Doing so admits defeat to the industry i.e. You're not the leader anymore.
So to sum it up, Intel will either:
2 and 3 are much more likely than one, You know which one I'd rather see happen :).
Either way it'll be a boon for the OS community and certainly make our (The Alpha community) lives easier. The way I see it, even if hammer is moderatly successfull. You guys will 'clean' most of the popular soucecode out there to be 64 bit clean, reducing our matainence work by like 80%. The only thing we'll have to worry about is firmware, toolchain, libc, Xwindows, and kernel. So please buy a *hammer and learn the joys of porting to 64 bits. If it proves too painfull, please see the ld manpage for the "-taso" flag :).
Peter
www.alphalinux.org
Spare me the smoke and vapor. Don't you remember the sad story of Mica, errr, NT on Alpha? Loudly proclaimed, quietly killed, that's why I think they are not there. If you consider the number of bugs and holes in 32bit M$ work, you might conclude they never arived anywhere.
In the mean time, you can get Linux and BSD on Alpha and other 64 bit platoforms:
Oh, it hurts so much to remember and think!
Friends don't help friends install M$ junk.
- The problems to be hurdled are:
True. But this is really a bad code practice sort of thing that developers that the C/C++ standard doesn't endorse anyhow. Java developers need not be concerned.1) Reliance on the fact that size of pointer is equal to size of int.
- 2) Reliance on a particular byte order in the machine word.
Its little endian, like it has always been on Intel. What's the problem? Little endian has the natural LSB/W/D property that makes increasing the natural word size typically a non-issue (unlike big endian where it is a serious PITA.)- 3) Using type long and presuming that it always has the same size as int.
It is the same. You need to use "long long", or "_int64" or something like that to move to 64 bits in your C/C++ compiler. AMD's new "long mode" actually defaults to 32 bit data sizes, and only uses 64 bits when specifically overridden to do so. That's the whole point of the x86 architecture -- it supports a variety of data sizes as a consequence of its long history of backward compatibility, not just one (like a typical RISC.)- 4) Alignment of stack variables.
Same as it has always been. (64 bit integers already exist today in known common ABIs/compilers, in case you were unaware.)5) Different alignment rules in structures and classes.
- 6) Pointer arithmetic.
Eh? You can add/subtract integers to pointers, and subtract two pointers from each other. How does moving to 64 bits change anything?I think the sort of latency you see from current "realtime" audio systems is about right to meet my demands, <2ms! When we can have our computer provide a simulated environment at the compexity of modern physics in which we can shoot at our friends driving F1 cars while impregentating our girlfriend, all modeled indistinguisably from real life (could we ever model the creation of a human life meaningfully). That should keep us going for a few years but it will give scientists an incredible toy! /. will be covered with questions over whether 512bit really is enough, with processor speeds of 3 Peta9Hz (thats 3 + 9 * 000,000,000,000,000). Who would want a beowolf cluster of those? Whose going to supply the power! :-(
With up to 10^81 (2^273) atoms in the universe and then what level of subatomic detail? 512bit seems about right to me. Pity Moore's Law suggests we might have to wait til around 2674 til
Unfortuantely anyone who reads this today will be lucky to see a nice 128bit computer in 96 years time at 1.5MegaPetaHz
Never underestimate the dark side of the Source
Let's say I have a 16,000 by 16,000 image frame. I have 60 of them per second, and have 2 hours of film. That works out to 100.5 terabytes of data. 2^64 happens to let me store and address about 166,937 of these superduperHD movies.
Now, I don't know about you, but I only own a couple-hundred movies, and I only own a couple-hundred games. Even if they were the mega, mega high res I mention above, I'd still not use up more than a miniscule fraction of what I had available. That's why I think it'll last at least a century.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
> For #2, realize that some integer operations are
> O(N) where N is the number of bits involved.
> 64-bit multiplication and division are slower
> than the same 32-bit operations. Period.
Not true. They are done in circiuts so you can use parallel algorithms. Mostly arithmetic ops are n log n so they dont take a significant amount of time longer. You do need more transistors though...