Forgot your password?
typodupeerror
Intel AMD Hardware

Facebook VP Slams Intel's, AMD's Chip Performance Claims 370

Posted by timothy
from the more-than-half-of-you-less-than-half-as-well-as-you-deserve dept.
narramissic writes "In an interview on stage at GigaOm's Structure conference in San Francisco on Thursday, Jonathan Heiliger, Facebook's VP of technical operations, told Om Malik that the latest generations of server processors from Intel and AMD don't deliver the performance gains that 'they're touting in the press.' 'And we're, literally in real time right now, trying to figure out why that is,' Heiliger said. He also had some harsh words for server makers: 'You guys don't get it,' Heiliger said. 'To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient.' Heiliger added that Google has done a great job designing and building its own servers for this kind of use."
This discussion has been archived. No new comments can be posted.

Facebook VP Slams Intel's, AMD's Chip Performance Claims

Comments Filter:
  • by eldavojohn (898314) * <eldavojohnNO@SPAMgmail.com> on Thursday June 25, 2009 @11:24PM (#28476905) Journal
    So let me get this straight, the Vice President of a web company is criticizing the hardware guys in two of the world's biggest chip makers?

    You guys don't get it

    Is it possible to take out a massive life insurance policy on Jonathan Heiliger?

    To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient.

    I assure you, despite your misconception that the world revolves around you everyone has those requirements. From the people who build supercomputers right down to the netbook I am typing on while watching Gurren Lagann.

    Can we get like a panel of hardware engineers to have a discussion with this guy and can I get some popcorn?

    • by Daengbo (523424) <daengbo@nOspam.gmail.com> on Thursday June 25, 2009 @11:34PM (#28476999) Homepage Journal

      Can we get like a panel of hardware engineers to have a discussion with this guy and can I get some popcorn?

      Slashdotters might want to take a look at the details of the Google servers [cnet.com] to see what Heiliger is looking for. There's also a video tour. [youtube.com]

    • Re: (Score:3, Insightful)

      by Frosty Piss (770223)
      You've basically agreed with him. Whats your bitch? I don't get it.
    • Re: (Score:3, Insightful)

      Yes, this reads like "Guy with huge ego upset that engineers can't use magic to conjure up ideal device at his command." to me.
    • Re: (Score:3, Insightful)

      by rgviza (1303161)

      that guy is an ass.

      the latest generations of server processors from Intel and AMD don't deliver the performance gains that 'they're touting in the press

      then

      Google has done a great job designing and building its own servers for this kind of use

      I wonder who makes the server processors for Google's servers. Hmmm.....

    • Re: (Score:3, Insightful)

      by DragonWriter (970822)

      So let me get this straight, the Vice President of a web company is criticizing the hardware guys in two of the world's biggest chip makers?

      Wrong.

      He is criticizing, in the bits in TFS, two groups:
      1) The marketing guys in two of the world's biggest chip makers (he's not complaining that the chips are flawed from an engineering perspective, he is complaining about the claims, which apparently conflict with Facebooks experience in testing them chips, about the performance of the chips), and
      2) The people settin

  • Hm... (Score:4, Insightful)

    by Darkness404 (1287218) on Thursday June 25, 2009 @11:28PM (#28476941)

    To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient.

    Hm, lets see... perhaps because Facebook and Amazon are niche markets? The average server isn't going to even need all the computing horsepower and the power efficiency is simply a drop in the bucket for most companies electrical bills. The average server is going to be much more I/O intensive than CPU intensive unless you do cluster computing or render a lot of stuff. The average server such as a web server or a file server doesn't use that much CPU and usually you are running 1-3 servers, not the hundreds that Facebook or Amazon would run.

    And really, why is a VP complaining about this stuff? That he can't either afford custom solutions or spend the money buying more servers?

    • Re: (Score:3, Informative)

      by Quothz (683368)

      Hm, lets see... perhaps because Facebook and Amazon are niche markets?

      -Maybe-. Even if they are a niche market, they're a big enough one to hold the attention of the big chipmakers.

      A traditional business model might use large orders, especially advance orders, to offset or defray the cost of setting up a production line or facility, and get most of the profit from smaller sales. Or they may choose only to do production runs for large, inherently profitable orders. Even in a firing-from-the-hip model, large customers cost less per unit in marketing and sales than do smaller

    • by vux984 (928602)

      That he can't either afford custom solutions or spend the money buying more servers?

      Tell me again what Facebook's revenue model is...??

    • Re:Hm... (Score:5, Informative)

      by HockeyPuck (141947) on Friday June 26, 2009 @12:25AM (#28477411)

      The average server is going to be much more I/O intensive than CPU intensive unless you do cluster computing or render a lot of stuff.

      As someone who designs and deploys large storage environments for a living, I call BS. While the current generation of HBAs are 8Gb FibreChannel, I would say that the "average server" (as you put it) could happily live on a 1Gb HBA. Recall that almost all servers, or atleast those you care about, have DUAL HBA connections to their respective storage. So that's actually 2Gb of storage connectivity. Sure there are servers which have multiple HBAs, or use a higher utilization of the HBAs, such as database servers or backup/media servers. Most servers today are deployed with dual 4Gb HBAs as the 8Gb SFPs/optics are still quite pricey, and you cannot, in all seriousness, purchase 1 or 2Gb FC HBAs.

      Even as we deploy VMware based servers, the VMware servers themselves tend to be more memory/cpu strapped than IO.

      It would be very rare, or almost impossible for a server to be driving linerate HBAs, with still plenty of headroom left in the CPU. Even basic test tools like IOmeter require significant CPU usage to drive an HBA to capacity. And that is when it's writing/reading all zeros. It's doesn't actually need to do anything with the data. As would be the case if a database server was requesting 2Gb/s from a disk array, and then had to join/sort/add/whatever the tables retrieved.

       

      • Re: (Score:3, Informative)

        by drsmithy (35869)

        As someone who designs and deploys large storage environments for a living,

        Then you should know that throughput is not the only (or - typically - the most important) measure of IO performance.

        Typical computing tasks tend to be I/O bound - specifically by random I/O performance. To a large degree, this is due to the massive disparity in performance improvements between CPUa and storage.

    • they may be "niche" but data centers are the top multiple unit customers, buying thousands of the exact same configurations from OEMS .... they've surpassed the "enterprise cube farm" desktops buy a good margin in that data centers buy the MOST expensive server CPU they can where Enterprises are buying the cheapest desktops they can... Data center customers and Gamers are the only ones that NEED new CPUS every six months... nobody else really cares as they're out buying no-profit Atom based netbooks now.

  • by jsimon12 (207119) <tzzhc4NO@SPAMyahoo.com> on Thursday June 25, 2009 @11:31PM (#28476965) Homepage

    I have heard from some reliable sources that Facebook and Twitter's backend applications are poorly written.

    Are Intel and AMD's claims overblown, sure what hardware manufacter doesn't cherry pick performance claims.

    But I don't care what sort of hardware you through at crap code you are always going to get crap performance.

    • Re: (Score:3, Insightful)

      Crap code on faster computer is still going to be faster than it was on a slower computer. He's not saying anything about how efficient their software is, just that buying new processors didn't get him the performance delta that it was supposed to. More advanced hardware should deliver a performance benefit no matter what is running on it.
      • Re: (Score:3, Insightful)

        More advanced hardware should deliver a performance benefit no matter what is running on it.

        Not if your code is not tuned for this new "advanced hardware". Surely there are new compile flags to consider, and if you are not tuning your code for the new processor features it could very well be slower than before.

    • by evanbd (210358) on Thursday June 25, 2009 @11:53PM (#28477167)

      Developers have been known to trade off performance for development ease. Frequently the result is crap code. Yes, it performs like crap on both sets of processors. But if the application is CPU-limited (rather than IO or memory or...), then throwing faster CPUs at it ought to make it proportionally faster, no? Obviously they thought the previous performance was acceptable, is it unreasonable to think that buying CPUs marketed as 50% faster should give a 50% performance increase? Clearly crap code will still run like crap, but you ought to be able to throw more CPU power at it and get 150% of crap performance.

      • Not necessarily, no.

        It's all about how CPU limited the workload is.

        You might be running a program that's CPU limited on one processor, then upgrade the processor and discover that it's suddenly discover that instead of being CPU-bound, now you're memory-bound. Or I/O bound. Or whatever.

        Point is, just because you've hit the wall in terms of CPU doesn't mean you'll get a 50% improvement with a 50% increase in CPU ... you'll only get that if all the rest of the server's systems have 50% overhead to spare. An

        • by evanbd (210358)

          Well, more generally, you have to apply Amdahl's law. Most complicated programs operate in a realm where there aren't well defined bottlenecks, and you can get more performance through more computer power, more memory, faster memory, faster disks, faster networking...

          The point I was trying to make is that if you have crap code, and throw more compute power at it, it's unreasonable to expect it to perform like it isn't crap code -- but probably entirely reasonable to expect faster crap code.

      • Re: (Score:3, Insightful)

        by gbjbaanb (229885)

        throwing proportionally faster CPUs at *good* code should make it proportionally faster.

        Crap code.... probably not. For example, I once had to improve the performance of an app. The app spent most of its time context switching from one thread to another, more time was taken up stopping a thread, switching to another, refilling the cache lines, and so on that was spent processing the data! Think what a faster processor would do here - the CPU would process the little bit of data it was given faster thus prov

    • by Necroman (61604) on Friday June 26, 2009 @12:14AM (#28477337)

      One of the server techs from Twitter was at SXSW 2 years and gave some details about how their backend servers worked. If I remember correctly (there were 4 sites on the panel, so I may be confusing them with someone else), the original code was written in Ruby on Rails which did not scale well to the multi-server systems that they had setup. They have spent a lot of time improving their code over the years, but from what I could tell, their initial implementation wasn't the most thought out thing in the world.

    • by Stormie (708) on Friday June 26, 2009 @01:26AM (#28477819) Homepage

      I have heard from some reliable sources that Facebook and Twitter's backend applications are poorly written.

      Given the quality of Facebook's developer API (it's horrible), I'd be amazed if the back-end of the actual site wasn't poorly written.

  • by cptnapalm (120276) on Thursday June 25, 2009 @11:31PM (#28476967)

    Well, I suppose that if he does not like the offerings from Intel and AMD, they could always go with...

    Uh..

    Oh.

    • Re:Well I suppose... (Score:5, Informative)

      by the linux geek (799780) on Thursday June 25, 2009 @11:39PM (#28477041)
      Let's see... IBM, Sun, Fujitsu, Itanium (yeah, its still Intel, but has great performance)... All of these can offer equivalent or much better performance at these kinds of applications than what they're using. Don't bitch if you're not willing to consider the alternatives.
      • Re:Well I suppose... (Score:4, Interesting)

        by Trixter (9555) on Friday June 26, 2009 @12:22AM (#28477393) Homepage

        I was just going to say that. If Facebook et al are not looking at the Sun coolthreads servers, they're idiots. A T5240 would deliver a whopping 128 hardware threads per 1u of rackspace.

      • None of these offer much better performance. None. Please find me a general purpose (even niche) processor with higher performance than a high end Xeon across a variety of loads. Power? Nope. Anything from Sun? Nope. When Nehalem comes out it will not be possible to buy a general purpose CPU for anything up to 8 sockets (64 cores).
        • I meant when Nehalem-EX comes out - Nehalem is of course out.
        • Re: (Score:2, Informative)

          by fishbowl (7759)

          >None of these offer much better performance. None.

          There are IBM and Sun systems that are in an entirely different league, in terms of IO and memory bandwidth, than any Intel- or AMD-flavored system.

    • Sun.... (Score:3, Insightful)

      by Fallen Kell (165468)
      Its the next logical solution... Those T5440 servers with 256 processing threads are MONSTERS in terms of handling simultaneous connections which make them very good web servers, database servers, and file servers, all of which means they are very good for a company who's product is a website.
    • Re: (Score:3, Informative)

      by kzieli (1355557)
      There's actually 2 seperate points here
      1. the latest CPU's don't seem to be any better in practice then the previous model.
      2. Server OEM's are not delivering power efficient servers.

      the two points are somewhat independent of each other. The second I suspect is due to their being a lack of any standard for power efficent servers. Google did it by running single voltage power supplies. A standard around something like this would be useful, and not just for servers I suspect.

    • by sznupi (719324)

      I wonder when we'll see servers with CPUs based on (many...) ARM cores.

      Yes, they are an order of magnitude slower, but three orders of magnitude more power efficient. For the same CPU performance you'd probably be around two orders of magnitude more power efficient (for CPUs at least). If your app runs on a large farm already...

  • "...To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient..."

    Sounds like ARM processors are being described here. Whether they can deliver is another subject in itself. On this front, I have my doubts on ARM's ability to deliver. That's my bias.

    • As the AC noted, ARM's are available, cheap and power efficient. What they are not, however, is very powerful.

      They have their uses, but interpreting large amounts of crappy scripts is not one of ARM's strong points.

      • by sznupi (719324)

        However, aren't ARMs so cheap (also in production, transistor-wise) and power efficient that you can throw 10 times as many at the problem (hey, seems you're operating a farm already) and still decisively win on price and power?

  • by joeflies (529536) on Thursday June 25, 2009 @11:33PM (#28476989)

    1) Facebook & Amazon need cheap, power efficient systems
    2) Intel and AMD aren't measuring up with processors to power these systems
    3) However, Google has systems appropriate for this use (presumably using Intel or AMD processors)

    If that's his argument, then it would seem that the real conclusion is that Facebook can't build systems as good as Google's, even though they are using the same processor technology.

    • Re: (Score:2, Insightful)

      by joeflies (529536)

      In addition, there seems to be something else wrong with his arguement

      "To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap"

      Which he later follows up with the following insight

      "There's a pretty simple answer for scaling infrastructure. It's, 'Don't be cheap,'"

      so which one is it?

      • Re: (Score:2, Informative)

        Server Cheapness != Data Center Cheapness
      • by Gazzonyx (982402)
        I'd assume that the context of 'cheap' is different in both instances. On one hand, you want cheap per unit servers; OTOH, you want to buy many cheap units to be able to scale.
        Of course, that's just my interpretation...
      • Both. Stupid people oversimplify. In this case, he did not mean cheap. He meant... damn, there is no English word for "preiswert". Essentially it is, when you get a good value for your money.
        He meant that you should buy much (don't be cheap) with little money (the servers have to be cheap).

        Of course, with that level of differentiation of thoughts, it's no wonder that he got problems. ^^

    • by Chuck Chunder (21021) on Friday June 26, 2009 @01:07AM (#28477675) Homepage Journal

      If that's his argument, then it would seem that the real conclusion is that Facebook can't build systems as good as Google's

      Google's core business is intelligence.
      Facebooks core business is stupidity.

    • Re: (Score:3, Insightful)

      by Trepidity (597)

      If that's his argument, then it would seem that the real conclusion is that Facebook can't build systems as good as Google's, even though they are using the same processor technology.

      Google does have approximately 30x as many employees as Facebook, so it's not implausible that they've got a much greater ability to build in-house custom tech.

  • PHP (Score:3, Interesting)

    by Anonymous Coward on Thursday June 25, 2009 @11:35PM (#28477011)

    And we're, literally in real time right now, trying to figure out why that is,' Heiliger said.

    It's because your shitty website doesn't have a single line of compiled code. PHP only goes so far.

    • Re:PHP (Score:5, Interesting)

      by afidel (530433) on Thursday June 25, 2009 @11:51PM (#28477151)
      Yeah, this. Most of us don't have too much trouble wringing performance out of x64 processors when we need to. He wants a miracle of hardware he can throw at poor code which is NOT what Google asks for. Google simply want to wring every last flop/dollar (TCO) out of their systems which is slightly more than most of us need (the cost of engineering Google type solutions is more than 99.9+% of shops could reap through improved efficiency).
    • Re: (Score:3, Insightful)

      by MightyMartian (840721)

      Exactly. All these interpreted languages, even with some special tricks, will have serious scalability issues. At some point you have to look at the application and ask some serious questions.

      • Exactly. They should start small. Focus on performance profiling, find the most expensive parts of their code and reimplement those in a compiled language.

        If they're using Zend and still can't get the performance they need, they just need to accept that PHP's flexibility and rapid development friendliness come at a price-runtime speed.

    • PHP "extension" (Score:5, Insightful)

      by RGRistroph (86936) <rgristroph@gmail.com> on Friday June 26, 2009 @03:41AM (#28478723) Homepage

      I once did a large project in which I took a large, slow site in PHP (it was pretty complecated, it was a CRM with a lot of custom business logic) and rewrote all the core functionality from PHP to C / C++, and made it a "module" of PHP. The rewriting was mostly simple translation -- litterally removing all dollar signs, adding some types, and attempting to compile, and just fixing the compile errors until it would build. Then going back through it with a fine-tooth comb to track down all the memory leaks.

      The speed increase from doing that is pretty surprising. Simple loops that do a bit of math or something speed up by 100 times, and a loop that creates and destroys an object within the loop will be 100,000 times faster. This is without actually trying to write fast C/C++ code, and not create and delete the same thing over and over in a loop -- just pure dumb translation of the code.

      At that point, the web site guys can keep tweaking and changing the web page in PHP just like before; but they load that module in the php.ini and then they have a basic library of stuff, like login_user() or get_user_balance() and etc, that are really fast and do all the heavy lifting.

      I would be surprised if Facebook has not already done this. How to do it is well documented in several books, and there are lots of PHP modules written in C/C++ to look at for examples.

      I suspect that Facebook's VP is right that AMD and Intel exaggerate their claims, but is also generally true that most computer programs are more IO bound that you expect. This is not a reason to avoid something like I describe above; once you have the more complete control of programming in C, IO issues may be easier to find and address.

      He also mentions that the servers offered by Dell and others aren't very power efficient or practicle for him, and he mentions Google designing their own servers. Nothing google did was really rocket science, from what we know, and Facebook probably doesn't have to go as far as they did to get a reasonable benefit. It's not that hard to set up motherboards to run without a case, booting off the network with no harddrive attached.

  • Honestly, I think that his arguments fall flat. Though I like FB as much as anybody, and I feel for someone dealing with massive performance needs - I only have a paltry 30 servers running my main application - I wonder if he's being realistic.

    There's a pretty simple answer for scaling infrastructure. It's, 'Don't be cheap,'" Heiliger said. He added that Facebook does drive hard bargains with its hardware and software infrastructure suppliers, and is careful not to overbuy.

    I remember reading about how

  • by stox (131684) on Thursday June 25, 2009 @11:47PM (#28477115) Homepage

    Assuming that a solution was properly engineered, this should not have been a surprise.

    Cheap. power efficient, performance. Pick two.

    • Re: (Score:3, Interesting)

      by rossifer (581396)

      Assuming that a solution was properly engineered, this should not have been a surprise.

      Cheap. power efficient, performance. Pick two.

      Actually, Google got all three of those in their system-level design (when cheap is measured per CPU). What they didn't get was per CPU reliability. That's pretty miserable by the standards of commercial servers. Luckily, all Google software is architected, designed, and written to work around frequent hardware failures, so that's ultimately covered.

  • by 1sockchuck (826398) on Thursday June 25, 2009 @11:56PM (#28477189) Homepage
    This is becoming an annual event for Heiliger, who also complained about server vendors [datacenterknowledge.com] at GigaOm's Structure 08 conference last year. Facebook used to buy a lot of cloud-optimized gear from Rackable/SGI, but no longer appears on the list of their largest customers. Makes you wonder if they're not going to follow Google's lead and build their own servers.
  • He woke up on the wrong side of the bed, and then he had to sign the check for the electric bill.

    He's just grumpy.

  • by SeaFox (739806) on Friday June 26, 2009 @12:12AM (#28477305)

    'You guys don't get it,' Heiliger said. 'To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient.'

    NEWSFLASH! Customer are tightwads.

    Performance/Reliability/Price.

    Pick any two, Heiliger.

  • by Klintus Fang (988910) on Friday June 26, 2009 @12:31AM (#28477451)

    I'm bemused that he implies the problems with his servers are due to Intel and AMD no delivering with their chips, yet at the same time he admires google for how good a job they do in building out their machines.

    he must be aware that google uses Intel and AMD chips.

    his reasoning just doesn't square.

  • And yet... (Score:5, Interesting)

    by Junta (36770) on Friday June 26, 2009 @12:37AM (#28477487)

    Every major server vendor has jumped on the bandwagon of 'look how efficient we are, and 'cheap'. Three years ago, by and large the tier ones wouldn't bother designing systems without forcing even the cheap design to have parts included to facilitate purchase of redundant add-ons (i.e. power distribution cards designed for dual power supplies regardless of one being bought or not). They would always put a high end storage controller on the planar. They would always make their 'entry' platform be burdened with expensive components to make it easier to option it up.

    Now, we have tons of 'internet scale', or 'cloud', or whatever buzzword you feel like. They tend to stress energy efficiency, low cost components, with sales and management strategies targeted at thousands of servers (i.e. IBM iDataplex, HP SL6000). Basically, precisely what he prescribes, though probably not as 'cheap' as he wants. The incentive he gives is that the vendors should have zero margin, which is not particularly compelling for companies to work toward. Google's situation works because they brought it in-house and thus have fewer middle-men. Honestly, from all the rumours I hear, it's the logical thing to do when your server consumption is larger than some respectable computer companies' entire production. If he thinks the volume of servers is high enough to pull a google, by all means do it. Otherwise, be prepared for people not jump at the chance to give their designs to him at zero margin.

    Of course, if he is calling them out on performance per-watt by avoiding non-x86 solutions, including ARM, that might be a fair criticism. However, I think company forays into 'exotic' architectures have not panned out in the market recently. Sun's niagra, despite all the worthy praise, couldn't attract a mass-market required to subsidize it for those who benefited most from it. Last year, IBM seemed to be saying Cell architecture would light the world on fire, but have been a lot quieter about it now. The message their buisness leaders have probably taken in is that while these things have their target market, that market isn't worth the expense of developing products that are refused by the larger market and focus instead on leveraging commonly accepted building blocks to do as best they can for that niche, even if it means skipping the 'perfect' solution. Sure, IBM still sells plenty of POWER, but I haven't heard that be *particularly* praised on the performance/watt category like I hear a lot for Niagra, Cell, and ARM. And if not for POWER's legacy, it probably would be still born in the market today. The PA-RISC->Itanium decision for HP probably sank their HP-UX product line faster than banking on legacy of PA-RISC installs, and it seems IBM won't make that mistake, but at the same time I don't hear much about *new* POWER customers.

  • Strange... (Score:5, Informative)

    by spire3661 (1038968) on Friday June 26, 2009 @12:55AM (#28477581) Journal

    Since when do we listen to manufacturer's claims? You take the new hardware, stress test it with your custom software, record results, plan servers accordingly. How hard is it really to commission a server design that meets your needs and then QA some prototypes?

    • by edmudama (155475)

      Mod the above up.

      Intel, AMD, Sun, HP, Dell, IBM, whoever. They all provide a wide range of configurable, scalable, inexpensive (to expensive) building blocks to get your business need accomplished. With all the amazing things that have been created using computers in the last thirty or forty years, I can't blame the providers of those building blocks for something not coming together. The latest chips are absolutely faster than previous ones, but maybe you need to rethink your network fabric? Maybe your

  • by OneSmartFellow (716217) on Friday June 26, 2009 @02:08AM (#28478081)
    ...I'm supposed to care about the comments of the guy who wrote Facebook ?

    Hah, hah, hah, hah, hah !At least google needed to actually engineer their solution, but Facebook, come on ! The next time I need to write a PHP script for displaying photos and text, I'll hire my 13 year old daughter.
  • by unix_geek_512 (810627) on Friday June 26, 2009 @03:36AM (#28478671)

    This isn't just about the CPU, it's about overall system performance.

    Despite improvements in CPU performance, memory and IO performance is lagging behind.

    A modern SATA drive delivers about 90MB/sec ( peak sequential read ).

    Some RAID controllers can do about 600-800MB/sec ( peak sequential read ).

    An average AM2 ( K10 core 65nm ) gets about 34,849MB/sec L1, 12,169MB/sec L2, 6371MB/sec L3, 2,741MB/sec DDR2-800 5-5-5-12.

    Obviously Opterons scale a lot better since they each have an onboard memory controller and additional HT links which greatly increases bandwidth as you add more CPUs. However adding more cores on the same die which have to share a single memory controller can cause starvation.

    Another major issue is software parallelization, writing parallel code is still a difficult problem. If your software doesn't parallelize well it doesn't matter if you have 8, 16 or even 32cores on a single die.

    If you had an equal number of CPU cores and memory controllers you could achieve much better performance, however your relatively very slow storage subsystems would still be a major bottleneck.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde

Working...