5 ms·

Comparing Graviton (ARM) Performance to Intel and AMD for MySQL

25 points by ArdelleF 4y ago

doctor_eval 4y ago
(2021)
rjzzleep 4y ago
From the comments, the AMD Epycs used for comparison were an older generation.
- gpderetta 4y ago
  follow up here: https://www.percona.com/blog/comparing-graviton-arm-performance-to-intel-and-amd-for-mysql-part-3/ https://www.percona.com/blog/comparing-graviton-arm-performa...
  - rjzzleep 4y ago
    Which completely changes the picture. The conclusion is completely wrong. The only reason AMD loses in the comparison is because their comparisons measure who's the best and then count how many times it's the best. If you look at the top graphs of this 2022 comparison, then there are plenty cases where AMD is in the middle, but doesn't take the top spot. Also since this comparison is newer, maybe it should replace the link in the topic.
neonsunset 4y ago
There is no details on which CPUs (graviton or graviton 2, what about amd?) were exactly used making the review useless to the vast majority of audience.
- pizza234 4y ago
  The article specifies that the instance classes are `m6g`, in the variants `large` all the way up to `16xlarge`. According to the AWS documentation (here¹ and here²), they are Graviton2. AWS is opaque about the underlying hardware underlying an RDS instance; there may be no way to find out exactly which are the CPU models (although I'm not 100% sure). The writer may have cleared the waters upfront about this, but this is a limit of AWS. ¹: https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/C... ²: https://aws.amazon.com/ec2/instance-types/m6g https://aws.amazon.com/ec2/instance-types/m6g
ArdelleF 4y ago
Another comparison maybe interesting too Comparing ARM based K8s to x86 based for TiDB (a distributed database) https://en.pingcap.com/blog/tidb-on-arm-based-k8s-cluster-achieves-up-to-25-percent-better-price-performance-ratio-than-x86/ https://en.pingcap.com/blog/tidb-on-arm-based-k8s-cluster-ac...
wwkeyboard 4y ago
Amazon is pretty clear that Gravatron is an actual core, while the others are hyper-threads[1]. It makes sense that at higher vcpu counts you're likely to run into contention with neighbors, or even yourself. [1] https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/optimizing-for-performance.html https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2...
- electroly 4y ago
  I believe AWS always gives you both hyperthreads on a physical core, you never share a core with another customer. That's why hyperthreaded instance types always have an even number of vCPUs rather than starting at 1 vCPU. Source: trust me bro, I can't find the relevant AWS doc.
  - wwkeyboard 4y ago
    From the 2nd paragraph of the link I posted: One of the major differences between AWS Graviton2 instance types and other instance types is their vCPU to physical processor core mapping. Every vCPU on a Graviton2 processor is a physical core. This means there is no Simultaneous Multi-Threading (SMT) and more isolation between vCPUs. By contrast, every vCPU on a 5th generation instance type with Intel processor (such as M5, C5, and R5) is a hyper-thread. This means vCPUs share resources and there is less isolation than in the case of Graviton2.
    - electroly 4y ago
      What I mean is that you're always sharing resources with yourself, not another customer. They're assigning you both hyperthreads on a single core when you get an instance with "2" vCPUs; it's not one hyperthread on one core and the other hyperthread on another core, with some other customer taking the other hyperthread on each core.

25 points by ArdelleF 4y ago

doctor_eval 4y ago

(2021)

rjzzleep 4y ago

From the comments, the AMD Epycs used for comparison were an older generation.

gpderetta 4y ago
follow up here: https://www.percona.com/blog/comparing-graviton-arm-performance-to-intel-and-amd-for-mysql-part-3/ https://www.percona.com/blog/comparing-graviton-arm-performa...
- rjzzleep 4y ago
  Which completely changes the picture. The conclusion is completely wrong. The only reason AMD loses in the comparison is because their comparisons measure who's the best and then count how many times it's the best. If you look at the top graphs of this 2022 comparison, then there are plenty cases where AMD is in the middle, but doesn't take the top spot. Also since this comparison is newer, maybe it should replace the link in the topic.

neonsunset 4y ago

There is no details on which CPUs (graviton or graviton 2, what about amd?) were exactly used making the review useless to the vast majority of audience.

pizza234 4y ago
The article specifies that the instance classes are `m6g`, in the variants `large` all the way up to `16xlarge`. According to the AWS documentation (here¹ and here²), they are Graviton2. AWS is opaque about the underlying hardware underlying an RDS instance; there may be no way to find out exactly which are the CPU models (although I'm not 100% sure). The writer may have cleared the waters upfront about this, but this is a limit of AWS. ¹: https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/C... ²: https://aws.amazon.com/ec2/instance-types/m6g https://aws.amazon.com/ec2/instance-types/m6g

ArdelleF 4y ago

Another comparison maybe interesting too Comparing ARM based K8s to x86 based for TiDB (a distributed database) https://en.pingcap.com/blog/tidb-on-arm-based-k8s-cluster-achieves-up-to-25-percent-better-price-performance-ratio-than-x86/ https://en.pingcap.com/blog/tidb-on-arm-based-k8s-cluster-ac...

wwkeyboard 4y ago

Amazon is pretty clear that Gravatron is an actual core, while the others are hyper-threads[1]. It makes sense that at higher vcpu counts you're likely to run into contention with neighbors, or even yourself. [1] https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/optimizing-for-performance.html https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2...

electroly 4y ago
I believe AWS always gives you both hyperthreads on a physical core, you never share a core with another customer. That's why hyperthreaded instance types always have an even number of vCPUs rather than starting at 1 vCPU. Source: trust me bro, I can't find the relevant AWS doc.
- wwkeyboard 4y ago
  From the 2nd paragraph of the link I posted: One of the major differences between AWS Graviton2 instance types and other instance types is their vCPU to physical processor core mapping. Every vCPU on a Graviton2 processor is a physical core. This means there is no Simultaneous Multi-Threading (SMT) and more isolation between vCPUs. By contrast, every vCPU on a 5th generation instance type with Intel processor (such as M5, C5, and R5) is a hyper-thread. This means vCPUs share resources and there is less isolation than in the case of Graviton2.
  - electroly 4y ago
    What I mean is that you're always sharing resources with yourself, not another customer. They're assigning you both hyperthreads on a single core when you get an instance with "2" vCPUs; it's not one hyperthread on one core and the other hyperthread on another core, with some other customer taking the other hyperthread on each core.