I wonder if a part of this was due to security concerns with hyperthreading, and the performance numbers were just a bonus that they decided to use as a way to promote the change.
Amazon has made sure that all current instance types always get pairs of hyperthreads on the same core, but lets you configure whether or not you actually want hyperthreading enabled based on whether you have cross-process security concerns with your particular application (and software licensing per vcpu costs, too).
I worker if Google has just decided "you know what? no more hyperthreads." rather than make it configurable, or because they didn't think people would pick the right option.
This really sounds and feels like smoke and mirrors wrapped around a price cut.
Most workloads will show higher throughput/physical core from running 2 threads at a time in SMT, and for most workloads overall throughput matters more than the time to process individual responses.
If they're winning price/perf vs an equivalent SMT system by pricing the individual cores cheaper it's the lower price getting them the win and the same cores would offer more performance if SMT was turned on.
And especially on smaller servers I'd rather have 1 or 2 physical cores with SMT on than 1 or 2 cores with SMT off because the extra threads help a lot with hiding the impact of an admin running a compute heavy report that hogs a thread for 30 seconds or several minutes from other users.
The actual value is all in Epyc sold cheap. But most customers would benefit more from a N(2N) core SMT VM than an N core non-SMT one. Offering the ability to turn SMT off for customers willing to pay a premium for low response time is a nice value add; but shouldn't be the default/primary configuration.
Are you SURE about that "most customers would benefit more from a N(2N) core SMT VM than an N core non-SMT one"? Clearly there are *some* workloads for which this is true, but the weights to associate with these (number of customers; importance they place on the workload) are far from obvious...
There ARE two data points that we know about: - anything HPC-like (so using vectors basically every cycle) gains essentially zero from SMT
- anything that's mainly moving memory around and so bandwidth limited gains essentially zero from SMT. Dick Sites, in his very interesting talk about what he (and, in a sense Google) want from future CPUs/data center SoCs makes a big deal of this, that the main thing he wants is the ability (with a duty cycle of 25%) to move 16B per cycle, assuming it's going to miss in RAM. Interestingly Apple M1 delivers this today (kinda -- ~20B/cycle, which you can either say is better than required [using only performance cores] or right on the edge [considering an E core as quarter of a performance core]), but of course Apple is not in the data warehouse space. No-one else comes close.
So point is, there are two clear use cases for these warehouse scale machines that don't benefit from SMT. Obviously there are other things that such a machine can do, and the primary win of SMT is optionality; if you can exploit that optionality by scheduling FP-heavy (but memory light) code code alongside memory heavy or int heavy code, you can have a win. But that requires your scheduler to track this info (by CPU counters I guess) and that you have an even enough pool of complementary tasks. For that you pay at least some extra gate delays and endless security issues. Is it a good tradeoff compared to other alternatives (eg use either large cores or small cores, small cores handling memory-heavy stuff; or share rarely-used vector hardware between two cores)? My guess is not; it was a bad idea that has been allowed to survive for far too long.
Of course the real difference is not in 2 cores without SMT, or 2 cores with SMT, its 2 real cores, or 2 "virtual" cores (or 1 with SMT, if you will)
Of course you could just say to buy twice as many of the virtual cores, but that is where pricing makes the big impact. And in marketing, or any third-party comparison, these real cores will always shine, and if they are priced competitively against other offerings with virtual SMT cores, who is to complain?
In fact it's other way around. Intel is running with half the cores and yet being able to nearly reach half of AMD performance. That's what's shocking. And even more is that google is comparing previous generation (Intel) with current (AMD).
Erm, there are no competitive 64C Intel parts, they are pretty much dual socket chips which makes them noncompetitive in terms of pricing. Their 32C Ice Lake clocks are only similar to the AMD 7713P (their "cheap" $k 64C/128T part) while AMD's side is a bit better in IPC.
Intel is currently not that competitive, their biggest advantage right now is lots of software they've made that is designed for their CPU's, I do hope they make a comeback sooner rather than later so AMD doesn't get complacent.
If you need more than one Intel server / socket to get that many cores then it's a relevant comparison, because the provider's costs will be tightly linked to how many servers they can fit into a given datacenter.
Phoronix just did a GCC compiler flag comparison, and found that -0fast is actually slower than -O3 in some tests. But they also experienced a regression with -flto, which doesn't seem quite right.
Anyway, AOCC is pretty cool, but I'm not sure how much faster it actually is than the LLVM build its based on. LLVM vs AOCC would be a more apples to apples comparison.
@Andrei Posting here because I don't have a twitter. It's sadly overpriced vs the US listing, but the phone stand you weren't able to find is available on amazon.de (found by searching for "Prosumer's+Choice")
I believe this move by Google also reflects the curious fact that Google, a pioneer in cloud computing and services, has managed to only play third fiddle to AWS and Microsoft's Azure. Google needs to up their game to stay competitive, and this is one of the ways to start doing so.
This content is a value bomb. I think in future physical storages are going to instinct. Cloud storages are the future. Thanks for sharing. By the way, I am here to discuss about a error resolution tool called <a href="https://opencloudmanifesto.org/quickbooks-file-doc... file doctor</a>, helps the users to resolve almost all the errors. I have shared some useful info regarding the same. Hope it helps.
This content is a value bomb. I think in the future physical storages are going to instinct. Cloud storages are the future. Thanks for sharing. By the way, I am here to discuss an error resolution tool called QuickBooks file doctor that helps the users to resolve almost all the errors. I have shared some useful info regarding the same. Hope it helps. Checkout here - https://opencloudmanifesto.org/quickbooks-file-doc...
Price will always be a factor of value. The depth of your pockets will determine what you get. Nonetheless, thank you for this piece of information https://customessayexpert.com/
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
24 Comments
Back to Article
kepstin - Thursday, June 17, 2021 - link
I wonder if a part of this was due to security concerns with hyperthreading, and the performance numbers were just a bonus that they decided to use as a way to promote the change.Amazon has made sure that all current instance types always get pairs of hyperthreads on the same core, but lets you configure whether or not you actually want hyperthreading enabled based on whether you have cross-process security concerns with your particular application (and software licensing per vcpu costs, too).
I worker if Google has just decided "you know what? no more hyperthreads." rather than make it configurable, or because they didn't think people would pick the right option.
DanNeely - Thursday, June 17, 2021 - link
This really sounds and feels like smoke and mirrors wrapped around a price cut.Most workloads will show higher throughput/physical core from running 2 threads at a time in SMT, and for most workloads overall throughput matters more than the time to process individual responses.
If they're winning price/perf vs an equivalent SMT system by pricing the individual cores cheaper it's the lower price getting them the win and the same cores would offer more performance if SMT was turned on.
And especially on smaller servers I'd rather have 1 or 2 physical cores with SMT on than 1 or 2 cores with SMT off because the extra threads help a lot with hiding the impact of an admin running a compute heavy report that hogs a thread for 30 seconds or several minutes from other users.
Andrei Frumusanu - Thursday, June 17, 2021 - link
At the end of the day the rationale doesn't matter as the price and value is competing, and that's where the huge leap lies in.DanNeely - Thursday, June 17, 2021 - link
The actual value is all in Epyc sold cheap. But most customers would benefit more from a N(2N) core SMT VM than an N core non-SMT one. Offering the ability to turn SMT off for customers willing to pay a premium for low response time is a nice value add; but shouldn't be the default/primary configuration.name99 - Thursday, June 17, 2021 - link
Are you SURE about that "most customers would benefit more from a N(2N) core SMT VM than an N core non-SMT one"?Clearly there are *some* workloads for which this is true, but the weights to associate with these (number of customers; importance they place on the workload) are far from obvious...
There ARE two data points that we know about:
- anything HPC-like (so using vectors basically every cycle) gains essentially zero from SMT
- anything that's mainly moving memory around and so bandwidth limited gains essentially zero from SMT. Dick Sites, in his very interesting talk about what he (and, in a sense Google) want from future CPUs/data center SoCs makes a big deal of this, that the main thing he wants is the ability (with a duty cycle of 25%) to move 16B per cycle, assuming it's going to miss in RAM.
Interestingly Apple M1 delivers this today (kinda -- ~20B/cycle, which you can either say is better than required [using only performance cores] or right on the edge [considering an E core as quarter of a performance core]), but of course Apple is not in the data warehouse space. No-one else comes close.
So point is, there are two clear use cases for these warehouse scale machines that don't benefit from SMT. Obviously there are other things that such a machine can do, and the primary win of SMT is optionality; if you can exploit that optionality by scheduling FP-heavy (but memory light) code code alongside memory heavy or int heavy code, you can have a win. But that requires your scheduler to track this info (by CPU counters I guess) and that you have an even enough pool of complementary tasks.
For that you pay at least some extra gate delays and endless security issues. Is it a good tradeoff compared to other alternatives (eg use either large cores or small cores, small cores handling memory-heavy stuff; or share rarely-used vector hardware between two cores)? My guess is not; it was a bad idea that has been allowed to survive for far too long.
nevcairiel - Thursday, June 17, 2021 - link
Of course the real difference is not in 2 cores without SMT, or 2 cores with SMT, its 2 real cores, or 2 "virtual" cores (or 1 with SMT, if you will)Of course you could just say to buy twice as many of the virtual cores, but that is where pricing makes the big impact. And in marketing, or any third-party comparison, these real cores will always shine, and if they are priced competitively against other offerings with virtual SMT cores, who is to complain?
yannigr2 - Thursday, June 17, 2021 - link
I don't know what is more shocking here. AMD having that much of an advantage, or Intel being so far behind.kgardas - Friday, June 18, 2021 - link
In fact it's other way around. Intel is running with half the cores and yet being able to nearly reach half of AMD performance. That's what's shocking. And even more is that google is comparing previous generation (Intel) with current (AMD).Spunjji - Friday, June 18, 2021 - link
Last I knew, Intel's current gen still isn't widely available. It seems to be roughly where Milan was back in January.RSAUser - Wednesday, June 30, 2021 - link
Erm, there are no competitive 64C Intel parts, they are pretty much dual socket chips which makes them noncompetitive in terms of pricing. Their 32C Ice Lake clocks are only similar to the AMD 7713P (their "cheap" $k 64C/128T part) while AMD's side is a bit better in IPC.Intel is currently not that competitive, their biggest advantage right now is lots of software they've made that is designed for their CPU's, I do hope they make a comeback sooner rather than later so AMD doesn't get complacent.
Kamen Rider Blade - Thursday, June 17, 2021 - link
I wonder how Intel's Server team feels that their Cascade Lake is placed @ a distant 3rd placeFunBunny2 - Thursday, June 17, 2021 - link
"Stop the steal!!""Stop the steal!!"
"Stop the steal!!"
drothgery - Thursday, June 17, 2021 - link
Seems odd to be comparing Milan vs Cascade Lake rather than Ice Lake, tbh, even if availability is still quite limited for Ice Lake - SP.kgardas - Friday, June 18, 2021 - link
Exactly! And even more odd is comparing X amd cores versus X/2 intel cores.Spunjji - Friday, June 18, 2021 - link
If you need more than one Intel server / socket to get that many cores then it's a relevant comparison, because the provider's costs will be tightly linked to how many servers they can fit into a given datacenter.Andrei Frumusanu - Friday, June 18, 2021 - link
There are no ICL-X deployments in the cloud as of yet. I have our own data in the custom chart if that helps.drexnx - Thursday, June 17, 2021 - link
I wonder if part of this uplift is enabled by the constraints of the current IO die on Milan, remove SMT, remove some pressure on IO resources?brucethemoose - Friday, June 18, 2021 - link
Phoronix just did a GCC compiler flag comparison, and found that -0fast is actually slower than -O3 in some tests. But they also experienced a regression with -flto, which doesn't seem quite right.Anyway, AOCC is pretty cool, but I'm not sure how much faster it actually is than the LLVM build its based on. LLVM vs AOCC would be a more apples to apples comparison.
DanNeely - Friday, June 18, 2021 - link
@Andrei Posting here because I don't have a twitter. It's sadly overpriced vs the US listing, but the phone stand you weren't able to find is available on amazon.de (found by searching for "Prosumer's+Choice")https://www.amazon.de/Prosumers-Choice-Universal-S...
eastcoast_pete - Saturday, June 19, 2021 - link
I believe this move by Google also reflects the curious fact that Google, a pioneer in cloud computing and services, has managed to only play third fiddle to AWS and Microsoft's Azure. Google needs to up their game to stay competitive, and this is one of the ways to start doing so.henryk99 - Thursday, December 16, 2021 - link
This content is a value bomb. I think in future physical storages are going to instinct. Cloud storages are the future. Thanks for sharing.By the way, I am here to discuss about a error resolution tool called <a href="https://opencloudmanifesto.org/quickbooks-file-doc... file doctor</a>, helps the users to resolve almost all the errors. I have shared some useful info regarding the same. Hope it helps.
henryk99 - Thursday, December 16, 2021 - link
This content is a value bomb. I think in the future physical storages are going to instinct. Cloud storages are the future. Thanks for sharing.By the way, I am here to discuss an error resolution tool called QuickBooks file doctor that helps the users to resolve almost all the errors. I have shared some useful info regarding the same. Hope it helps.
Checkout here - https://opencloudmanifesto.org/quickbooks-file-doc...
Dkey - Friday, April 8, 2022 - link
Price will always be a factor of value. The depth of your pockets will determine what you get. Nonetheless, thank you for this piece of information https://customessayexpert.com/