SPEC - MT Performance (16xlarge 64vCPU)

While the core scaling figures are interesting from an academical standpoint, what’s even more interesting is seeing the absolute throughput numbers compared to the competition. We’re starting off with SPECrate results with 64-rate runs, fully utilising the vCPUs of the EC2 16xlarge instances.

Again, there’s the conundrum of the apples-and-oranges comparison between the Graviton2’s 64 physical cores versus the 32 cores plus SMT setups of the AMD and Intel platforms, but again, that’s how Amazon is positioning these systems in terms of throughput capacity and instance pricing. You could argue that if you can parallelise your workload above a certain amount of threads, it doesn’t matter on whether you can achieve the higher throughput through more cores or through mechanisms such as SMT. Remember, when talking about silicon die area, you could at minimum probably fit 2 N1 cores in the same area than an AMD Zen core or an Intel core (probably an even higher number in the latter comparison).

SPECint2006 Rate Estimated Scores (64 vCPU)

The Graviton2’s performance is absolutely impressive across the board, beating the Intel Cascade Lake system by quite larger margins in a lot of the workloads. AMD’s Epyc system here doesn’t fare well at all and is showing its age.

SPECfp2006(C/C++) Rate Estimated Scores (64 vCPU)

It’s particularly in the non-memory bound workloads that the Graviton2 manages to position itself significantly ahead, and here the advantage of having a two-fold physical core lead with essentially double the execution resources shows its benefits.

SPEC2006 Rate-64 Estimated Total (16xlarge)

In the overall SPECrate2006 results, the Graviton2 is shy of Arm’s projection of a 1300 score, but again the Amazon chip does clock in a bit lower and has less cache than what Arm had envisioned in their presentations a year ago.

Nevertheless, the Graviton2 has the performance lead here even against the Intel Cascade Lake based EC2 instances, which is quite surprising given the latter’s cost structure, and indicator of what to come later in the cost analysis.

SPECint2017 Rate Estimated Scores (64 vCPU)

Arm’s physical core count advantage here continues to show in the execution intensive workloads of SPECint2017, showcasing some very large performance leads in many workloads. The performance leap on important workloads such as 502.gcc again isn’t too great over the Intel system for example – Amazon and Arm definitely could do better here if the chip would have had more cache available.

SPECfp2017 Rate Estimated Scores (64 vCPU) (copy)

In SPECfp2017, there’s more workloads in which the Xeon system’s 2-socket setup with a 50% memory channel advantage does show up, able to result in more available bandwidth and thus give the more memory intensive workloads in this suite a good performance advantage over the Graviton2 system. Still, the Arm chip fares very competitively and does put the older AMD EPYC processor in its place, and yes again, we have to remind ourselves that things would be quite different here if we’d be able to include Rome in our charts.

SPEC2017 Rate-64 Estimated Total (16xlarge)

Overall, the Graviton2 system has an undisputed lead in the SPECint2017 suite, whilst just edging out on average the Xeon system in the FP suite, only losing out in situations where the Xeon’s higher memory bandwidth comes at play.

SPEC - Multi-Core Performance Scaling SPEC - MT Performance (4xlarge 16 vCPU)
Comments Locked

96 Comments

View All Comments

  • anonomouse - Tuesday, March 10, 2020 - link

    Will there be more articles on this, covering other workloads than SPEC? You see lots of academic and industry papers talking about how real cloud/hyperscaler/server workloads have deep software stacks with large instruction-side footprints and static branch footprints, whereas SPEC is really... not that. Those workloads tend to have lower IPC on all platforms, and it would be interesting to see how Graviton2 performs on those from the instruction-supply side of things (1 core) as well as how I-side bandwidth scales horizontally with thread counts given the coherent I-Cache.
  • Andrei Frumusanu - Tuesday, March 10, 2020 - link

    Concrete suggestions in terms of workloads too look at and can be reasonably deployed are welcome- we currently don't have a well defined test suite for such things.
  • FunBunny2 - Tuesday, March 10, 2020 - link

    "Concrete suggestions in terms of workloads"

    OLTP on RDBMS?? real one, of course, not MySql. :)
  • Andrei Frumusanu - Tuesday, March 10, 2020 - link

    I mean an actual concrete example of such a structured benchmark, me going around doing random DB operations just opens up more criticism on why we didn't use test framework XYZ.
  • FunBunny2 - Tuesday, March 10, 2020 - link

    here's one: https://hammerdb.com/ don't know, perhaps likely, that you can get the source and compile for any db/OS of interest. didn't say it was simple. :)
  • Andrei Frumusanu - Wednesday, March 11, 2020 - link

    It's just I'm hearing a lot of "we want something specific" without actually specifying anything, me doing some random workload myself that isn't validated in terms of characterisation isn't in my view any better than the well understood nature of SPEC.
  • anonomouse - Wednesday, March 11, 2020 - link

    Have you looked at the benchmarks in GCP PerfKitBenchmarker (https://github.com/GoogleCloudPlatform/PerfKitBenc... It includes benchmark versions of various popular benchmarks including variants of ycsb on different databases, oltp, cloudsuite, hadoop, and a bunch of wrapper infrastructure around running the tests on cloud providers.
  • anonomouse - Wednesday, March 11, 2020 - link

    Okay so maybe the comment system doesn't have well with links:

    https://github.com/GoogleCloudPlatform/PerfKitBenc...
    http://googlecloudplatform.github.io/PerfKitBenchm...
  • yeeeeman - Tuesday, March 10, 2020 - link

    Ok, now imagine this chip with apple custom cores. Even Zen wouldn't stand a chance.
  • HStewart - Tuesday, March 10, 2020 - link

    You can't truly say that. Keep in mind both Apple and Amazon are aim at there own custom environments - things are like different in real world.

Log in

Don't have an account? Sign up now