Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloud.google.com

Post reply on HN
Print view View original

91–100 of 146 posts

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

#91

Post by milesward »

boulos wrote: post #82
mdasen wrote: post #31

Since people from Google Cloud are likely here, one thing I'd like to ask/talk about: are we getting too many options for compute? One of the great things about Google Cloud was that it was very easy to order. None of this "t2.large" where you'd have to look up how much memory and CPU that it has and potentially how many credits you're going to get per hour and such. I think Google Cloud is still easier, but it's get…

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The prob…

We need some kinda shortcut: like, run your app for a few days on an instance, we chew your stackdriver metrics, we make a new shortcut n3-mybestinstance, which picks the right shape/processor family etc for yah.

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

#92

Post by elithrar »

milesward wrote: post #91
boulos wrote: post #82

Earlier quoted context omitted.

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The prob…

We need some kinda shortcut: like, run your app for a few days on an instance, we chew your stackdriver metrics, we make a new shortcut n3-mybestinstance, which picks the right shape/processor family etc for yah.

As a Googler: take VM rightsizing recommendations - "save $X because you're underutilizing this machine shape" - and extend them to encompass this by including VM-family swaps based on underlying VM metrics? :)

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

#93

Post by alfalfasprout »

boulos wrote: post #82
mdasen wrote: post #31

Since people from Google Cloud are likely here, one thing I'd like to ask/talk about: are we getting too many options for compute? One of the great things about Google Cloud was that it was very easy to order. None of this "t2.large" where you'd have to look up how much memory and CPU that it has and potentially how many credits you're going to get per hour and such. I think Google Cloud is still easier, but it's get…

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The prob…

I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient.

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.

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

#94

Post by [deleted] »

mdasen wrote: post #70
theevilsharpie wrote: post #42

Earlier quoted context omitted.

> For example, the N2D instances are basically the price of the N1 instances or even cheaper with committed-use discounts. Given that they provide 39% more performance, should the N1 instances be considered obsolete once the N2D exits beta? As the name implies, N2 is a newer generation than N1. I don't think Google has announced any official N1 deprecation timeline, but that product line clearly has an expiration dat…

> If Google tried to streamline everything...they'd have another cohort of users screaming that the product doesn't meet their needs 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…

[deleted]

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

#95

Post by loeg »

kllrnohj wrote: post #75
loeg wrote: post #60

Earlier quoted context omitted.

Raw single-thread perf still matters for many workloads. Epyc doesn't come in especially high clock / fewer core configurations that are beneficial to some workloads. (Additionally: cloud vendors don't buy that end of configuration; they buy the high core count, high perf per watt configurations. E.g. GCE's N2D is the 2.25 GHz base clock, 64 core Epyc 7742 in a 2P configuration, but you can get EPYC 7302 with 16 core…

> For my business' workloads, Threadripper 3 (same gen 2 Zen, same IO chiplet, etc) would likely be a much better fit (and competitive with Intel) if AMD sold it with the same kind of enterprisey guarantees they do for Epyc (ECC, etc). Threadripper has official support for ECC. Well, "optional" based off of the motherboard's support: https://www.amd.com/en/chipsets/str40 And just picking a random board: https://www.g…

Yep, I'm familiar with all that.

Yeah, it's that "optional" part that is problematic for ECC in particular. But don't let that be a distraction; there are plenty of other enterprisey features in Epyc that are not present in TR, including registered memory support.

Re: 256GB ECC UDIMM on an 8-socket TR board, that's 32GB a DIMM. I guess you can find 32 GB ECC UDIMMs now, but that's pretty recent and expensive.

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

#96

Post by loeg »

vel0city wrote: post #76
loeg wrote: post #60

Earlier quoted context omitted.

Raw single-thread perf still matters for many workloads. Epyc doesn't come in especially high clock / fewer core configurations that are beneficial to some workloads. (Additionally: cloud vendors don't buy that end of configuration; they buy the high core count, high perf per watt configurations. E.g. GCE's N2D is the 2.25 GHz base clock, 64 core Epyc 7742 in a 2P configuration, but you can get EPYC 7302 with 16 core…

AMD does sell Threadripper with the same enterprisey guarantees as they do for Epyc, at least in regards to ECC. >Quad-Channel DDR4 ECC Memory Support >With the most memory channels you can get on desktop6, the Ryzen™ Threadripper™ processor can support Workstation Standard DDR4 ECC (Error Checking & Correction Mode) Memory to keep you tight, tuned and perfectly in sync. https://www.amd.com/en/products/ryzen-threadri…

ECC isn't the only feature, please don't focus on that at the expense of missing the point. They do some market segmentation between TR and Epyc and it is material.

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

#97

Post by bcrosby95 »

adamc wrote: post #64
scardycat wrote: post #37

Earlier quoted context omitted.

Customers like having choices. Enterprises typically will "certify" one config and would like to stay on that till they absolutely need to move to something else.

That reflects the lumbering, bureaucratic nature of enterprises.

Lumbering enterprises that spend billions of dollars on IT.

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

#98

Post by erulabs »

alfalfasprout wrote: post #93
boulos wrote: post #82

Earlier quoted context omitted.

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The prob…

I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google wa…

Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.

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

#99

Post by kllrnohj »

loeg wrote: post #95
kllrnohj wrote: post #75

Earlier quoted context omitted.

> For my business' workloads, Threadripper 3 (same gen 2 Zen, same IO chiplet, etc) would likely be a much better fit (and competitive with Intel) if AMD sold it with the same kind of enterprisey guarantees they do for Epyc (ECC, etc). Threadripper has official support for ECC. Well, "optional" based off of the motherboard's support: https://www.amd.com/en/chipsets/str40 And just picking a random board: https://www.g…

Yep, I'm familiar with all that. Yeah, it's that "optional" part that is problematic for ECC in particular. But don't let that be a distraction; there are plenty of other enterprisey features in Epyc that are not present in TR, including registered memory support. Re: 256GB ECC UDIMM on an 8-socket TR board, that's 32GB a DIMM. I guess you can find 32 GB ECC UDIMMs now, but that's pretty recent and expensive.

> But don't let that be a distraction; there are plenty of other enterprisey features in Epyc that are not present in TR, including registered memory support.

Then don't make your example be ECC specifically. It's the only thing you listed, I wasn't "distracted" by it. And I also even commented on the lack of registered memory support, so I don't know why you're repeating that back to me?

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

#100

Post by aidenn0 »

erulabs wrote: post #98
alfalfasprout wrote: post #93

Earlier quoted context omitted.

I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google wa…

Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.

Plenty of services can deal with X hours of downtime when a single machine fails for values of X that are longer than it takes to restore to a new machine from backups.
Post reply on HN