Slashdot Mirror

← Back to Stories (view on slashdot.org)

64-bit Linux On The Opteron

Posted by timothy on from the unchecked-envy dept.

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."

35 of 325 comments (clear)

  1. Market Share by Hadur · · Score: 5, Interesting

    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.

    1. Re:Market Share by IGnatius+T+Foobar · · Score: 2, Interesting

      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.

      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. (I say 'consumer grade' because Windows NT didn't count -- it required what was then considered high-end hardware that most consumers couldn't afford -- but even Windows NT was a good 5-6 years after the 386 shipped.) Despite the availability of a 32-bit processor that finally eliminated the stupid segmentation scheme of the 80286, there was no mass exodus to OS/2 or Xenix.

      Don't count on consumers to be smart. They aren't. All they know is what the TV tells them to believe.

      --
      Tired of FB/Google censorship? Visit UNCENSORED!
  2. whats the deal by nil5 · · Score: 3, Interesting

    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?

    1. Re:whats the deal by the_bahua · · Score: 3, Interesting

      Yeah, that's kind of my feeling. It's nice that it's working, but it looks like it still isn't quite there yet. Until I hear some better things about 64-bit performance in GNU/Linux with the Opteron, I'm going to stick with my athlon for now.

      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.

  3. Awesome by bigjnsa500 · · Score: 5, Interesting

    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.
  4. Windows 64 by swordboy · · Score: 3, Interesting

    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.
    1. Re:Windows 64 by jmauro · · Score: 5, Interesting

      An even better example would be MMX, SSE and SSE2 on the curret 32-bit x86 machines. All three of can process numbers that are 128-bits long. Sadly more and more machines will need to address more than 4 gigs of data at once, forcing the move to 64-bits for addressing.

    2. Re:Windows 64 by Nothinman · · Score: 2, Interesting

      I read a while ago that it comes with both versions of alot of applications because right now it's more of a development platform than anything else.

      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 libraries, it's not a good idea (or not possible, I'm not 100% sure) to mix them so to run 32-bit IE on a 64-bit system you need a 32-bit copy of every library it depends on. And if you want to run a 64-bit version along side it you need both versions of all the libraries too. This is the biggest problem Debian is having right now, getting bi-architecture support to work cleanly.

    3. Re:Windows 64 by RALE007 · · Score: 2, Interesting
      Amen. An ad on the back of the January '04 Popular Science ragazine reads:

      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 creations with memory to spare. Prepare to blow minds. Get a dose of the AMD Athlon 64 FX edge at www.amd.com/amdathlon64fx

      The ad really annoyed me. Apparently a wider data bus doubles the computing "thrill factor". Which is good because for a while there it seemed we were approaching a "thrill factor" barrier. *Whew* glad we found away to continue the growth of the "thrill factor". I'm happy to see the computing "thrill factor" will continue to grow at an exponential rate for the foreseeable future.

      It's great they're acting like you need a multi-gigahertz 64 bit processor to stream audio. Yep, this new processor will really speed up my net connection.

      Lastly, because the processor is 64-bit, apparently I will have memory to spare for "editing, mixing, and modeling my own digital creations". And here I just thought I'd have the ability to address more memory, but I was wrong, nope, it will *give* me memory to spare.

      Marketing sucks.

      --
      Beware blue cats moving at .99c
    4. Re:Windows 64 by Anonymous Coward · · Score: 1, Interesting

      I did mention that PAE only allowed 4GB per process. I agree it is a hack - but a useful one.

      I think PCI-Express, Hypertransport and PCIX-133 are big steps forward - I think you will see more "real" slots in the Opteron systems than the mostly junk slots you get with today's P4 (Xeon systems seem to have decent PCI slots in them) and particularly the Athlon boards. I think in this transition they will have time to revamp how this all works.

      I believe the underpinnings will be better mated to these new CPUs, just as Fire (and UPA) is in Sun GX in Power4/4+, we now get Hypertransport and a better pathway. It's getting closer to real IO - this is what I want out of the deal.

      Think of it this way, SPARC and SPARC64 are a lot more than just 64-bits different. I think this is another evolutionary change in computing and it's more important that memory addressability alone.

      I advocate the move to 64-bit, but hope to get a lot more out of it than just massive memory addressability, though this is a compelling reason to move.

      PC's have been more than adequate for the roles they fill today for some time. The real stuff was done, and will continue to be done on heavier stuff. It is nice to see heavier stuff like the Opteron trickling down to being within reach of the common, more low-end server and computer. I think you get a lot more out of a heavy hitting box than a bunch of ram. I've proven it to myself with various boards and high speed network IO, all motherboards and the chipsets that surround a CPU are not the same, and it tends to be that the heavier hitting the CPU is (which also tend to be 64-bit, SB2000, Alpha ES47, Power 4+, etc) have a lot more beef to handle viscous amounts of IO. I can easily kill a desktop style PC and most 32 bit "servers" with IO, and a lot of it has to due with various inefficiencies I think the Opteron will alleviate.

  5. 128-bit? quantum computers? by Anonymous Coward · · Score: 1, Interesting

    a bit offtopic, i know, but i can't help wondering whether we'd see 128-bit cpu's in the near future... possibly with quantum computers.

    well?

    1. Re:128-bit? quantum computers? by sundling · · Score: 2, Interesting

      I doubt I will see 128 bit computing in our lifetime, but then again I might live longer than I expect. Why would we need it? The memory
      addressing situation will take probably over 100 years, if you think of the amount of memory doubling every 2 years, to take up that next 64 bits of address space, that's about 128 years, right?

      So, short of some new technology requirements or ram moving much faster (it will probably advance slower) it doesn't sound likely.

    2. Re:128-bit? quantum computers? by Just+Some+Guy · · Score: 4, Interesting
      a bit offtopic, i know, but i can't help wondering whether we'd see 128-bit cpu's in the near future... possibly with quantum computers.

      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?
    3. Re:128-bit? quantum computers? by Hoser+McMoose · · Score: 5, Interesting

      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.

  6. Seti problems with x86-64 kernel by Alizarin+Erythrosin · · Score: 4, Interesting

    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
  7. Speed vs Memory by ArkiMage · · Score: 5, Interesting

    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!

    1. Re:Speed vs Memory by IvyKing · · Score: 5, Interesting
      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.

      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.

    2. Re:Speed vs Memory by Nothinman · · Score: 2, Interesting

      If you're letting the OS do the caching you could get an IA32 system that handles >4G memory and the performance would probably be close, I'm not sure how much of a performance hit PAE in the kernel has but the price difference might make it worthwhile. And since you'd be relying on the normal Linux page cache the applications don't have to be 64-bit aware to have all that memory used for their caching.

  8. What about 4GB? by localman · · Score: 5, Interesting

    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

    1. Re:What about 4GB? by Junta · · Score: 3, Interesting

      I've been working with an Opteron platform as well and I've seen several issues when the memory gets above 4GB. A lot of it has to do with them recycling the 32-bit code used for BIOS operations before that breaks under those conditions. In our case, the problems are mostly solved. We have seen a couple of dirvers, however, that had issues (some really picky portions that really relied on addresses being 32 bit values). The 32-bit capability is a double-edged sword, gives greater compatiblity, but someimtes companies take shortcuts with what they have since it at least gives the initial impression of working, when the reality is that the shortcuts break things in some obscure ways.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  9. heh? by DashEvil · · Score: 5, Interesting

    "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.
    1. Re:heh? by EMN13 · · Score: 3, Interesting

      That's not so stupid at all. Although i have no experience with 2.3; I've heard it said that the general stability of 2.6-test is quite beyond that of the early 2.4-test - so much so that it's quite useable.

      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

  10. Anyone know about the maturity of NUMA support? by Serveert · · Score: 2, Interesting

    I believe the latest 2.4 Linux kernels have NUMA support but is it mature or will it get any better? Are other unix OS'es better at taking advantage of NUMA compared to Linux and will this change in a future Linux version?

    --
    2 years and no mod points. Join reddit. Because openness is good.
  11. .NET by MrBlack · · Score: 4, Interesting

    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.

  12. Re: Hungarian Notation by bluGill · · Score: 2, 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.

  13. Re: Hungarian Notation by rhinoX · · Score: 4, Interesting

    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.
  14. 64 bit is more about memory by stabiesoft · · Score: 4, Interesting

    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.

  15. Re:hurdles by Hoser+McMoose · · Score: 2, Interesting

    OS X has only VERY half-assed 64-bit support. It's support is barely better than Intel's PAE mode which has been supported in Windows for years (since NT4.0). The Macs have the minor advantage of being able to handle 64-bit integers through math libraries, but while that's nice, it's really a very distant secondary benefit of 64-bit processors.

    To have proper 64-bit support you need to be able to give the application a flat 64-bit virtual address space to work with. OS X does not do this in any way, shape or form.

    Don't get me wrong, OS X is a good operating system, Apple really seems to have taking the right approach to it's design IMO. But it's definitely not a 64-bit OS.

  16. FreeBSD/amd64 by DarkHelmet433 · · Score: 5, Interesting
    I threw together a 30 second screenshot in case anybody is interested. http://people.freebsd.org/~peter/desktop.png

    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.

  17. Re:128-bit? Why would we need it? by raxx7 · · Score: 2, Interesting

    Besides the single and double precision formats, the IEEE 754 also loosely defines two classes of extented formats.
    A few I know that exist: 80 bit (x87, IPF), 96 bit (Cray), 128 bit (SPARC, Alpha, PowerPC).
    The thing is that, as you mentioned, to get IEEE 754 complian behaviour out of x87 you need to store and load back the results. This is because x87 only has operations on 80 bit formats, that yield results rounded to 80 bit. If you want 32 or 64 bit precision, you need to round those results to get IEEE compliant results. And the store/load cycle is the (painful) way to do it. Any IEEE 754 compliant compiler should be able to do this, its not a a GCC specific feature.
    SSE/SSE2 extension and other architecures don't have this problem: they have operations that yield properly rounded results to the intended precision, no matter how they work internally.

  18. Re:Well... by truesaer · · Score: 4, Interesting
    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.


    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!

  19. C types by WhiteDragon · · Score: 3, Interesting

    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?
  20. Re:If X doesn't work on Gentoo/Opteron... by Brane2 · · Score: 5, Interesting

    I'm using it because: -I need 64 bit integer ops
    - 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...

  21. Linux by Exter-C · · Score: 2, Interesting

    I have recently built up a system based on an opteron processor in a dual processor configuration. I had more problems than i had ever had with other systems initially. However once I upgraded hardware bios's and other things like that it became a good task. Ive since replaced several systems with opterons and all is working well and stable.. note these are servers and have no X.. DB servers and Web / Mail servers. The increased performance is noticable over the last hardware that wasnt that old as well (Dell PE-2650 Dual XEON's 2400mhz etc).

  22. Re:Windows applications by kbsingh · · Score: 2, Interesting

    Where exactly did you get this figure of 40%?

    Correct me if I am wrong, but 40% of all applications on Windows translates to a few hundred thousand apps.