[vladvasiliu]

> Moved from m5.24xlarge --> m6g.8xlarge with better service performance and improved latency characteristics. Intel is in trouble in my opinion.

I wonder if this is actually an Intel issue or if there are some other optimizations at play, such as in the virtualization layer.

Because at one point I wanted to try Jetbrains' new "gateway" product, which basically runs a remote IDE and only shows the GUI locally. I was curious on one hand, but I also wanted a machine with a bit more oomph for my occasional compilation needs (rust on Linux, fwiw). I was really unimpressed, the c6i was comparable to my local slim laptop running an 11th gen i7u part. My similar slim AMD 5650U laptop is actually faster. IIRC, the c6i.metal wasn't particularly faster on this kind of single threaded work.

[di4na]

The difference is in the pricing and the fact the core are "whole"

On intel aws, you pay per HyperThread. On Graviton, you pay per core.

But on this kind of workload and with modern schedulers, HT bump is rather limited. So in practice you are paying twice the price for the same number of cores.

This is the biggest contributing factor to that difference and i keep being surprised noone mention it.

[guipsp]

Not sure what you're talking about - in aws x86 you pay by core (well as much as pay by core with arm anyways, you can't just buy a 1gb server with 64 cores)

[mattashii]

AWS x64 'cores' are the virtual cores you see on hyperthreaded CPUs and map 2:1 to physical cores on the CPU, but the AWS ARM offering doesn't have hyperthreading, so the virtual cores map 1:1 to cpu cores.

You can disable hyperthreading on the x64 instances at the cost of halving the number of cores you have available in the instance that you paid for.

[guipsp]

Yes, but this doesn't really matter - just multiply the cost by two in your accounting. Its not like you one get one core with 15 hyperthread cores