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

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

  2. 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.
  3. 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.

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

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

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

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

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