Slashdot Mirror
AMD Predicts End of 32-bit Processors
DDumitru writes "Infoworld
reports that AMD predicts it will stop producing 32-bit processors by the end
of 2005. By depending on price cuts for Athlon-64 and Opteron, AMD is predicting that
it's sales of 32-bit CPUs will fall off and obsolete 32-bit systems in less
than 3 years. This is either a push forward, or a tactic to try to capture the 64/32 bit
standard leaving Intel in the rear. Or it could just be hype." I'm not in a hurry to ditch any of my 32-bit machines, so long as I get them replaced by 2038.
I'm not in a hurry to ditch any of my 32-bit machines, so long as I get them replaced by 2038.
I hope the editors realize that 32bit processors CAN process 64 bit numbers. In Java, for example, the date is handled by a 64bit number that tells the number of milliseconds since Jan 1, 1970. Amazingly enough, that clock won't run out for another few billion years.
Oh, and most Unixes have fixed the time problem. The real issue is getting the programs to switch over to the new APIs.
Javascript + Nintendo DSi = DSiCade
I wonder what applications will drive the adoption of 64-bit computers? Besides playing the latest games, most real-world applications seem to run fine on older 32-bit processors, even sub-GHz processors. AMD's prediction is self serving.
That said, I have my eye on a new dual G5, so I guess I've bought into the hype that size (word size) matters.
Two wrongs don't make a right, but three lefts do.
Once I predicted the end of 16 bit chips. Then I found one in my PDA...and my cell phone....and my clock radio....and my DVD player.....and......
I don't think that they are predicting that all 32-bit processors will be phased out by then, but will probably not be manufactured anymore. It's the next logical step in the progression of microprocessors. 32-bit will phase out just like the 16-bit, whether it will be in 2 years or no we will have to see, but my comp is good for at least 5 more years as is.
My sig beat up your sig.
Draw the line. In little more than 25 years we've gone from the 4004 (4-bits) through 8-bits (8008 and successors) to 16-bits, 32-bits, and now 64-bit microprocessors. Why stop now. We already have 128-bit and 256-bit wide data and memory busses. How long until a true 128-bit microprocessor?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
AMD has said that next year they will be shipping Opteron chips that only dissipate 30 Watts. An opteron runs 32-bit code faster than an Athlon, and totally owns if you run it in 64-bit mode. If you could buy a chip like that, for the same price as an Athlon, why would you want an Athlon?
(If there was a problem getting a good motherboard for the Opteron, that would be a good reason to still want Athlons, but there isn't a problem. There are plenty of good motherboards for Opteron and Athlon64 already.)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
That pretty much is true, along with the fact that GNU/Linux has been running on other 64-bit platforms for many years now.
./configure.
The biggest problem I'm having building a custom install for my AMD64 machines is the fact they have 32-bit compatiblity. On the Alpha is was easy, the lib directories contained 64-bit libaries, because the machines were 64-bit, period. But with the AMD64 the lib dirs are still supposed to contain the 32-bit libs, with the 64-bit versions installed in a lib64 variant. This causes problems because almost no libary packages are setup to compile twice once in 32-bit and then over again in 64-bit mode with a simple
I have Visicalc for my spreadsheet needs and the CPM card allows me to use the wonderful WordStar, the king of the word processors.
What is sad is that I'm only 30 and I can tell you that Ctrl-B reformated a paragraph in WordStar. I usually used wsn, however, to edit my C programs, which I then compiled with my lattice C compiler. Those were the days when men were real men and clocks ran at 4.7MHz.
Why is that? Generally smaller geometries result in lower yields. It's worse when the process is first rolled out, and yield does improve as a process matures (which 90nm has by no means done yet), but in general, a larger geometry process results in higher yields.
If you care, this is because defect densities in the silicon remain relatively constant, and although die sizes may be reduced somewhat with smaller geometries (not as much as you would think, though, due to wiring density not scaling linearly with gate size), the odds of a defect being fatal (i.e., falling into one of the increasingly dense "wrong spots" on the silicon) increase exponentially with gate size decrease.
everything in moderation
How can you say that with a strait face? Doesn't that sound just a little bit like "no one will ever need more than 64k of ram"? ALL technology has built-in obsolescence. It probably won't be in three years like AMD wants us to believe, but 32 bit systems will eventually be obsolete, just like the horse drawn buggy you will only be able to find them in museums and in the basements of fanatic collectors. I feel like writing a cron job that will remind me to look you up in 2023 and remind you of that statement you made.
SCO.com uses Linux
The real question is how long will it be before the BIOS is 64 bit protected mode?
Probably never.
I still write in 16 bit assembly because the BIOS still runs in 16 bit mode. It would be nice if AMD broke backward compatibility for once and started off with 64 bit firmware so I could at least write 64 bit assembly. The mixed-mode stuff (16 and 32 bit) that I would have to do for OS programming is getting ridiculous:
- I could write in 32 bit mode, if I wanted to write drivers for every single conceivable piece of hardware out there. While this would be ideal, it is far from possible. And since the processor starts in 16 bit mode, I'd still have to write at least a little real mode assembly.
- I could still use 32 bit mode if I wanted to use a call gate to call the 16 bit code of the BIOS, or:
- I can write 16 bit code, call the BIOS directly, and only have to worry about the 64k and 1M memory limitations.
I don't like any of these solutions, but it's a lot easier to fit kernel modules in 64k than it is to write call gates for BIOS services. The reason why I like using the BIOS is because it is standard across differing computers - I don't have to write a different driver for every single video card and hard disk controller that I might come across. Plus, if it uses the BIOS, I can be reasonably certain that it will run on an arbitrary PC; I don't have to do any hardware probing or detection.Well, it's a pipe dream, I guess.
Those of us who like to program their own hardware took a serious hit when the 32 bit OS became the standard. We either ended up jumping through hoops to use the 16 bit BIOS from protected mode, or we just decided not to use more than 1 megabyte of the machine's memory. If they had installed 32 bit BIOS's when the 32 bit processors came out, we would never have had these problems.
But no, we still have a 16 bit BIOS because the manufacturers are afraid that some fool might want to run DOS on their 3GHz Pentium 4 with 1 GB of RAM....
The society for a thought-free internet welcomes you.
I am not sure what you mean :
1) Gcc 3.3 actually compiles to AMD64 (i.e. Athlon 64 and Opteron)
2) Gcc 3.3 generates pretty fast code too, as you can see on spec.org where IBM submitted results obtained with an Opteron, Suse Linux and GCC 3.3 : the baseline is above 1100 whereas Apple said that a Pentium 4 at 3.06GHz only achieves 880 with GCC 3.3. So it seems that the Opteron is a better processor for people who use GCC.
3) I write this text on my Athlon 64 running Mandrake 9.2 RC1 for AMD64. I can tell you that there is litlle left to adapt because it works pretty well. In fact you could hardly tell the system is the AMD64 version...
4) running 32 bit programs works fine : I have to use Java 1.4.2 for Linux x86 since the AMD64 version is not available. To do that, you just run the 32bit Linux program and it works at native speed.
As a conclusion, the Athlon 64 is good but it is still expensive (I paid 450 euros for my processor).
If you're going through all this trouble to down clock a processor, wouldn't it make more sense to just use something that runs at a lower clock? Its like putting a Farrari engine in a car that is only ever intended to move at 35 MPH - sure you could do it, but wouldn't it make sense to just get an engine more suited to the task.
This is not strictly true. I believe Linux on Alpha is purely 64-bit, but other operating systems (such as OpenVMS) allow programs to be compiled to use either 32-bit or 64-bit virtual memory spaces. Link
Unless AMD or someone else has a massive gain with respect to being able to cool these monster CPUs...
For quite a long time, now, Sun, for example, has been cooling it's CPUs using the full-size case fans and ducts to guide the air over their generous but modest heatsinks. Even the Blade 2000 with dual UltraSPARC IIIs just has a case fan and a duct. Take a look at the PowerMac G5; it's the same thing.
On the lower-end, Sun's UltraSPARC IIi and IIIi CPUs are given little heat sinks and teeny fans.
It seems to be only the PeeCee crowd that wants to attach a half-pound chunk of aluminum to their CPUs with dual fans, etc. I wonder if it's related to phallic underachievement, you know, the computer geek equivilent of those super-long slender dragsters with the 3000HP at the base or perhaps like a 300-foot-tall five-million-pound-thrust rocket whose only job is to lift three 200lb men and cargo into orbit...
Healthcare article at Kuro5hin
This may have been true but the average user just wants it to look good on paper
Ok, so go ask Average User how fast the CPU in the HP Pavilion 3000+ is. Odds are they'll say 3.0 GHz, which isn't true but is proof of AMD's success in "looking good on paper".
The issue that AMD has long had is poor motherboards. Via had a long, long time with poor chipsets/drivers which lead to crashes (this pretty much ended with the KT133A, but it's popped up every now and then since). They also had issues with MS not including the drivers for the chipsets with the OS (which is a death knell, especially for something like a motherboard -- the boards worked without the drivers, but they were dog slow). They also had some thermal problems, which were wonderfully overhyped by the hypemasters at Tom's Hardware (no, I won't provide a link -- if you don't know it you're better off).
Nowadays those issues are in the past. Nvidia has been producing rock solid motherboards for over a year now. Via has finally worked out its issues as well. Via even has chipset support in XP (and Win2k/ME IIRC). Anyone who spouts heat issues is an idiot -- Intel chips now have higher power consumption and heat dissipation than AMD does at the same effective processor speed.
AMD's had issues breaking into corporate PCs though, and still does. Most PCs sold for corporate use are Intel only. They've also had problems breaking into the notebook arena, and they're making a slow go of it in both areas. AMD has long had the enthusiast market, particularly the value-oriented gamers, but it's by no means a lock, and it's really not a very large market.
The low-power CPUs are usually low-power in both senses of the word; they may use less power, but they also do less per clock cycle. Your non-low-power CPUs like the Athlon XP or P4 simply do more per clock cycle than, say, VIA EPIA, which isn't even superscalar.
The Athlon XP does more per cycle than the P4; the P4 does more per cycle than the C3. Think of the C3 as a 1.5 liter toyota motor, the Athlon XP as a V8, and the P4 as a turbo straight six, if you must apply automotive metaphors. The C3 is small and efficient, but it simply cannot do much. The Athlon is big and maybe inefficient, but it can do a lot. The P4 is also big and maybe inefficient, but it can do a lot too - However it gets its power from RPMs and not from displacement.
If you are going to be running a lot of processes at once, it makes the most sense to have a P4 or Athlon XP, not a C3 or an EDEN; Especially with P4's hyperthreading, if you are in a position to use it. Regardless the significantly superscalar nature of a non-budget CPU is often well worth it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I agree. What we really need is a processor that scales well for a cheap price. How about a 64 bit MP capable processor design that stacks like legos? Water cooled multiprocessor lego goodness.