New AMD EPYC-based Compute Engine family, now in beta

It's long been the "google way" to try and abstract out compute but it's led to an industry full of people trying to follow in their way and overcomplicating what can be solved on one or two machines.

E2 is just such an amazing idea that feels like it's going to be under-utilized because it isn't cheaper for the sustained-use case. There doesn't seem to be any reason why E2 would be more expensive (to Google) for sustained-use and not for on-demand or committed.

Google Cloud is really nice, but the inconsistent pricing/discounting between the different types seems odd. Like, I'm running something on N1 right now with sustained-use because there's no incentive for me to switch to E2. It feels a bit wasteful since it doesn't get a lot of traffic and would be the perfect VM to steal resources from. However, I'd only get a discount if I did a 1-year commitment. For Google, I'm tying up resources you could put to better use. E2 instances are usually 30% cheaper which would give me a nice incentive to switch to them, but without the sustained-use discount, N2D and N1 instances become the same price. So, I end up tying up hardware that could be used more efficiently.

Except that they could simplify it without reducing flexibility.

For example, the difference between E-series and N-series is that E-series instances have the whole balancing thing. Instead of being a different instance type, it could be simplified into an option on available types and it would just give you a discount.

Likewise, some of it is about consistency. How much should sustained-usage give you a discount? 20%? 30%? 0%? There seems to be little difference to Google whether sustained-use an E2, N2, N2D, or N1 in terms of their costs and planning and yet the discount varies a lot.

It's not about fewer choices. It's more that the choices aren't internally consistent. N2 instances are supposed to be simply superior to N1 instance, but N1 instances cost the same as N2 instances for 1-year contract, 3-year contract, and on-demand. They're only more expensive for sustained-use which seems odd. Likewise, E2 instances are meant to give you a discount and they do give you a discount for 3 out of the 4 usage scenarios. The point is that there's no real reason for the pricing not to be consistent across the 4 usage scenarios (1-year, 3-year, on-demand, and sustained-use). That's where the complexity creeps in.

It's really easy to look and say, "ok, I have E2, N2D, and N2 instances in ascending price order and I can choose what I want." Except that the pricing doesn't work out consistently.

> N2 instances are likely faster on a per-core basis

Are they meant to be? Google's announcement makes it seem like they should be equivalent: "N2D instances provide savings of up to 13% over comparable N-series instances".

--

The point I'm trying to make isn't that they shouldn't offer choice. It's that the choice should be consistent to be easily understandable. E2 instances should offer a consistent discount. If N2 machines are the same price as N1 machines across 3 usage scenarios, they should be the same price across all 4. When you browse the pricing page, you can get into situations where you start thinking, "ok, the N1 instances are cheaper so do I need the improvements of the N2?" And then you start looking and you're like, "wait, the N2s are the same price....oh, just the same price most of the time." Then you start thinking, "I can certainly deal with the E2's balancing...oh, but it's the same price...well, it's cheaper except for sustained-use".

There doesn't seem to be a reason why sustained-use on N1s should be cheaper for Google than sustained-use on N2s. There doesn't seem to be a reason why sustained-use on E2s offers no discount - especially given that the 1-year E2 price offers the same 37% discount that the N1s offer.

It would be nice to go to the page and say, "I'm going with E2s." However, I go to the page and it's more like, "I'm going with E2s when I am going to do a 1-year commitment, but I'm going with N2Ds when I'm doing sustained-use without a commitment since those are the same price for better hardware with seemingly no reason and the N1s are just equal or more expensive so why don't they just move them to a 'legacy machine types' page". It's the inconsistency in the pricing for seemingly no reason that makes it tough, not the options. The fact that N2Ds are the same monthly price as E2s for sustained-use, but E2s are significantly cheaper in all other scenarios is the type of complexity that's the annoying bit.

EDIT: As an example, E2 instances are 20.7% cheaper on-demand, 20.7% cheaper with 1-year commitment, and 20.7% cheaper with 3-year commitment compared to N2D instances. That's wonderful consistency. Then we look at sustained use and it's 0.9% cheaper with no real explanation why. It's a weird pricing artifact that means that you aren't choosing, "this is the correct machine for the price/performance balance I'm looking for" but rather you're balancing three things: price, performance, and billing scenario.

Compared to the second-generation Epyc processors that Google is using, the first generation has lower clock speeds, can execute fewer instructions per clock (particularly in terms of floating-point operations), has substantially less cache, and has a more complicated memory topology that can negatively impact the performance of workloads that aren't NUMA-aware.

In short, your experience with AMD in AWS isn't relevant to Google's offerings.

I don't work with Rails anymore but the last Rails app(single threaded, Unicorn) I worked with raw CPU compute was not the bottleneck usually as with most CRUD apps time was mostly spent in I/O. This effect was so pronounced that I had set up most scaling groups on M or R instances as the memory used by the gems was the bottleneck on the number of Rails processes I could spawn in the box without exhausting resources. However I do remember even if CPU was not the bottleneck, moving to a processor with a better single thread performance did improve the median response time at the cost of making the same request throughput costlier.

As for 224, we've always reserved threads on each host for I/O and so on. Figure 2 from the Snap paper [1] is probably the best public reference. We also don't make it clear (on purpose) what size the underlying host processors are, though you can clearly guesstimate pretty easily.

[1] https://research.google/pubs/pub48630/

That's correct! Once the rollout completes, you will be able to use N2D instances for GKE!

224 threads = 112 HT cores = 2 x 56 core CPUs. This is 8 cores short of the 64 core flagship. 8 cores == 1 CCX.

It seems exceedingly unlikely that AMD would produce a Rome CPU with 7 out of 8 CCX in perfect health, but have the 8th CCX completely missing (functionally). It seems more likely that the 8th CCX is there with all 8 cores, and that it is reserved for some other type of service. One possibility could be that there are higher guarantees of side channel protection at the CCX boundary, and google intends to use this for secure internal functions or sell to clients who have side channel sensitivity. Another may be that they simply want the hypervisor to have a very fat budget of 8 cores per socket to work with. Considering the amount of potential IO going on, this might be required in some cases.

Both. AMD uses chiplets for higher yields compared to Intel's huge monolithic processors (HCC, XCC), which lowers costs, and Intel jacked prices up because they had a monopoly.

The argument was always "no one can use more than X cores" - but software seems to trail hardware in these examples, not the reverse. When Zen was first released, many of the less expensive 6 core options performed worse than Intel's similarly priced 4 core chips. But when comparing modern software using those old parts, AMD's 6 core offerings tend to hold up better.

It feels like AMD is finally ushering us into an era where being able to take advantage of large amounts of parallelism is going to become important for almost every developer.

So yes, they figured out how to produce cheaper solutions.

569 Euro equals 613.73 United States Dollar