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."
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 was always preferable to Linux over Windows on 64-bit processors. Of course, I'm talking about the G5...
don't really understand why this shouldbe any different than supporting any other architecture. Linux does run other 64-bit architectures, eg64bit sparc and the antiquated among others. it's really just a matter of time before it's perfected.
big woop. so what else is new?
We went to a Sun demonstration on campus and they showed the new to be released Opteron servers with 1-4 CPUs. Price and performance is very, very good. They come with a SuSE derivitve distro. I couldn't tell if its real SuSE or a SuSE Sun optimized. Anyway, we are going to order a few of them for a BLAST cluster to replace our existing cluster.
This is a test. This is a test of the emergency sig system. This has been only a test.
Windows has a native 64-bit version but Intel have prompted MS to delay the release until they can come up with a competitive processor. AMD serves to steal much of Intel's marketshare otherwise. Useful or not, console wars has caused "64 bits to be better than 32".
Life is the leading cause of death in America.
A few moths ago
Even 64-bit Linux doesn't prevent spelling mistakes on Slashdot.
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
I don't know exactly what caused it, and it may not be much of a concern for other people, but the cpu time on my Seti@home units wouldn't increment using a Redhat beta for x86-64, with both the 64- and 32-bit clients. I liked the idea of using a 64-bit Linux distro but if I couldn't get Seti to run correctly on it, I'll just run a 32-bit version for now (Fedora Core 1 currently).
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.
There are only 10 kinds of people in this world... those who understand binary and those who don't
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.
I've been benchmarking the opteron for the last week, it is at least 26% faster on high mysql load vs a comparably priced opteron system.
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
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!
2 years and no mod points. Join reddit. Because openness is good.
I think there is a general benefit to Open Source that we haven't been able to observe until now. It is a fact that Open Source is more easily ported and adapted, but the major systems haven't changed much for the past many years (Mac, X86, etc.). Now that an entirely new system is out, proprietary software developers will be stumbling over themselves as they try feverishly to make something from scratch, while Open Source developers will benefit from working as a group.
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.
Esoteric reference.
I've been benchmarking the opteron for the last week, it is at least 26% faster on high mysql load vs a comparably priced opteron system.
;)
Really? That's a neat trick
The whole idea of a CPU with more bits of addressability is memory... MORE memory... 4GB of addressable RAM on a 32-bit processor is simply not enough today. Speed is a side-issue, they're already fast, some of us just want more RAM.
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!
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)
Doesn't seem the article tests the system with >4GB. That seems odd since that is one of the most compelling reasons to go 64bit (other than pure bragging rights).
My company 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
"The only questionable aspect of the Suse distribution is the choice of kernel, which is 2.4.21. I know that 2.6.x is beta for now, but it does seem (from the Gentoo installs) that it is faster and able to play nice with the ACPI, unlike 2.4.x on this motherboard."
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.
-If God wanted people to be better than me, he would have made them that way.
That is one of the interesting benefits of virtual execution environments. AFAIK the JIT compilation process can take advantage of the target system's architecture, so .NET apps would not need to be recompiled to see a beneift. I don't have access to a 64 bit CPU so I haven't investigated but I did notice 64 bit versions of the .NET framework in the latest Whidbey betas. I'm not sure if there is a 64 bit version of framework 1.0 or 1.1. I did notice at least one Tech-Ed presentation from this year was on writing .NET apps to target 32 and 64 bit platforms.
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
Yes, we will. Keep in mind, "near future" is relative. The universe is really, really old.
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
That's why you use a handful of well-defined and strictly used prefixes.
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.
The copper bosses killed you, Joe. 'I never died', said he.
I ported my software to the opteron a few months back. It was quick & easy (I used a beta red hat distro). The main reason I got the box was to provide customers an alternative to sun. I work in EDA (we do the software to make the chips) and 4GB is not enough for the big chips. I'd encourage other developers to give the opteron a try. I think it took all of 2 days to do the port. Performance has been good, but since I can't afford a fast sun box, I can't really compare.
Pathscale by former SGI'er does just that.
Help fight continental drift.
...my point is that Linux has 64-bit support and it has it now. Linux and AMD are a natural partnership.
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.
Ruby on Rails Screencast
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.
Dewey, what part of this looks like authorities should be involved?
In my opinion the "killer app" that not only 64bits systems, but linux in general needs to make any serious headway is business applications. Another person who replied touched on this with mention of RDMS.
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
My blog [.net, rants, general IT]
In the near future? Not unless you use a very broad definition of "near future". The main reason for this is quite simply that 128-bit CPUs would be SLOW as compared to 64-bit chips and add absolutely no meaningful features.
:> ).
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.
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.
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
I have had a 64 bit AIX machine running for a while with the 64 bit kernel. While I have not really had the load yet to test it, I and many others in the AIX realm don't necessarily think that 64 bit is going to increase performance. How do you test a performance increase when it only increases by a few nanoseconds??
:) So, the need for more memory is upon us.
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.
Gorkman
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?
I suppose this is really more of a gcc question, but here goes. Does the amd 64 use a 64 bit pid_t, time_t, uid_t, etc? In my opinion, that is one of the more important reasons to switch to a 64 bit processor.
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
A petabyte would be a kilo-terabyte. A mega-terabyte would be and exabyte.