64-bit Linux On The Opteron 325
JigSaw writes "A few moths ago Robert Minvielle put to test AMD's Opteron regarding its 64-bit Linux compatibility. The results back then were not very positive but he is now back testing more 64-bit updated distros: Gentoo, SuSE, Mandrake, Red Hat and Fedora. And this time the results are more positive with Linux offering good Opteron support where Windows-64 doesn't seem to. FreeBSD also lists the AMD64 platform as a tier-1 architecture."
Market Share (Score:5, Interesting)
Re:Market Share (Score:5, Insightful)
Re:Market Share (Score:5, Insightful)
(DRM, TCPA, etc. omitted)
Re:Market Share (Score:5, Funny)
Re:Market Share (Score:2)
Re:Market Share (Score:5, Informative)
I can see this for customers such as Hollywood. This isn't necesssarily true in the consumer world, however. Too many variables to make that a reliably true or false statement.
Frankly, I find this statement a bit overrated. Nothing personal, but a little bit of clarification would have sounded less like 'pat-linux-on-the-back-karma-whoring' and more like something informational.
Re:Market Share (Score:3, Interesting)
Linux will gain user base because it's cheaper, and because some forward-thinking organizations are finally starting to see the benefits of not being chained to Microsoft.
Technology has nothing to do with it. Case in point: Intel shipped the 80386 in 1985, and it was ten years before Microsoft finally shipped a consumer-grade 32-bit operating system.
Well... (Score:5, Funny)
Re:Well... (Score:5, Funny)
Just the processor-fan alone in an AMD system can blow just about aything away - I use my old Athlon system as a leaf blower now and then.
Re:Well... (Score:5, Interesting)
This will always be a good joke, but people should be aware now that AMD's processors run cooler than Intel's. The thermal diode in the 64-bit chips also supposedly works well. So you should be saving heat and power with AMD over Intel now believe it or not!
Re:Well... (Score:4, Informative)
whats the deal (Score:3, Interesting)
big woop. so what else is new?
Re:whats the deal (Score:4, Interesting)
It'd be nice if some more practical benchmarks were posted, though, like I/O, database performance/stability, positive effects of the new memory access, etc, instead of, or at least in addition to telling us how well KDE works.
Re:whats the deal (Score:5, Informative)
Re:whats the deal (Score:2)
btw. what's the article on about 'new' NVidia drivers? They're dated September 23rd!
Re:whats the deal (Score:4, Insightful)
Awesome (Score:5, Interesting)
Re:Awesome (Score:2, Insightful)
Re:Awesome (Score:5, Funny)
Re:Awesome (Score:5, Funny)
Windows 64 (Score:3, Interesting)
Re:Windows 64 (Score:2)
Re:Windows 64 (Score:2)
Re:Windows 64 (Score:4, Informative)
Usually via bank switching (e.g. PAE) which is slow and cumbersome.
Re:Windows 64 (Score:3, Informative)
So, the "big deal" about 64-bit is that (a) there will be *direct* access to the memory beyond 4GB, as the previous message mentioned; and that (b) individual processes will be able to access > 4GB.
(a) provides a performance boost, by removing the need for "mapping" between 32-bit and 64-bit
Re:Windows 64 (Score:5, Interesting)
Re:Windows 64 (Score:3, Informative)
You really mean to say is that each process may need access to more than that much memory, and if an application is written with PAE in mind, I believe even an application can have more.
64-bit machines are a good thing because it allows hardware people a new opportunity to slip in some good stuff (better IO comes to mind) while they are at it.
Having used an AMD64
Re:Windows 64 (Score:5, Funny)
Actually, the delay in Windows64 was trying to come up with a new prefix for all the hungarian-notaion in their code.
I think they settled on the following for a 64 bit pinter to a string: pllpsexsfeString
Re:Windows 64 (Score:2)
'jfb
Re: Hungarian Notation (Score:2, Informative)
S mi a baj magyarral? Szerintem egy nagyon szep nyelv, de lehet hogy egy kicsit eloiteletes vagyok ebben az esetben...
(What's wrong with Hungarian? I think it's a very beautiful language, but I may be a little prejudiced in this case...)
MT
BTW, there should be accented and tilded characters in the above sentence, but I don't know how to submit them using the Slashcode engine.
Re: Hungarian Notation (Score:3, Interesting)
The language is fine. The notation as used in programing (like MS does) is a pain. I have to use it, meaning I'm always making up prefexes for each class and structure I have. I have yet to see any benifit to it. I try to be kind and remember I've only worked on this code for a couple months, but I still hate it.
Re: Hungarian Notation (Score:4, Interesting)
s - struct
a - array
str - string (stl)
sz - string (c)
csz - CString
etc. Making up new prefixes for everything is just about as useful as not using them at all.
Re:you're missing a lot (Score:3, Insightful)
Which is the situation I hate the most. I have to support several different OSes in one code stream, and if the OS can do it I have to support big files. That means positionInFile is a 32 bit number on some systems, and 64 bit on others, choosen by a #if.
Of course when I use a variable I don't trust that notation because often enough it is defined wrong. That is I have DWORD ulFoo or some such. Better than what I just discovered: I have a ulHandle used all over, that turns out to be a pointer to a st
Re:Windows 64 (Score:5, Informative)
Re:Windows 64 (Score:2)
(Everything includes drivers, libraries, through to applets, databases, and Office itself.)
Re:Windows 64 (Score:3, Interesting)
And frankly with how well Opteron handles 32-bit apps there's no reason to ship 64-bit versions of everything, a 32-bit userland with a 64-bit kernel and the option to run 64-bit userland apps as necessary is more than enough and infact that's how a number of Linux builds work, sparc64 comes to mind quickly since I have two of them.
The big problem is shared l
Re:Windows 64 (Score:5, Insightful)
I suppose I should spend some time demonstrating why this is stupid to avoid being flamebait. So first, Intel isn't working on a competitive processor, not in the sense you mean it. If they are working on one, it would almost certainly be a year or longer before they could roll it out, and there's no way MS would agree to wait that long. Second, there is no possible reason for MS to withhold Windows just because Intel asked them to. MS is allowing free operating systems to have a monopoly on AMD64 right now. Do you really think they'd do that voluntarily? Third, it seems clear that Intel is betting on there being no market for desktop 64-bit machines. I don't want to get into that particular flamewar, so let's just say that, right or not, that's what Intel believes, so it makes sense for their business decisions to reflect that belief.
Re:Windows 64 (Score:3, Interesting)
My adrenaline fix isn't what it used to be. Double the dose.
AMD me.
Introducting the AMD Athlon (TM) 64 FX processor. Take your system to extremes. Double the data path from 32- to 64-bit and you more than double the thrill factor. Uninterrupted, ear-splitting, streaming audio and rich, razor sharp video make your pad a launching pad. What's more, you get all the power you need to edit, mix, and model your own digital creation
moths (Score:5, Funny)
Even 64-bit Linux doesn't prevent spelling mistakes on Slashdot.
Re:moths (Score:4, Funny)
Even 64-bit Linux doesn't prevent spelling mistakes on Slashdot.
No no, he's implying that it's buggy.
FYI No benchmarks (Score:3, Informative)
www.aceshardware.com for some benchmarks (Score:5, Informative)
They have 32 and 64 bit apache benchmarks along with some others compared against single and dual xeons.
Re:FYI No benchmarks (Score:5, Informative)
Tom's Hardware, Anandtech and aceshardware have all benchmarked the opteron on linux. Tom's hardware's benchmarking isn't that great, aces hardware does the best job.. The Opteron kicked butt in all reviews.
This is by far the best review so far IMO:
http://aceshardware.com/read.jsp?id=60000275 [aceshardware.com]
We're going to order a bunch of them by the end of this year so the government doesn't hit us with too many taxes, woo hoo!
Re:FYI No benchmarks (Score:5, Funny)
Really? That's a neat trick
Re:FYI No benchmarks (Score:3, Informative)
Re:FYI No benchmarks (Score:2)
Re:FYI No benchmarks (Score:2)
The extra address space is nice. However most apps aren't programed to take advantage of 64 bits, and many couldn't benifit from it. Don't expect any improvent in times to do 2+2, because on either both numbers fit into your native data size. Expect massive improvements when adding 6 billion to 6 billion though.
Opteron and *BSD (Score:5, Informative)
On the other hand, NetBSD has had amd64 support since 2001 [netbsd.org].
OpenBSD is reportedly working on it [openbsd.org], but I haven't seen anything hit the tree as yet.
Re:Opteron and *BSD (Score:3, Informative)
IA64 is a new one which tries to explicity code parallel instructions. It is titled EPIC, as opposed to RISC, VLIW or CISC. It is one of only a few CPU instruction sets which were designed as 64-bit (alpha) and not had it tacked on (sparc mips)
x86-64 always has refered to amd's 64-bit extentions to x8
Opteron support could perform better (Score:5, Informative)
I suppose I dont even know the purpose of this post, just some observations
PathScale (Score:5, Informative)
Seti problems with x86-64 kernel (Score:5, Interesting)
As much as I'd love to support Linux by purchasing a distro, SuSE wants $130 for their AMD64 distribution, which I just can't afford right now. And I'm too much of a noob to build my own from scratch using pure source, so I'll hafta wait.
But anyways, it's exciting to see more AMD64 distros, even if conspiracy theory says that Microsoft keeps delaying because of Intel pressure. I'm very happy with my dual opteron server, and will be even more-so when I can run pure 64-bit Linux.
Re:Seti problems with x86-64 kernel (Score:3, Informative)
You have 2 options
1) use a source based distro (gentoo, sourcerer would be best)
2) make your own distro
I GUARENTEE that if you follow the directions on the gentoo install page, that you won't have one problem. Any of the serious obsticles I've had with gentoo are user errors (I get bored during an emerge, start reading ahead, and skip a step).
I never have been able to get sorcerer to inst
Re:Seti problems with x86-64 kernel (Score:3, Insightful)
Re:Seti problems with x86-64 kernel (Score:2)
hurdles (Score:5, Insightful)
In a way, this has always been the way it worked, but now that there is a large jump in computing (32 to 64 bit processing is a pretty big jump, neh?) and the scale of development is made larger, the Open Source projects will show just how slow and inefficient proprietary software developing methods are.
Re:hurdles (Score:3, Insightful)
Microsoft has developed all of their code to be cross-platform for years (NT used to run on several processors, but when the same software was available on multiple platforms it strangely led people to Intel), and upwardly bit-scalable, and has been demoing 64-bit editions of Windows for years. Having the technical ability to toss a basic operating system out the door, and wanting to
Re:hurdles (Score:3, Informative)
I think you may have fallen for a little propaganda yourself ...
Not true I'm afraid. Windows NT 3.5 and 4.0 (and maybe 3.1 too?) were available for Alpha, MIPS and PowerPC. But other than these versions of the OS, and some associated server software (such as IIS and SQL server) everything was Intel only. In particular, the Microsoft Office software was only ever supported under emulation for Alpha.
Not r
Re:hurdles (Score:4, Insightful)
But If you're talking about 32-64 bit, then Apple has made the transition quite smoothly with the G5 if you ask me. While the OS itself is not true 64 bit, it supports 64 bit applications perfectly.
The conclusion... (Score:3, Informative)
Conclusion:
The coming months (weeks?) should be interesting in that Mandrake is set to release the AMD64 version any time now, as they are taking pre orders for it in the Mandrake store. Recall, it was one of the best (if not the best) in my first review, and I blame the drive problems on the Asus BIOS update. Gentoo is nearing (from what I read) a really stable working system, and I have read repeatedly that others have it working fully (as a workstation with X windows) on other motherboards, so I again blame the Asus for my troubles with Gentoo. Red Hat is another story, having dropped the desktop edition, the "workstation" edition is well beyond my financial reach. A corporation may consider purchasing a copy for evaluation, but I would be tempted to wait on Mandrake or Suse.
FYI: costs as of 12-16-2003 for AMD64 Linux distributions:
Mandrake pre order $100
Mandrake corporate server $750 (standard support) $1500 (unlimited support)
Red Hat AMD64 workstation $792
Red Hat Advanced Server $1992
Suse Professional 9.0 $120 (distribution on DVDs, no CDs)
Suse Enterprise Server $767 (2 cpu) $1450 (4 cpu)
Looking at the above cost matrix and my experience, it is almost tempting to purchase SuSe just to have the DVDs (no CDs, strange). The enterprise/server editions seem to all be priced about the same, with no definitive mention of CPU capability from RedHat or Mandrake on the server editions. (I assume at least 2 CPU capability built into the kernel)
Side note: the Mandrake pre-order in question is Mandrake 9.2 (pre-order is at http://www.mandrakestore.com [mandrakestore.com])
Speed vs Memory (Score:5, Interesting)
We have a couple of Opterons with 8GBM RAM each running as MySQL/INNODB backend database servers. With that much RAM databases that would crawl on IA32 are very fast since so much more of it can be cached in RAM.
The only real problem is memory technology hasn't kept up. 1GB DIMMs can be had at almost reasonable prices but 2GB density ones are out of range of most everyone. 4GB are on the distant horizon.
I'd have gladly stuffed 16 or 32GB of RAM in the boxes we have if it had been affordable. More for less!
Re:Speed vs Memory (Score:5, Interesting)
Crucial is listing their CT51272Y265 DIMM's for a measly $6999 - these are 4GB PC2100 registered with ECC. The price (ahem) may be a bit high, but if you really need the memory...
Hal Computers had an interesting "benchmark" back in the late 90's. Their Sparc box was capable of handling 3 GB (at close to 80 grand per GB), one chip simulation took 40 hours with 2 GB and 1.5 hours with 3 GB.
Re:Speed vs Memory (Score:3, Interesting)
Re:4GB of addressable RAM ...is simply not enough (Score:3, Funny)
Is there a word for a mega-terrabyte?
Re:4GB of addressable RAM ...is simply not enough (Score:4, Informative)
Compatibility-performance fallacy (Score:3, Informative)
I'm sick of people making the mistake that a '64-bit' processor will automatically perform poorly at apps compiled for 32-bits. In the case of the Opteron, a 64-bit app will probably run better due to more general purpose registers (32 vs. 8), but by his tone, the author of the article seems to think that 32-bit app performance will be unimpressive (like Itanium).
This just ain't the case with Opteron or Athlon64.
Fallacy fallacy (Score:2)
Debian port infomation. (Score:4, Informative)
What about 4GB? (Score:5, Interesting)
My company [zappos.com] upgraded to SuSE on Opteron a few months back, and had some random memory corruption with our 8GB setup. Turned out it was some bad interaction between the Tyan motherboard, the BIOS, and the stepping 1 of the Opteron. What a pain.
We're stable now with 4GB, but the memory was the only reason we upgraded in the first place. I'd like to see more tests with lots of memory.
Cheers
Re:What about 4GB? (Score:2)
Most 32/64 bit hybrid architectures lose speed when going from 32 to 64 bit software due to losing bandwidth to storing pointers.
AMD64 actually has an advantage to offset that in the fact it doubles the number of registers in 64 bit mode, so even code that doesn't break the 4GB barrier has a chance of running better.
Re:What about 4GB? (Score:4, Interesting)
Re:What about 4GB? (Score:4, Informative)
A 64-bit integer takes two 32-bit registers, that's all. Two back-to-back add instructions instead of one. Might make a difference if you have an unholy hell of a lot of 64-bit integers to add and that's about all you're doing, but if you're talking about doing a few large integers on a spreadsheet, you'll never notice the difference.
A "thunk" is a mechanism for making a procedure call in the face of some annoying obstacle that prevents the normal processor call instruction from "just working". Typical examples would be a stub procedure that maps in one of several possible overlays before jumping to the actual code, or the little dance you get to do in Windows to call 32-bit DLLs from 16-bit apps, or vice versa. The word has nothing to do with the size of a single integer.
heh? (Score:5, Interesting)
Can someone tell me why using a stable kernel over a development kernel is a 'questionable' decision?
I stopped reading the article there, that is just stupid.
Re:heh? (Score:2)
Debian is months away from a stable distro (waiting on dpkg and apt upgrades to support multi-arch installs) and I'm damned if I'm going back to RPM... it's 64bit hell out there
Re:heh? (Score:4, Interesting)
Furthermore; Before a kernel is "stable" it's going to have to be stable on most arches that it's to run on; support all the hardware correctly etc etc etc. For a distro specifically targetted at one arch, it can be much simpler to target a good stability because the problematic hardware interactions are far simpler.
Finally, it seems entirely normal, and indeed the opposite rather "questionable", for a _beta_ distribution to include that software that they intend to ship with. 2.6 Is definitly nearly at that point; as such it's the obvious choice to use. By the time AMD64 under linux is ready for prime time, i bet that 2.6 will be too.
--Eamon
Anyone know about the maturity of NUMA support? (Score:3, Interesting)
.NET (Score:5, Interesting)
Re:.NET (Score:3, Informative)
Radeon drivers (Score:3, Informative)
64 bit is more about memory (Score:4, Interesting)
What's needed is a Killer App (Score:5, Insightful)
What's needed is a killer game that runs on Linux-64. The must-have toy will drive Linux faster and further than any business app could. It's the reason I know most people overspend on a PC, so they can play the latest and greatest games.
Intel's known this for years. That's why they give early release processors to the top game manufacturers so that when the new processor hits the street, there's software that'll shine with it.
Re:What's needed is a Killer App (Score:5, Insightful)
RDBMS systems are your killer app. Opterons are well-suited to RDBMS work, to the point of nearly seeming intended for it. Between the "big iron" memory architecture and the 64-bit address space, AMD has finally provided commodity hardware that can truly tackle real, heavy database environments.
The only reason I didn't buy an Opteron for our main RDBMS server this year was because they weren't ready for our peak season. This coming year, I'll be getting a minimum of a dual-opteron, more likely a quad - and getting it for a fraction of what similar performance would cost from Sun.
steve
Business Apps (Score:4, Insightful)
What linux needs more of is actual business systems (Point of sale, finance tracking etc - for small to medium sized businesses). If you could run your point of sales system on linux the savings of several hundred dollars per system would be a major advantage. I mean it was the spreedsheet that really brought pushed PCs mainstream (you start using one at work, then you think you should probably have one at home... story goes on).
It's just an opinion - but I think we have more than enough text editors and windowing environments.
- traskjd
Should of benchmarked kernel 2.6 (Score:3, Informative)
Of course alot of it has to do with the gnu C compiler being optimized but the newer kernel will better take advantage of the newer chipset and other features.
FreeBSD/amd64 (Score:5, Interesting)
FreeBSD/amd64 is a pure 64 bit OS. There is no 32 bit code at all. The kernel, userland, ports/packages etc are all 64 bit. None of this hybrid 64/32 stuff. :-)
Actually, this is probably our greatest liability. While we can run 32 bit binary applications (can you say perforce?), it isn't perfect. Much more work is still going to be done in this regard.
If anybody is interested in giving FreeBSD/amd64 a whirl on one of these machines, we'd appreciate folks trying out the 5.2-RC1 ISO images. See the ftp link on the story above. Since RC1, lots of bugs have been found and fixed. Most notably for support of KDE and gnome environments. If you do try it out, do be aware that its still a little green in this area.
I personally, have been running a FreeBSD/amd64 desktop for about 2 months. I do subscribe to the 'eat my own dogfood' mantra. I do not have any x86 unix machines left except for my 486 firewall and a laptop. That goes for both home and work. My work desktop is FreeBSD/amd64 too.
Anyway, it's nice to see a FreeBSD reference here for a change.
If X doesn't work on Gentoo/Opteron... (Score:3, Informative)
It's true that many things doesn't work in 64-bit mode (loke OpenOffice, Abiword etc), but system WORKS ! By "system" I mean X, cups, samba, KDE, Gnome etc. It works so well that I have bought two dualCPU machines (update of two aged workstation machines-P4 2 GHz and Tualatin 1.4 Ghz @ 1.7 GHz) and I'm waiting for a third to arrive- that one will replace fileserver/printeserver/firewall/etc machine.... Gentoo on Opteron works, and unpolished details are getting its shine rapidly. I use: Motherboard TYAN Thunder K8W S2885 2x Opteron 240 2 Gb of PC2700 ECC Reg (512 Mb modules) GeForce 4 Ti4200 HDD EIDE 120 Gb WDC
Re:If X doesn't work on Gentoo/Opteron... (Score:5, Interesting)
- I need performance increase due to 1 Mb L2 and much bigger register count than in x86
- I need better scalability than with Athlon MP.
Current Athlon MP offerings are pale compared to Opteron.
With Athlon MP, there is some performance penalty to be paid when going SMP, due to different factors.
One is pure frequency of available CPUs, other is sharing of the bus bandwidth between two CPUs, yet another is relatively old chipsets for SMP Athlon MP systems, compared to uni CPU Athlon boards...
Besides that, poor old Athlon can't even begin to compete with Opteron regarding bus bandwith. Even more, Opteron needs memory bus only for memory comunication. Everything else goes through HT ports, while old AThlon has to scram it all through one bus.
So, even though I only use 2 Gb per system at the moment, 64 bit architecture shows real speed advantage. After prices of RAM fall a bit, I'l probably go to 4 or 8 Gb and/or faster Opteron, but neither is criticall at the moment.
I can certainly wait a year or two with that...
64 bit ...not nescessarily for performance (Score:5, Insightful)
64 bit is all about memory addresability. You can directly address more memory on a 64 bit machine then you can a 32 bit machine. Period. When you would like to get the best performance you can out of your RDBMS, most shops like to load as much of the DB as they can into memory. DB's are getting larger then 4 GB now!
BillG said 640 KB out to be enough for anyone..ha ha Bill. Very funny.
Re:64 bit ...not nescessarily for performance (Score:4, Insightful)
Every year, as our business has grown, I've had to upgrade our DBMS server to keep up. We've gone from a 4xP3 Xeon to a 2x AthlonMP to a 2xP4 Xeon, and next year it will be a 2x or 4x Opteron.
In every case, when the machine is finally hit it's max capacity, the CPU's were nearly *never* at full use. Even though the entire operation was running from memory and cache(the disk lights rarely blinked), the memory bandwidth has always been the limitation. Between the Opterons having VERY fast memory controllers (and each chip having it's own controller), and the ability to address vast amounts of memory, it's a recipe for letting those CPU's fulfill just a bit more of their true potential! : )
steve
Windows applications (Score:4, Insightful)
I mean, I understand that Linux applications will most likely have 64-bit support a lot sooner, but 40% of windows application support in the first year sure looks like enough of a reason to purchase the machines now.
I guess I don't see a huge argument in justifying that only %40 of windows applications are going to have 64-bit support when there's virtually no drawback to buying a 64-bit processor from AMD vs. an equally priced 32-bit processor from Intel.
Sure, you can argue that it's a "waste", but even if only three of the big players have 64-bit applications (Microsoft, Macromedia, Adobe) within the first year, that's still 90% of the applications that are used on Windows machines in a corporate or even personal environment for the average user.
The driving force is going to be the gaming community, and AFAIK, the major game software companies plan on having 64-bit games available too, so I fail to see what the real issue regarding support is.
If %40,%30,%20,%10 is a fair assessment of compatibility over the next five years, that means that in three years %90 of the Windows applications can be assumed to have 64-bit support, which is perfectly fine for the corporate or average 3-year life cycle of a computer.
Or am I missing something?
C types (Score:4, Interesting)
Re:when dual-64 will hit the shelves? (Score:4, Informative)
Don't be afraid to shop around online... both ZZF and newegg (I buy parts from them all the time) are great retailers if you live in the US (I know, US centric but you don't specify where you live
I'm sure your local computer parts store wouldn't mind ordering you one though, for a small fee
Re:when dual-64 will hit the shelves? (Score:3, Informative)
A few examples:
Tyan Thunder K8W [tyan.com]
MSI K8D Master-F [msi.com.tw]
Rioworks HDAMC [rioworks.co.jp]
Re:128-bit? quantum computers? (Score:4, Funny)
Yes, we will. Keep in mind, "near future" is relative. The universe is really, really old.
Apples to oranges (Score:3, Informative)
Ultimately, part of the problem here is that people are still trying to find one single, meaningful number that can tell them whether one processor is "better" or "faster" than another. There just isn't such a thing anymore. Yes, megahertz really is (at least partly) a myth. Processor vendors are doing a lot of things with their chips now that
Re:128-bit? quantum computers? (Score:5, Interesting)
Don't hold your breath. The jump from 8-bit to 16-bit was important; CPUs could address a whole 64KB of memory with just one index register. 16-bit to 32-bit was equally big, since it increased the addressable single-address-byte memory space by a factor of 2^16 (from 64KB to 4GB).
However, with the jump from 32-bit to 64-bit, you're increasing the addressable map by a factor of 4 billion. Put another way, the relative increase is 2^16 times bigger (4 billion fold instead of 65 thousand fold).
I'm still somewhat amazed that my office workstation has over 20,000 times more memory than my first computer. I do not anticipate being alive, though, when an off-the-shelf PC has 4 billion times more memory than this.
Re:128-bit? quantum computers? (Score:5, Interesting)
Every time you increase your bitness of the machine, you increase the size of your pointers, and bigger pointers take up more memory, take longer to load from memory (or store to memory) and they fill up your cache faster. All else being equal, 64-bit code is usually about 5% slower than 32-bit code, and 128-bit code would probably be 10% slower than 64-bit code. Of course, all is rarely equal with 32 vs. 64-bit code (ie the AMD64 instruction set doubles the number of registers when running in 64-bit mode, and that usually more than makes up for the 5% performance hit of running 64-bit code and actually makes things faster since x86 is so register-starved). With Apple's G5 though we might see this 64-bit performance hit. The IBM PowerPC 970 and the PPC arechitecture in general is exactly the same in 64-bit mode as in 32-bit mode (warning: before anyone jumps on me for this, I'm kind of oversimplifying here
There are, of course, exceptions to this rule. Any time you need to access more than about 2GB of memory, then 64-bit is the only way to go. While 32-bit chips can, at least theoretically, support up to 4GB of memory, things start getting really messy by around 2GB and typically you can't actually use more than 3GB. Quite a while down the line (40+ years?), 64-bit processors might run into a similar memory problem and then 128-bit chips will be worthwhile. However, since 64-bit chips can natively address 10^19 bytes of memory, this is still quite a ways off even if we continue the trend of doubling memory requirements every 2 years or so.
There is also the issue of large integers. If you need integers with a range of more than 4 billion (maximum that 32-bit allows), then using 64-bit integers is faster. You CAN deal with 64-bit integers on a 32-bit chip, it just takes at least 3 times as long. If you only need to deal with one 64-bit integer every ten thousand instructions, than this advantage is negligible, but if you deal with very large integers regularly it will help performance. The advantage of using 64-bit integers is very rare though (remember that most complicated calculations use floating point numbers instead of integers). Going from 64-bit to 128-bit integers helps even less. It's got to be extrodinarily rare that an integer range of greater than 10^19 is required.
In short, the need for 64-bit CPUs in here now for some and will be very beneficial for many people in the next 2-5 years. The need for 128-bit chips is pretty much non-existant now and likely won't exist in any meaningful quantity for 30+ years. Beyond that, who knows.
Ohh, and before anyone makes some clueless comment about how game consoles are already 128-bit, they aren't. They are measuring a totally different bitness related to video processing. The CPUs of the three major consoles out there today are all 32-bit. The Nintendo64 used a 64-bit CPU, mainly for marketing purposes, but it was rather useless from a technical point of view.
Re:128-bit? Why would we need it? (Score:3, Informative)
floats are 32 bits.
doubles are 64 bits.
Most modern CPU's handle floating point as 64 bits internally (with a couple extra bits for rounding stuff off, etc.). If the CPU is compliant to the IEEE specs (almost everyone is) you should get the exact same results running on one architecture as another.
The main exception is Intel, whose math processing uses 80 bit internally and is not IEEE compliant. While technically Intel's floating point math is a little more accurate (we're talking about the last
Re:128-bit? Why would we need it? (Score:3, Informative)
doubles are 64 bits.
Sez who?
On the CDC-6600 and 7600, single precision reals were 60 bits and double precision reals were 120 bits (well 1 bit for sign, 11 for exponent and 96 bits for the mantissa).
Sun Fortran has support for 128 bit reals (IIRC copied from DEC) although handling of those beasts is done by software.
Note that while Intels are 80 bit internally, as soon as you move off the CPU, you're back down to 64 bits. Someone correct me if I'm wrong, but I believe there's an
Re:skimps on redhat and fedora details (Score:3, Informative)
When we were discussing this at a system admin meeting, several people who were running Linux clusters got VERY big grins on their faces.
-Erwos