Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
AMD Intel Hardware

Linux Shootout: Opteron 150 vs. Xeon 3.6GHz Nocona 217

Posted by michael from the they'll-still-be-obsolete-in-a-year dept.
danalien writes "Anandtech with their previous review have stirred up a bit of controversy, and they've released their follow-up review where they pit AMD's Opteron 150 vs Intel's Xeon 3.6 Nocona (on linux)."
This discussion has been archived. No new comments can be posted.

Linux Shootout: Opteron 150 vs. Xeon 3.6GHz Nocona More

Linux Shootout: Opteron 150 vs. Xeon 3.6GHz Nocona

Comments Filter:

  • Short version: Xeon RIP. (Score:5, Interesting)

    by Anonymous Coward on Sunday August 15, 2004 @08:39AM (#9973274)

    No message here. Oh, did you know that an Athlon64 3000+ is within 2fps of a P4 3.4 Extreme Edition [anandtech.com] in Doom 3?

    Look up the prices for those two items.

    • Re:Short version: Xeon RIP. (Score:5, Informative)

      by Anonymous Coward on Sunday August 15, 2004 @08:47AM (#9973296)

      Athlon64 3000+ (2GHz): $167 [newegg.com]
      Pentium 4 3.4GHz Extreme Edition: $1025 [newegg.com]

    • I think it should go without saying that Doom 3 has nothing to do with the typical market for Xeon.

      I'd also hesitate to make a choice based on performance on a single program unless that is the only program I ever plan to use.
  • i thought it was Athlon 64 now?

    • Re:opteron (Score:5, Informative)

      by lachlan76 ( 770870 ) on Sunday August 15, 2004 @08:43AM (#9973287)
      Athlon 64 is the name used for the desktop line, and Opteron is the name used for the server/workstation processors.

      • Re:opteron (Score:3, Informative)

        by NoMercy ( 105420 )
        The critical point being that Opterons unlike there Athlon 64 cousins have more hyper-transport interfaces, allowing them to be used in a multy-processor enviroment, depending on the seriese number up to 8-way systems can be built, though I think the largest Tyan's only carry 4 at present.

        There's other minor diferences but *goes off dreaming about a 4-way processor in a database server*

  • Memory (Score:5, Insightful)

    by lachlan76 ( 770870 ) on Sunday August 15, 2004 @08:41AM (#9973280)
    To be able to show the real potential of the Opteron, you need to have more than one processor.

    This lets you take advantage of the on-die memory controller, by letting each processor do it's own memory work, rather than making the Northbrige do all the work.

    If you want to use a single processor, you might as well use an FX-Whatever, since they are just an Opteron without MP capability and only one HT bus.

    • Re:Memory (Score:5, Informative)

      by Ianoo ( 711633 ) on Sunday August 15, 2004 @08:53AM (#9973311) Journal
      Provided you have a NUMA-aware operating system, that is. The OS needs to know which memory is attached to which processor, since access to memory attached to the same processor on which a thread is running will obviously be faster and lower latency than going across hypertransport to a different processor and waiting for an answer.
      • Provided you have a NUMA-aware operating system, that is.

        Like Linux 2.6, you mean?
        • Like Linux 2.6, you mean?
          Yes. Yes I do.
          • You still must give CPU affinity explicitely but yes it's numa aware.
            • If I remember correctly, the speedup of turning on this numa-awareness on an opteron multiprocessor system is negligible even on benchmarks which should stress it. It's a neat feature but doesn't appearantly really help the opteron (partially because the HT bus is very fast and the number of CPU's involved isn't so great).

              --Eamon

        • Re:Memory (Score:2, Informative)

          by upsidedown_duck ( 788782 )

          What about Solaris, IRIX, AIX, etc.?

          UltraSPARCs have been running with memory local to CPUs for quite a while now, for example.

          • Re:Memory (Score:2, Informative)

            by andreyw ( 798182 )
            Well, while Solaris is *technically* going to be ported to x86-64 eventually... IRIX and AIX won't for sure.

      • Re:Memory (Score:5, Insightful)

        by ottffssent ( 18387 ) on Sunday August 15, 2004 @02:32PM (#9974995)
        Actually, even without a NUMA-aware OS, the worst-case dual (and almost quad) memory latency is less than a Xeon's.

        What really sets the Opteron apart in MP scenarios is the bandwidth. Each chip gets 6.4G/sec to memory: add more chips, get more bandwidth. The Xeon on the other hand has to share its 6.4G/sec with all the chips in the system, which severely limits its scaling. A quad Opteron has over 25G/sec of aggregate memory bandwidth, while a quad Xeon is stuck with its 6.4G shared 4 ways. That's half the bandwidth of a 400MHz P4 - no wonder the quad Xeons are often barely faster than the duals.

        Add to this that cache snoops and other bus traffic all have to share the same FSB on the Xeon whereas on the Opteron local memory accesses don't touch the HT links at all. For a standard 2P system, this frees up 3.2G/sec of HT link bandwidth, and a NUMA-aware OS only increases the efficiency of the system.

        Despite Intel's recent marketing push, they really don't have the best CPU, and don't have the best system either. There are still considerable advantages to choosing a Xeon system but these days they have little to do with the chip or the board and a lot to do with Intel backing. That's an advantage that will quickly evaporate as industry gets comfortable with non-Intel parts.

    • Re:Memory (Score:1, Interesting)

      by Anonymous Coward
      your argument is pretty fucking retarded. it is NOT always better to move away from a BUS architecture.

      simple proof: consider an array of 486 processors connected by an ultra-fast, ultra-low-latency network.

      long boring argument for idiots like you: suppose you have a single value in memory, called 'GO!!', it has the value 0 or 1. If it's ever set to 1, all the CPUs have to do some work and write an answer or something. If it's set to 0, the CPUs have to stay idle, otherwise the electricity man comes and s

      • Re:Memory (Score:4, Informative)

        by Waffle Iron ( 339739 ) on Sunday August 15, 2004 @09:27AM (#9973417)
        THE INSTANT ANY CPU WRITES A ONE TO GO!!, ALL THE CPUS KNOW IT!! AND CAN START WORKING INSTANTLY!

        How do they know? By cache coherence signals transferred between the CPUs. This isn't free and consumes bus bandwidth.

        The first CPU can't "instantly" write the value either, because it must first obtain exclusive ownership of that cache line by checking with the other CPUs.

        On the Opteron architecture (we call this NUMA, or "point-to-point"), as soon as one CPU writes a value to the 'GO!!' area, well, that's _just the beginning_. It has to tell another CPU in the system that it just did that. etc etc

        It has to use some communication resource to update the other CPUs on the state of that cache line. Just like the bus-based situation.

      • This is assuming that the CPUs are all working on the same data set.

        If (theoretically) you got all of the CPUs working on an independant dataset then the CPUs would scale much better.

  • These in-architecture tests are OK, but... (Score:5, Interesting)

    by Amiga Lover ( 708890 ) on Sunday August 15, 2004 @08:47AM (#9973295)
    It's good to see benchmarks between processors in the same family, but is there anywhere that regularly tests CPUs across families? x86, PPC, Sparc, VIA etc. I'd like to see comparisons like that to see how various architectures strengths & weaknesses stack up

  • set-up benchmarks? (Score:1, Interesting)

    by Metteyya ( 790458 )
    There's been some controversy about benchmarks being set up in favor of Intel, thus allowing it's processors - even having lower amount of MHz - to win most.

    But I've seen some computers which, having only switched from AMD to comparable (in clock frequency) Intel processor, got some boost in speed. Especially in games. And I've seen some changing from Intel to AMD, suffering loss of speed - mainly in games.

    I don't know if recent games (I've seen these effects mainly with Neverwinter Nights) are compil

    • Re:set-up benchmarks? (Score:2, Interesting)

      by sigaar ( 733777 )

      It really depends on what the rest of the hardware in the box is. AMD's (especially K6-II/III and Duron) CPUs tend to be seen as the low cost alternative and put in a box with a cheapo mobo, cheap mem and everything that goes with it, more often than Intel's CPUs. This is just my observation in dealing with a lot of SMEs, some who go all out and some who try to save where ever possible.

      Shining example. We run an Astaro [astaro.com] firewall for one of our clients. At first they didn't have machine available, when w
    • But I've seen some computers which, having only switched from AMD to comparable (in clock frequency) Intel processor, got some boost in speed.

      That doesn't make any sense. Current AMD chips ALLWAYS perform better at the same clock speed. If you really mean that AMD chips with a performance rating (or whatever their calling it this week) similar to the Intel tends to perform a bit worse then that might make some sense. In addition recent Intel and AMD chips won't work in the same motherboards so clearly

  • Opteron cpu hacked (Score:5, Interesting)

    by GuyFawkes ( 729054 ) on Sunday August 15, 2004 @08:49AM (#9973300) Homepage Journal
    I submitted this story an hour or two ago, but thinking about it it will be rejected just like everything else, and then pop up under someone else's name.

    so what the hell.

    Opteron Exposed: Reverse Engineering AMD K8 Microcode Updates

    Summary

    This document details the procedure for performing microcode updates on the AMD K8 processors. It also gives background information on the K8 microcode design and provides information on altering the microcode and loading the altered update for those who are interested in microcode hacking.

    Source code is included for a simple Linux microcode update driver for those who want to update their K8's microcode without waiting for the motherboard vendor to add it to the BIOS. The latest microcode update blocks are included in the driver.

    Background

    Modern x86 microprocessors from Intel and AMD contain a feature known as "microcode update", or as the vendors prefer to call it, "BIOS update". Essentially the processor can reconfigure parts of its own hardware to fix bugs ("errata") in the silicon that would normally require a recall.

    This is done by loading a block of "patch data" created by the CPU vendor into the processor using special control registers. Microcode updates essentially override hardware features with sequences of the internal RISC-like micro-ops (uops) actually executed by the processor. They can also replace the implementations of microcoded instructions already handled by hard-wired sequences in an on-die microcode ROM.

    AMD's U.S. Patent 6438664 ("Microcode patch device and method for patching microcode using match registers and patch routines") goes into substantial detail on this.

    Typically microcode update blocks are stored in the BIOS flash ROM and loaded into the processor as the system boots. They can also be loaded by the operating system; for instance, Linux contains a microcode device driver for Intel chips.

    AMD recently released a "BIOS fix" to motherboard makers to address Errata 109, in which REP MOVS instructions caused subsequent instructions to be skipped under specific pipeline conditions.

    Previously it was not clear if and how AMD even supported microcode updates in the K8 family until this announcement. After analyzing a number of BIOS images, it appears that AMD has secretly used the microcode update facility on several occasions over the past few years, but obviously avoided publicly disclosing that it actually had bugs patchable in this manner.

    Early K7 (Athlon) cores initially supported microcode updates as well, until ironically the microcode update mechanism itself was found to be broken and subsequently listed as an errata!

    The following sections describe the microcode update procedure, obtained by clean room reverse engineering various vendors' BIOS code. The actual microcode update blocks are embedded in the BIOS image; the most recent updates (created June 2004) have been included in the Linux driver source code attached to this description.

    Microcode Update Procedure

    The update procedure expects the 64-bit virtual address of the update data, including the 64 byte header, to be in edx:eax:

    edx = high 32 bits of 64-bit virtual address
    eax = low 32 bits of 64-bit virtual address
    ecx = 0xc0010020 (MSR to trigger update)

    Execute wrmsr with these register values. If the address and update block data are valid, wrmsr completes successfully. Otherwise, a GP fault is taken.

    The microcode does not appear to update MSR 0x8B with the new update signature as it does on Intel processors, despite the fact that some BIOS code I have analyzed does seem to check this field. It is possible the MSR is only updated under certain conditions, for instance when microcode is loaded before initializing the cache controller. Nonetheless, as we shall see below, the processor is clearly doing something internally when it claims to accept an update in this manner.

    The update generally takes around 5500 clock

    • Re:Opteron cpu hacked (Score:5, Insightful)

      by Ianoo ( 711633 ) on Sunday August 15, 2004 @09:17AM (#9973379) Journal
      Microcode updates aren't permanent though - you need to reload them every time the machine boots. So clearly you would need to reload these "hacks" using a piece of software during the boot process.

      Also, the article admits that it's "very unlikely" that a particular processor could be fried using a dodgy microcode update, so why even mention it? It would be much easier to write a BIOS flashing virus, I believe a few of these did exist at one point (although the old memory is failing). I doubt the hoops you'd need to jump through to write such a thing for Intel processors are no higher than for AMD processors, and as such, this is just FUD.

      • Re:Opteron cpu hacked (Score:3, Insightful)

        by arose ( 644256 )
        It would be much easier to write a BIOS flashing virus, I believe a few of these did exist at one point
        Chernobyl [cert.org].

      • Re:Opteron cpu hacked (Score:5, Insightful)

        by Sunspire ( 784352 ) on Sunday August 15, 2004 @11:09AM (#9973803)
        I'm not sure if other Linux distributions do this already, but at least Fedora Core 1 and 2 both come with a processor microcode update service that runs in the bootup sequence. It's even enabled by default out of the box.

        Linux has for a long time already mostly ignored the system BIOS since they're notoriously broken because of legacy reasons. Supplying known good microcode is simply another step in eliminating variables that make system testing needlessly complex, I predict we'll see more developments along these lines in general.

    • Does the above article have an original source? I'm guessing it didn't just spontaneously appear on half a dozen weblogs [google.com], it was probably written by someone who would like credit for his/her work? Perhaps this is why the story was rejected?

      -jim

      • Re:Original source? (Score:3, Informative)

        by GuyFawkes ( 729054 )
        quoted in the submission
        http://www.realworldtech.com/forums/in dex.cfm?acti on=detail&PostNum=2527&Thread=1&entryID=35446&room ID=11

        hasn't been rejected yet, still pending, but no doubt will be.
    • Submit this stuff to Kuro5hin [kuro5hin.org], it would be welcomed with open arms (mostly).

      Was an interesting read!

      --Robert
      • Original discussion at

        http://www.realworldtech.com/forums/index.cfm?ac ti on=detail&PostNum=2527&Thread=1&entryID=35446&room ID=11

        I only saw it because bruce scheiner pointed it out.

  • This doesn't look good for Intel (Score:5, Interesting)

    by GreatDrok ( 684119 ) on Sunday August 15, 2004 @08:52AM (#9973305) Journal
    I recently installed Fedora 2 on a dual Opteron 248 system (Sun V20Z) and was amazed at the sheer grunt of the thing. Why anyone would even consider buying a Xeon just amazes me. I ran one of my own integer and memory heavy benchmark programs (single threaded) against my Athlon XP 2200+ and a single Opteron processor was 3x faster than the XP for only 400Mhz higher clock speed. These things are amazing, Intel should be crapping themselves and I am sure they would be if it wasn't for the cozy deal with Dell and the number of sites that have a Dell only policy. In a true free market they would be toast.
    • Dell will move back to AMD if they think it's worth it, and I think they are starting to feel the heat. The opteron has went down very well in nearly all sectors, and I think we should see opteron servers soon. Hopefully.
    • Actually. it is a free market. Intel stil has the Intel name going for them. It'll be a long time (in tech time) before that changes.

  • Difficult to trust? (Score:5, Insightful)

    by arose ( 644256 ) on Sunday August 15, 2004 @08:55AM (#9973320)
    As we can see above, the difference between the two CPUs seems exaggerated and difficult to trust.
    Maybe it's because Intel still makes processors for MHz and not performance? Maybe because unlike some comercial vendors the POV-Ray Team doesn't feel the need to make processor specific optimizations and leave that to job to the compiler (where it belongs)?

    • Re:Difficult to trust? (Score:5, Insightful)

      by ezzzD55J ( 697465 ) <slashdot5@scum.org> on Sunday August 15, 2004 @09:12AM (#9973363) Homepage
      This review struck me as a bit clueless, or unfinished. The above quote is a good example of why i think so. They do some measurements, but aren't sure they're doing it fairly (compiler flags), and don't know what to do with the results. There is little in the way of analysis or conclusions. With the openssl measurements they don't even give any conclusions. But analysis and conclusions are the whole point of the review, and a remark like "As we can see above, the difference between the two CPUs seems exaggerated and difficult to trust." really devaluates this review - they're just showing us measurements they're not sure are correct ('difficult to trust') and let us figure out what they're worth?

      Well, the conclusion that the opteron kicks the xeon's ass is pretty inescapable to me, finding out opteron is available and the xeon isn't quite yet and more expensive, really closes the deal to me. But the review isn't very scientific, and didn't go very deep.

      • It says to me that compiler flags matter a lot! ...oops, maybe those Gentoo zealots are onto something!
        • It says to me that compiler flags matter a lot!

          They do, but some performance-oriented flags can either cause instability or mistaken results. I've seen single flags cause a program to core dump or not, and even any optimization at all can cause some programs to crash (probably a very obscure bug regarding program and compiler assumptions...I never found it).

        • Yes, yes we are. :)

          You definitely have to be careful about which ones you pick, though, and if you're really worried about performance you have to do what they did in this review, and try different settings with different programs because different flags will produce different results on different programs.

          In general I use -O3 on older processors, like pentium2 cores, and -O2 on newer ones. I don't know if it's still true but -O3 was known to cause problems (errors, not just a performance hit) with G

      • Re:Difficult to trust? (Score:5, Insightful)

        by alienw ( 585907 ) <alienw.slashdotNO@SPAMgmail.com> on Sunday August 15, 2004 @10:43AM (#9973685)
        That's because it is nearly impossible to do a scientific comparison of two different processors. Anyone who tells you otherwise is a moron.

        You have to evaluate performance (possibly vs price) for your particular application. If you need a faster processor for Doom 3, look at Doom 3 benchmarks. If you need to encode video, look at video benchmarks. If you need to do integer computations, look at integer benchmarks. Xeons probably kick AMD's ass at some applications, and AMD might beat the Xeon at others. You can't just say that one is "better" than the other in general.
        • Well, actually you can if one beats the other in almost all the benchmarks : )
        • You have to evaluate performance (possibly vs price) for your particular application.

          Well considering that that Intel chip is more than 6 times the price of the AMD chip, if $858 matters to you at all, then AMD appears to win hands down.

          Considering that the AMD chip is considerably faster on the vast majority of tasks, if you run multiple kinds of software, or even one peice of software with code that does multiple things, then on average the AMD appears to win hands down.

          But yeah, you're right. *IF* yo
          • Well considering that that Intel chip is more than 6 times the price of the AMD chip, if $858 matters to you at all, then AMD appears to win hands down.

            This is a SERVER processor. If you are running a server, cost matters very little. Hell, you probably pay more than $800 to your janitor. Reliability, performance, and compatibility are what matters. AMD may be a better value, but Intel has a lot more experience with servers. Do you want to buy a $250K cluster to find out it doesn't work reliably with
    • But they are not making just for MHz now. They are switching all CPU lines over to a similar system of numbering that AMD uses for Opetron CPUs, that is a 3 number ID code. The Prescott based Celeron is now known as the '320D' for example. The Pentium-M line is moving over soon (if they haven't totally done that yet).

  • Lame conclusion? (Score:4, Informative)

    by Quixote ( 154172 ) on Sunday August 15, 2004 @09:07AM (#9973347) Homepage Journal
    The comparison concludes with the wishy-washy statement:
    After all is said and done it became difficult (nearly impossible?) to justify the Xeon processor in a UP configuration over the Opteron 150,

    Huh? Here are some numbers:

    • POV-Ray 3.50c: Opteron is 40% faster
    • Crafty v19.15: Opteron is 70% faster
    • TSCP: 10% faster
    • PostgresSQL test-insert and test-select: Opteron takes 60% of the time it takes Xeon
    • MySQL test-insert: Opteron takes 80% of the time it takes Xeon.
    In almost every benchmark, where proper optimizations are used (and why shouldn't they be? Who in his/her right mind would not use proper optimizations??), the Opteron destroys the Xeon.
  • Anandtech originally posted an article [anandtech.com] which was a comparison of the Intel Xeon Nocona ("3.6F") and the AMD Athlon 64 3500+. The Xeon "won" most of the benchmarks by a good amount.

    The criticisms were that the Xeon is not a desktop CPU, or vice-versa, the Athlon is not a workstation/server CPU. But are they so different? The Xeon has 1MB L2 cache, and so does the P4 Prescott (and presumably Prescott with x86-64 enabled), and both run at the same speed.

    Similarly, the 3500+ runs at 2.2GHz and has a 51
  • I can say it kicks all kinds of ass in Doom3. :) I see that all sors of business/content creation benchmarks were used in the Anandtech review, but when a Baron of Hell corners you an ancient underground Mars excavation site... Well, lets just say your death animation looks all the more sweet with those extra fps.

  • Hyperthreading is not good for these benchmarks (Score:5, Insightful)

    by DJStealth ( 103231 ) on Sunday August 15, 2004 @09:24AM (#9973408)
    As hyperthreading cuts the L2 cache in HALF, it should be disabled before doing any of these benchmarks. Hyperthreading only seems to improve the multithreading ability. These benchmarks being run on a single process are not realistic.
    • Hypterthreading doesn't cut the L2 cache in half. At least not statically, it is possible that if you're unlucky it will indeed look like each process will only have half the cache.
    • As hyperthreading cuts the L2 cache in HALF, it should be disabled before doing any of these benchmarks. Hyperthreading only seems to improve the multithreading ability. These benchmarks being run on a single process are not realistic.

      Since it isn't possible to dynamically turn hyperthreading on and off while the system is running, the benchmarks should be run in the mode most systems will use - with (highly touted) HYPErthreading turned on. After all, it is supposed to be a useful feature...

      Personally,

      • I've tested this on various machines. Benchmarks for single processes are almost always higher with HT turned off. However, in multitasking system with only 1 processor, you are correct in stating that it should be turned on; yet the benchmarks shown on this site are meaningless unless they are tested in a multitasking environment.

        However, we may be getting a few multiprocessor Xeon's for research use; since there are multiple processors, I'm debating whether HT should be turned OFF, as HT slows things d
        • However, we may be getting a few multiprocessor Xeon's for research use; since there are multiple processors, I'm debating whether HT should be turned OFF, as HT slows things down for single processes, and as there are multiple processors to deal with multiple processes, HT may not serve any advantage whatsoever.

          Well, you should really look at the number of compute-bound threads you have active on average. If that number is around 4 or greater, and you have a dual-processor box, then you should probably

    • But in the real world, wouldn't you have HT enabled, even doing this kind of stuff?

  • AnandTech Biased (Score:2, Interesting)

    by ironwill96 ( 736883 )
    It seems to me that AnandTech seems to be biased in Intel's favor for some odd reason. Either that, or that particular reviewer happens to be. Last week in their other review they said the Intel Xeon processor was way better - even when the results were about the same skewed in Intel's favor. Now that the results are skewed toward AMD the reviewer still refuses to see that the Opteron is a better processor, is available NOW, and is $250 cheaper than the Xeon-yet-to-be-released that they are comparing it
    • "I've lost all faith in reviews by some of these hardware sites lately - they seem to be getting paid by someone to make invalid conclusions (or none at all) from fairly conclusive data."

      We still have Ars. :)

    • Re:AnandTech Biased (Score:3, Insightful)

      by swordgeek ( 112599 )
      Anandtech isn't biased, it's incompetent.

      Don't get me wrong--I've liked Anand and company since they first hit the internet. They don't generally have an axe to grind or an ego to boost (both of which TomsHardware suffers from terribly), but they don't have the slightest bloody clue about statistics, or significance.

      Fun to read, and not consistently biased, but not a great source of actual benchmarking or review information. (techreport.com is better for that)

  • Those results speak for themselves (Score:3, Informative)

    by Stevyn ( 691306 ) on Sunday August 15, 2004 @09:38AM (#9973463)
    Other than a few benchmarks that were either synthetic or not compiled specifically for the processor, AMD whooped Intel's ass. Some of the gains were quite significant.

    However, this speed increase seems to depend on being able to compile your software from scratch which is generally unknown in the windows world. That should change in the future, but for now it's still a tough call whether or not to buy one now. But if you're running gentoo, let the funroll-loops begin!
    • The decision is simple: bang for the buck. AMD always wins that choice. Check other reviews for the best motherboard to go with it and build a real hot rod gamer, or a fast enough web server to need more bandwidth.

  • Other Ideas for benchmarks (Score:5, Interesting)

    by johnhennessy ( 94737 ) on Sunday August 15, 2004 @10:07AM (#9973562)
    How about profiling bytecode interpreters for the new breed 64 bit processors.

    Both Sun (the original innovators) and now Microsoft are putting their money on their bytecode (rather than binary) executables to try and avoid the whole backwards compatibilty problems when moving architectures. To get to grips with how important this is - Microsoft has only just recently managed to escape from the 16 bit code hell that it lived in for years (need proof - check out the Win16Lock you needed to get access to the video memory in DirectX).

    That said, I can't imagine that many (someone might enlighten us here) performance benchmarks that a 64 bit bytecode interpreter could do better in when compared to its 32 bit smaller brother.

    What would be interesting here would be to see how Javas bytecode and CIL scale to 64 bit. My first guess would be that Java should scale better (with Suns heritage of 64 bit platforms) but I wouldn't be surprised if MSFT weren't too far behind, as they were always keeping their eye on this test when designing the CIL. This would also be a good chance for the Mono project to try a "ours is better than yours" benchmark for their interpreterrs.
  • cona in portuguese jargon, is a vagina... :D
  • go read this Infoworld review [infoworld.com]. They don't list any real figures that I could track -- do other reviews replicate their results?

  • These benchmarks show the Opteron 150, a $600, real-world-available chip handily beating a $850, non-real-world-available chip. But that's still not the half of it.

    Wait until tests are run on multi-CPU machines. Because the Opterons scale so much better than Xeons, the performance advantage of the Opteron will be even greater.

    When I've bought a quad Xeon machine, I've never been at all impressed with the scalability. When I bought a quad Opteron, I was blown away.

    steve

  • My own results (Score:2, Interesting)

    by davros74 ( 194914 )
    We have been benchmarking several loaner boxes at work to determine what will be our next purchases for our compute farm. We do primarily ASIC and FPGA design, simulation and verification. We have been in dire need of >4GB boxes, and until just recently, we had been forced to run on Solaris machine to get 8GB.

    The day of the Opteron, however, has come at last:
    All these were run with stock tools in 32-bit mode, no fancy compiler optimizations. These are the same programs that we run on 2GHz P4s.

    Agilent 3

  • Fair comparison? (Score:2, Insightful)

    by illumina+us ( 615188 )
    This is comparing Intel's latest chip to a very old Opteron.

    First of all, AMD's Opteron 150 is the highest performing AMD workstation CPU money can buy
    What about the AMD Opteron 850?

    • Re:Fair comparison? (Score:3, Informative)

      by Lucretian ( 136335 ) *
      The way the opteron numbering system works is the first number is the amount of CPUs you can run SMP. The 150 is the fastest single CPU you can buy right now, the 850 is running at same clock rate as the 150 but can run in an 8way opteron system (if the boards ever become available). Right now you'd mainly find the 850s in a 4way system. The 850 would definitely be the most expensive opteron, but as a single chip would perform the same as the 150.

Slashdot Top Deals

God help those who do not help themselves. -- Wilson Mizner

Close