Slashdot Mirror
64-bit Linux On The Opteron
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."
Benchmarking: Again, I do not have any benchmarks on CPU performance to show off. I did run the povray benchmark, but looking over the Povray benchmark page I see P4 3.0GHz machines getting beat out by Athlon 2800's and vice-versa, so I have little faith in the results (or at least in peoples postings to the site). Other sites on the net have run benchmarks on the Opteron, but without a 64 bit OS, and without 64 bit compiled benchmarks, I also have little faith in them. They should be used as a "touchy-feely-sort-of-may-bee" mark at best, in my opinion.
New year Resolution: Don't change sig this year
On the other hand, NetBSD has had amd64 support since 2001.
OpenBSD is reportedly working on it, but I haven't seen anything hit the tree as yet.
The linux opterons we have run SuSE but since the opteron compiler support is still not up to par performance wise they have yet to make a big impact on run times. AMD needs to fund some good compiler development for this architecture, as it CAN perform incredibly, it just doesn't due to unoptimized compilers. Thats why IA64 still beats the pants off Opteron IMHO. The Madison chips from Intel are insanely fast, and their compiler is top notch. PG's compilers just aren't optimized as well as Intels, and it really shows. The numbers I've seen from AMD compared to the numbers I get, are two different things, obviously due to poor optimization at the compiler level.
:-)
I suppose I dont even know the purpose of this post, just some observations
http://www.aceshardware.com/read.jsp?id=60000275
They have 32 and 64 bit apache benchmarks along with some others compared against single and dual xeons.
It is the difference between porting the kernel and porting a distro. There may be some apps in a distro that do not work well on the new architecture. Also each of the apps has to interact with the others and those combinations can cause problems. There could also be issues in the libraries that cause dependent programs to crash in 64 bit mode. Yes in time it will be perfected, but if there are problems now they need to be smoked out and fixed.
This lets you directly jump to the conclusion without having to read the 3-pages:
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)
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.
Debian has not released its port yet, but it is coming. Here is the official Documentation (FAQ and HOWTO)
I've seen plenty of them online (I got mine from googlegear.com, now zipzoomfly.com, but have seen a few at newegg). I got a Tyan retail box server board for my file server from ZZF. (I hate that new name)
:-P)
;-) And I don't work for either company.
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
There are only 10 kinds of people in this world... those who understand binary and those who don't
What are you talking about? Dual Opteron boards have been out since pretty much Day 1 of the Opteron's release.
A few examples:
Tyan Thunder K8W
MSI K8D Master-F
Rioworks HDAMC
Breakfast served all day!
Er, there are 32-bit processors out there that can address more than 4GB of RAM.
Usually via bank switching (e.g. PAE) which is slow and cumbersome.
"Interesting revelation in the tests: Linux, while not having a great share of the market now, will progressively gain user base simply because it is so capable of evolving with new technology."
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.
"Derp de derp."
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.
I've been very happy with Suse on my opteron system, but there's one thing that keeps a 32 bit installation on another partition. ATI, though they've made several press releases about how they "fully support the opteron", has not felt the need to release 64 bit versions of their drivers (either for linux or windows), and the open source radeon driver doesn't support the radeon 9700 pro that I own. I'm almost tempted to get an nVidia card simply because they have 64 bit drivers, even though this generation of cards just isn't as good as ati's.
This is why I'm glad I started out using slackware. 90% of people think it's actually hard to compile your own software.
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 install, but Gentoo works perfectly
Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
Man, you're getting confused. The "bits" that the current generation of processors can sling around have no meaningful comparison to the qubits of quantum computers.
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 make any single figure pretty much irrelevant. You have to look at a whole bunch of things, like pipeline depth, cache design, the things being done to make chips more efficient at lower clock speeds (a la AMD's chips and the Pentium-M), the number and workload of actual function units on each chip, etc.
A "64-bit chip" isn't automatically "better" than a 32-bit one, just like a 2GHz chip isn't automatically better than a 1.8GHz one. One thing remains true: processors are getting better all the time, and will continue to do so.
Breakfast served all day!
I know. That is why I said that 64-bit apps will probably perform better. I was commenting on the fact that the author of the article seems to be under the common assumption that a 64-bit processor will automatically perform worse on 32-bit apps than a 32-bit-only processor (despite the fact that Opteron does run 32-bit apps natively, rather than emulated like Itanium). For an example of this (not Opteron-related, but thematically the same), check out some Mac boards from before the release of the G5, where some posters insisted that every app would have to be recompiled for 64-bits or else they'd perform badly.
Sorry for the misunderstanding.
The BIOS initializes the hardware and then Linux uses it as it has been initialized.
On many systems only the BIOS knows how to do things such as set the speed of the IDE connection. Linux can then query and use that speed but it cannot set the speed to anything else. This can be true even though Linux goes to the hardware directly and does not use the BIOS.
Thunking? You don't need a thunk to support a 64-bit integer on a 32-bit processor, any more than you needed them to support 32-bit integers on a 16- or 8-bit processor.
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.
Pathscale by former SGI'er does just that.
Help fight continental drift.
Tivo could be done with 16 bit processors- it would just take more work, and more clock cycles to get the job done.
If I had a choice between a 16 bit processor running at infinite clock speed, and a 128 bit processor at 2 Ghz. Gimme the 16 bit one- and I'll do realtime raytracing.
According to the Gentoo folks: "The 2.4.x kernel line is being deprecated for amd64. As of 2.4.23-pre7 devfs has been disabled (hardcoded in kernel), stating memory corruption as the reason. Please see this message on lkml for more info: Re: Oops linux 2.4.23-pre6 on amd64. We at gentoo have not experienced any such problems, but 2.4 is not a good solution on Gentoo without devfs." You can read more about Gentoo and Opteron here: http://dev.gentoo.org/~brad_mssw/amd64-tech-notes. html
All modern processors have way more physical registers than architecural registers. Dynamically at run time the registers are renamed. So an increase in physical registers can help even 32-bit code that uses 8 architecural registers....assuming the scheduling window is big enough. Those 8 x86 registers are dynamically mapped to 128 physical registers. Not bad.
"640k should be enough for anybody!"
By that logic, it should have been 64 years between switching to 32 bit from 16 and to 64 from 32. When did x86 finally switch from 16 bit to 32 bit? I don't think it was in 1971.
More addressable memory isn't the only benefit of having more bits per CPU, and even if it were, I think your estimate for how fast things double is off by at least a factor of 2 or so.
-"It seems like you're trying to exploit a security hole. Would you like help?"
Microsoft currently doesn't have a 64bit version of the .Net runtime for 1.0 or 1.1. Whidbey (.Net 2.0) is supposed to ship with a 64bit version.
PAE already allows 32-bit x86 machines to have more than 4GB in the system. There are numerous 32-bit CPU systems with more than 4GB of memory.
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 system in both x86 and native mode, I can say this is a very good thing. Nothing sad about it at all.
Legalize the constitution. Think for yourself question authority.
Good place to bring it up: the academic pricing DOES include the x86-64 version of RHEL, too.
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
Plausible conjecture should not be misrepresented as proof positive.
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.
http://saveie6.com/
uh, no.
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 bit here), it can be annoying that your results from a IA32 processor will be slightly different than from a Sparc...
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 option in gcc to force IA32 code to be IEEE compliant, and it works by inserting a load and save before every floating point operation (forcing the value off chip, which kills performance but causes things to get truncated to 64 bits).
And I've never heard of anything using 96 bits.
How come I'm using it on my dual Opteron 240 (on Tyan S2885) ?
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
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 option in gcc to force IA32 code to be IEEE compliant, and it works by inserting a load and save before every floating point operation (forcing the value off chip, which kills performance but causes things to get truncated to 64 bits).
Dunno about the Pentia, but the original 8087 implementation had a control word that would force rounding to either 32 or 64 bits. Also bear in mind that the SSE facilities in the latest Pentia do not use the 80 bit internal representation (which probably disgusts Kahan, but...).
A Shadeless room is a brighter room.
But really look at PAE. While it allows a computer to have more than 4 GB total, it doesn't allow for any one process to address more than the 4 GB total, regardless of the total amount of memory in the system, since the largest memory pointer any one program can have is still 32-bits long. PAE doesn't get around that restriction for the process. (It's important to remember an OS's idea of a process is inherently built into the processor its self.) And with 64-bits all programs can automaticly take advantage of the new address space, just not programs specificly written with the PAE hoop-jumping in mind.
And for the "new IO" features of 64-bit computers, are there any? I doubt it since, they've already been applied to the 32-bit lines of computers and slipped into the newest chipsets for the 32-bit computers. Intel and AMD both continue to introduce new items like PCI-X and Hypertransport into their "older" 32-bit lines when ever they jump processes or major models. (You're still not running with the same IO systems on the 386 on your P4 now are you?)
PAE was really just a temporary stop gap to fill the void until Intel made its 64-bit processor. The only real reason for going to 64-bits is memory addressing.
A computer of 16-bits or any arbitrary size can emulate a computer of 128-bits or any other arbitrary size with no difficult (especially at an inifinite clock speed.) It just make take more than one instruction to do the same thing.
A petabyte would be a kilo-terabyte. A mega-terabyte would be and exabyte.
Athlon64's run very cool. Under light load, the CPU slows down (all the way down to 800Mhz). Hell, I have heard people using their system with the fan being dead-still! And XP's don't run particularly hot either. In fact, they run a bit cooler than equivalent Intel-chips do!
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
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 really sure what you mean here, but at the time there existed non-Intel versions of Microsoft software, they presented a 32-bit environment, even on 64-bit platforms such as Alpha and MIPS. Given the win32 API, it actually seems like a serious problem extending it to 64-bits in a compatible way, given the frequent and intentional confusion between 32-bit int values and pointers. Working in the computing industry for many years now, I have to start with a low opinion of demos, having written too many myself. If Windows were written with portability in mind, why is it that the Itanium version of Windows Server 2003 lacks so many features of its 32-bit brethren?That there was a brief period of partial cross-platform support in Microsoft's recent history is more to do with from where they got the basis for Windows NT in the first place (ie Digital) than anything else. And word-size agnosticism has never been their strong point - one would have thought they would have learnt from 16-bit Windows 3.1, but no ...
64-bit address space means that a PROCESS (loosely equal to a PROGRAM) can access > 4GB. In Linux, processes are limited by 32bit (i.e., 4GB - though in practice a process can usually not get quite that much).
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 address space at the low level. [I haven't looked into the extent to which this actually happens in the Linux kernel - I hope to read some elaboration.]
(b) removes an important barrier to the many programs that want > 4GB, but can't get it (even on a system with well over 4GB). RDBMS, various simulation models, very large rendering, etc. are all great candidates, and we'll be seeing more. Before someone argues that they *can* get > 4GB on 32-bit: yes, it's possible to have multiple processes working together in a program. But each process has a max of 4GB.
There are lots of interesting byproducts of going to 64-bit addressing, notably that pointers move from 4 bytes to 8. So, today's implementations try to trade off, by allowing either compile-time choice of how large the address space should be, or space-saving techniques so that MANY aspects get the full 64-bit limitations, but not all (for example, 6 bit pointers rather than 8 bit; and limiting the # of file descriptors to 32 bit, since nobody needs 18446744073709551616 open files right now).
Nuff said... Greg