• What
    is this?
    You've landed on the AMD Portal on AnandTech. This section is sponsored by AMD. It features a collection of all of our independent AMD content, as well as Tweets & News from AMD directly. AMD will also be running a couple of huge giveaways here so check back for those.
    PRESENTED BY

Benchmark Configuration

Since AMD sent us a 1U Supermicro server, we had to resort to testing with our 1U servers again. That is why we went back to the ASUS RS700 for the Xeon server.

Supermicro A+ server 1022G-URG (1U Chassis)

CPU 2x AMD Opteron Interlagos 6276 (2.3GHz, 8 cores per CPU, 16 integer clusters)
2x AMD Opteron Interlagos 6220 (3.0GHz, 4 cores per CPU, 8 integer clusters)
2x AMD Opteron Magny-Cours 6174 (2.2GHz, 12 cores per CPU)
RAM 64GB (8x8GB) DDR3-1600 Samsung M393B1K70DH0-CK0
Motherboard SuperMicro H8DGU-F
Chipset AMD Chipset SR5670 + SP5100
BIOS version v2.81 (10/28/2011)
PSU SuperMicro PWS-704P-1R 750Watt

The AMD CPUS have four memory channels per CPU. The new Interlagos Bulldozer CPU supports DDR3-1600 and thus our dual-CPU configuration uses eight DIMMs for maximum bandwidth and performance. We ran with one DIMM per channel.

Asus RS700-E6/RS4 1U Server

CPU 2x Intel Xeon X5650 (2.66GHz, 6 cores/12 threads)
RAM 48GB (12x4GB) Kingston DDR3-1333 FB372D3D4P13C9ED1
Motherboard Asus Z8PS-D12-1U
Chipset Intel 5520
BIOS version 1102 (08/25/2011)
PSU 770W Delta Electronics DPS-770AB

To speed up testing, we ran the Intel Xeon and AMD Opteron system in parallel. As we didn't have more than eight 8GB DIMMs, we used our 4GB DDR3-1333 DIMMs for the Xeon server. The Xeon system only ends up with 48GB, but this is no disadvantage as our benchmark with the highest memory footprint (Nieuws.be/SQL Server 5 tiles) uses no more than 30GB of RAM.

We measured the difference between 12x4GB and 8x8GB of RAM and recalculated the power consumption for our power measurements (note that the differences were very small). There is no practical alternative as our Xeon has three memory channels and cannot be optimally configured with the same amount of RAM as our Opteron system (which has four channels).

We chose the Xeons based on AMD's positioning. The Xeon X5649 is priced at the same level as the Opteron 6276 but we didn't have the X5649 in the labs. As we suggested in our previous article, the Opteron 6276 should reach the performance of the X5650 to be attractive, so we tested with the X5650.

Common Storage System

Both servers used intel 710 SSDs for storing the database.

Software configuration

All Windows testing was done on Windows 2008 R2 SP1. The Linux tests are done on Ubuntu 11.10 Linux kernel 3.0.0-14 SMP x86_64.

Other

Both servers were fed by a standard European 230V (16 Amps max.) powerline. The room temperature was monitored and kept at 23°C by our Airwell CRACs. We used the Racktivity ES1008 Energy Switch PDU to measure power. Using a PDU for accurate power measurements might seem pretty insane, but this is not your average PDU. Measurement circuits of most PDUs assume that the incoming AC is a perfect sine wave but it never is. However, the Rackitivity PDU measures true RMS current and voltage at a very high sample rate: up to 20,000 measurements per second for the complete PDU.

Introduction SQL Server 2008 R2 "OLAP" Workload
POST A COMMENT

46 Comments

View All Comments

  • Jaguar36 - Thursday, February 09, 2012 - link

    I too would love to see more HPC related benchmarks. Finite Element Analysis (FEA) or Computational Fluid Dynamic (CFD) programs scale very well with increased core count, and are something that is highly CPU dependent. I've found it very difficult to find good performance information for CPUs under this load.

    I'd be happy to help out developing some benchmark problems if need be.
    Reply
  • dcollins - Thursday, February 09, 2012 - link

    These would indeed be interesting benchmarks to see. These workloads are very floating point heavy so I imagine that the new Opterons will perform poorly. 16 modules won't matter when they only have 8 FPUs. Of course, I am speculating here.

    Going forward, these types of workloads should be moving toward GPUs rather than CPUs, but I understand the burden of legacy software.
    Reply
  • silverblue - Friday, February 10, 2012 - link

    They have 8 FPUs capable of 16x 128-bit or 8x 256-bit instructions per clock. On that level, it shouldn't be at a disadvantage. Reply
  • bnolsen - Sunday, February 12, 2012 - link

    GPUs are pretty poor for general purpose HPC. If someone wants to fork out tons of $$$ to hack their problem onto a gpu (or they get lucky and somehow their problem fits a gpu well) that's fine but not really smart considering how short release cycles are, etc.

    I have access to a quad socket magny cours built mid last year. In december I put together a sandy-e 3930k portable demo system. Needless to say the 3930k had at least 10% more throughput on heavy processing tasks (enabling all intel sse dropped in another 15%). It also handily beat our dual xeon nehalem development system as well. With mixed IO and cpu heavy loads the advantage dropped but was still there.

    I'd love to be able to test these new amds just to see but its been much easier telling customers to stick with intel, especially with this new amd cpu.
    Reply
  • MySchizoBuddy - Friday, March 09, 2012 - link

    "GPUs are pretty poor for general purpose HPC."
    tell that to the #2, #4 and #5 most powerful supercomputers in the world. I'm sure no one told them.
    Reply
  • hooflung - Thursday, February 09, 2012 - link

    I think I'd rather see some benchmarks based around Java EE6 and an appropriate container such as Jboss AS 7. I'd also like to see some Java 7 application benchmarks ( server oriented ).

    I'd also like to see some custom Java benchmarks using Akka library so we can see some Software transactional memory benchmarks. Possibly a node.js benchmark as well to see if these new technologies can scale.

    What I've seen here is that the enterprise circa 2006 has a love hate relationship with AMD. I'd also like to see some benchmarks of the Intel vs AMD vs SPARC T4 in both virtualized and non virtualized J2EE environments. But this article does have some really interesting data.
    Reply
  • jibberegg - Thursday, February 09, 2012 - link

    Thanks for the great and informative article! Minor typo for you...

    "Using a PDU for accurate power measurements might same pretty insane"
    should be
    "Using a PDU for accurate power measurements might seem pretty insane"
    Reply
  • phoenix_rizzen - Thursday, February 09, 2012 - link

    MySQL has to be the absolute worst possible choice for testing multi-core CPUs (as evidenced in this review). It just doesn't scale beyond 4-8 cores, depending on CPU choice and MySQL version.

    A much better choice for "alternative SQL database" would be PostgreSQL. That at least scales to 32 cores (possibly more, but I've never seen a benchmark beyond 32). Not to mention it's a much better RDBMS than MySQL.

    MySQL really is only a toy. The fact that many large websites run on top of MySQL doesn't change that fact.
    Reply
  • PixyMisa - Friday, February 10, 2012 - link

    This is a very good point. While it can be done, it's very fiddly to get MySQL to scale to many CPUs, much simpler to just shard the database and run multiple instances of MySQL. (And replication is single-threaded anyway, so if you manage to get one MySQL instance running with very high inserts/updates, you'll find replication can't keep up.)

    Same goes for MongoDB and, of course, Redis, which is single-threaded.

    We have ten large Opteron servers running CentOS 6, five 32-core and five 48-core, and all our applications are sharded and virtualised at a point where the individual nodes still have room to scale. Since our applications are too large to run un-sharded anyway, and the e7 Xeons cost an absolute fortune, the Opteron was the way to go.

    The only back-end software we've found that scales smoothly to large numbers of CPUs is written in Erlang - RabbitMQ, CouchDB, and Riak. We love RabbitMQ and use it everywhere; unfortunately, while CouchDB and Riak scale very nicely, they start out pretty darn slow.

    We actually ran a couple of 40-core e7 Xeon systems for a few months, and they had some pretty serious performance problems for certain workloads too - where the same workload worked fine on either a dual X5670 or a quad Opteron. Working out why things don't scale is often more work than just fixing them so that they do; sometimes the only practical thing to do is know what platform works for what workload, and use the right hardware for the task at hand.

    Having said all that, the MySQL results are still disappointing.
    Reply
  • JohanAnandtech - Friday, February 10, 2012 - link

    "It just doesn't scale beyond 4-8 cores, depending on CPU choice and MySQL version."

    You missed something: it does scale beyond 12 Xeon cores, and I estimate that scaling won't be bad until you go beyond 24 cores. I don't see why the current implementation of MySQL should be called a toy.

    PostgreSQL: interesting several readers have told me this too. I hope it is true, because last time we test PostgreSQL was worse than the current MySQL.
    Reply

Log in

Don't have an account? Sign up now