Live data from Hacker News

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

cloud.google.com

71–80 of 146 posts

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

#71
post #59
post #52

Earlier quoted context omitted.

They really are doing something disruptive. I can't quite remember if this is correct (it has been a while since I last studied business), but in business there is a "blue ocean strategy". The basic premise is, if you can provide a product for half the price, with the twice the value, you will destroy the incumbent. What AMD is doing is really insane in my opinion. I'm not sure if they are pricing their processors lo…

Two problems is production capacity and data center, since AMD is competing against Apple for production by tsmc. on the point about data centers, Amd narrowly got on the train here. Semiconductors are a very cyclical industry and since the end of the business cycle is coming in Amd is in for a rough time. There's room for growth, but arguably the stock is priced in

The opposite.

AMD spent less money on TSMC's research. Apple has been bankrolling TSMC to get the latest and greatest process tech.

AMD reached 7nm not because AMD put the R&D research into it... but because they can ride on the coattails of Apple and TSMC's investments.

--------

TSMC and Apple simultaneously benefit: TSMC can spread the risk of the 7nm process to more companies. Apple still gets first-dibs on the technology (but they only need ~6months worth of factory time to build all the chips they need).

Its more surprising that Intel managed to stay ahead of TSMC / Apple for so long. The economics are kind of against Intel here. The more people working together on process tech, the more efficient the results get.

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

#72
post #64

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.

Any company has a problem, which they size the value that it has to be tackled for, so they set budget, measure options, raise possible trade-offs, eventually succeed at dealing with it or get bitten due to lack of proper future-proofing, not evaluating environment/requirements properly, rinse and repeat. Once you've got several problems that require this kind of approach, carefully handpicking the possibly-but-not-proven best solution is not only time consuming but might lead to potentially awfully impactful consequences. When the decision to switch cloud provider services to one that may get you offline for half an hour leading to a million-dollar revenue impact, that's when we're talking enterprise.

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

#73
post #28
post #27

What are the implications? Higher perf and/or lower price?

Looks to be about $5/Month cheaper, based on this page: https://cloud.google.com/compute/all-pricing#n2_machine_type... Jeez, I didn't realize how expensive cloud compute was. I always wondered why my school still has a datacenter. Having your own servers still makes sense for a lot of orgs.

It’s a question of how dynamic your usage is and how much the better security and management features save you. If you have very consistent workloads with little idle hardware and modest admin needs you can beat cloud environments even with reservations but usually when I see the numbers it means major costs like staffing or power / HVAC aren’t being factored in.

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

#74

Earlier quoted context omitted.

There's absolutely no way you could've read those articles in the last four minutes. They go into great detail about what makes the Rome processors so important -- it's not just some random amalgamation of benchmarks, but the benchmarks serve to provide hard numbers that back up the textual analysis. The benchmarks are not just "distributed compilation" either... that's a very misleading characterization. There was o…

Every morning, I beg my God to make morons stop replying to me on HN. Today is the first day anyone has promised to make my dream come true. I didn't read those articles in the last 4 minutes because I read them when they were published. A massively parallel run of 7zip was a really stupid benchmark in August and it remains stupid today. These other benchmarks are certainly more relevant but none of them jumps out at…

Calling someone a moron is not acceptable on HN, to start with, but it's also just not a great way to conduct a discussion. Secondly, you explained that you HAVE read the articles, so why would I stop replying to you?

> These other benchmarks are certainly more relevant but none of them jumps out at me as a killer claim. An EPYC 7402 with 50% more cores, drawing 80% more power, and costing 35% more dollars than a Xeon Silver 4216 delivers 24% more pgsql ops per second. What TCO equation do you plug that into? I would describe these results as mixed.

That's some interesting cherry picking. If I may do some of my own...

- The Epyc 7642 is doing 66% more pg sql ops per second than the Silver 4216, but only using an average of 34% more power than the 4216.

- The Xeon Platinum 8253 is consuming about the same amount of power as the Epyc 7402, costs twice as much, and yet the 7402 is performing 34% faster.

The Xeon Silver 4216 is competitive in this one benchmark, and you declare that the results are "mixed". It gets thoroughly destroyed in tons of other benchmarks.

So, yes, if you will only ever run this specific version of MariaDB on this one server, then it might be a toss up... IF you don't benefit from using PCIe 4.0 to access more (or faster) SSDs, and you don't want to have the option of putting in more RAM.

AMD is consistently better in the overwhelming majority of benchmarks here, especially as you get away from the low end. Saying that Intel has one "toss up" victory in the low end category is not exactly a ringing endorsement to pick Intel here.

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

#75
post #60

Earlier quoted context omitted.

You can pick almost any basis you like, it's still winning. Most performance, most performance per watt, most performance per cost. Also, more performance per thread than high-threadcount intel chips. (Although, some of their low-threadcount Xeons do have an edge on that one.) Oh, and best memory interface and best IO, too.

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.gigabyte.com/Motherboard/TRX40-AORUS-XTREME-rev-... you'll see it listed:

"Support for ECC Un-buffered DIMM 1Rx8/2Rx8 memory modules"

That it must be un-buffered is an annoying market segmentation thing that limits your max RAM in practice, BUT you can at least get ECC up to 256GB with official support and RAM modules that actually exist.

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

#76
post #60

Earlier quoted context omitted.

You can pick almost any basis you like, it's still winning. Most performance, most performance per watt, most performance per cost. Also, more performance per thread than high-threadcount intel chips. (Although, some of their low-threadcount Xeons do have an edge on that one.) Oh, and best memory interface and best IO, too.

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-threadripper

ECC is also supported in the desktop class CPUs and chipsets.

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

#77
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…

Realistically; a typical hyperscale cloud provider has tens/hundreds of millions of dollars invested into a specific CPU platform. It makes very little sense to just throw it out chasing some idealism like "simplicity"; the world is not simple.

You can be like Digitalocean and just say "You want a CPU core, you get a CPU core, no guarantee what it'll be". Most enterprises won't buy this. But, I think there's some interesting use-cases where even a hyperscale provider targeting enterprises could (and do) utilize this; not on an EC2-like product, but as the infrastructure for something like Lambda, or to run the massive number of internal workloads necessary to power highly-managed cloud workloads.

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

#78
post #7

Earlier quoted context omitted.

We do not yet support AMD's nested implementation (we do on Intel). But cvallejo is also the PM for Nested :). 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.googl…

> We do not yet support AMD's nested implementation (we do on Intel). Any particular reason for that limitation, or just "not implemented yet"? (Not asking for product roadmaps, just wondering if there's a specific technical issue that makes it more difficult to support.) > 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.…

Not implemented yet. In the stack rank of “stuff needed to update our hypervisor for AMD again” it wasn’t at the top :).

Note the again as well: GCE originally had it such that N in N1 meant iNtel, and A1 was for AMD (as Joe said publicly here: https://twitter.com/jbeda/status/1159891645531213824). By the time I joined though, we didn’t see the point of the A1 parts, since the Sandybridge’s smoked them.

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

#80
Disclosure: I work on Google Cloud.

This has come up a few times, so I wanted to reiterate that these are the Zen2/Rome parts not the first generation “Naples” parts. We didn’t bother launching Naples for GCE, because (as you can see) Rome is a huge step up.

Post reply on HN