Live data from Hacker News

AMD 3rd Gen EPYC Milan Review

anandtech.com

71–80 of 109 posts

Re: AMD 3rd Gen EPYC Milan Review

#71

Earlier quoted context omitted.

The article linked at the top has pages of benchmarks. Did.... you miss them?

There are benchmarks, yes, but Anandtechs' bechmarks are mostly synthetic benches from systems almost no-one uses (I don't run SPEC benchmarks daily, and ok, I compile stuff, but not clang, nor using clang) But Phoronix has synthetic benchmarks from systems quite a few people use (e.g. databases, rendering, simulation). SPEC is nice, but I wouldn't know where to look if I would want to apply that to e.g. postgres. Wi…

SPEC benchmarks are hardly synthetic. They're Perl programs like SpamAssassin, or GCC-compile times, and other "server-like" tasks.

So one can maybe argue that those workloads don't match your use case. But... SPECINT is the "standard server benchmark" for a reason.

I think there's been some suggestions that SPEC benchmarks are a bit small these days and maybe bigger code would be more realistic. But the actual programs they use are decent.

Re: AMD 3rd Gen EPYC Milan Review

#72
post #62

Earlier quoted context omitted.

Servers are in 4U rack mounted enclosures with (relatively) low height heatsinks and huge amounts of airflow. Intake in front, exhaust in rear. Most clients will have beefy air conditioning to keep the ambient intake temp and humidity low.

I think 4U servers are quite rare these days, except for models designed to accommodate large numbers of either GPUs or 3.5" hard drives. Most 2-socket servers with up to a few dozen SSDs are 2U designs.

Agreed. My last company we used a 1RU with 2 blades (servers) in that space. Front to back cooling, quite loud. No need to worry about the noise in the DC. Power density in a rack vs computer density is all that matters.

Re: AMD 3rd Gen EPYC Milan Review

#73

Nice bump in specs. Perhaps now they will announce the Zen3 Threadripper :-). As others have mentioned the TR can starve itself on memory accesses when doing a lot of cache invalidation (think pointer chasing through large datasets). If the EPYC improvement of having the chiplet CPUs all share L3 cache moved into the TR space (which one might assume it would[1]) then this could be a reason to upgrade. [1] I may be wr…

In fact, all Zen chips are equal in the cores part (except for clockspeed and other tuning) thanks to the reusability of chiplets. The only thing that differs between Ryzen, TR amd EPYC is the IO die. And the pins (TR and EPYC use the same package, yep).

Re: AMD 3rd Gen EPYC Milan Review

#74
post #36

Earlier quoted context omitted.

RTFA: “ Users will notice that the 16-core processor is more expensive ($3521) than the 24 core processor ($2900) here. This was the same in the previous generation, however in that case the 16-core had the higher TDP. For this launch, both the 16-core F and 24-core F have the same TDP, so the only reason I can think of for AMD to have a higher price on the 16-core processor is that it only has 2 cores per chiplet ac…

I really don't think the article's speculation there is helpful... it's really reaching. As I said below the article in the comments: > If I were to speculate, I would strongly guess that the actual reason is licensing. AMD knows that more people are going to want the 16 core CPUs in order to fit into certain brackets of software licensing, so AMD charges more for those to maximize profit and availability of the 16 c…

That paragraph struck me as poorly thought out/written as well. I think finding chiplets that will run two cores at the higher 3.5ghz clock is the tricky part, not that it's harder to pick the 2 fastest cores than pick 3.

Re: AMD 3rd Gen EPYC Milan Review

#75
post #69
post #64

Earlier quoted context omitted.

I suspect so. A lot of the commercial market wants stability. Once I've validated a server config for a particular use, I want to be able to continue building those servers for a long time (often long past obsolescence). That may seem odd, but a lot of safety-critical applications (e.g. medical, military, aerospace, etc.) require spending tens of thousands, hundreds of thousands of dollars, or even millions of dollar…

Rather than buying new-old-stock CPUs, why not just buy all the CPUs the long-term program will ever need when they're still cheap, and stockpile them? It's not like they go bad.

There are exceptions of course, but computers are a depreciating asset. You should never buy more computers than you need at any given time, because next year offers better computers for cheaper. Similarly: don't "invest" into a car. They also depreciate.

In contrast: artwork, houses, and a few other goods (Magic: The Gathering cards?) seem to appreciate... or increase in price. These stuff you want to buy before they get more expensive.

Re: AMD 3rd Gen EPYC Milan Review

#76
post #69
post #64

Earlier quoted context omitted.

I suspect so. A lot of the commercial market wants stability. Once I've validated a server config for a particular use, I want to be able to continue building those servers for a long time (often long past obsolescence). That may seem odd, but a lot of safety-critical applications (e.g. medical, military, aerospace, etc.) require spending tens of thousands, hundreds of thousands of dollars, or even millions of dollar…

Rather than buying new-old-stock CPUs, why not just buy all the CPUs the long-term program will ever need when they're still cheap, and stockpile them? It's not like they go bad.

> Rather than buying new-old-stock CPUs, why not just buy all the CPUs the long-term program will ever need when they're still cheap, and stockpile them?

You might not know how many you need. Suppose one of your data centers burns down and has to be replaced or you have triple the expected customer demand.

Also, time value of money.

Re: AMD 3rd Gen EPYC Milan Review

#77
post #48

Earlier quoted context omitted.

What AMD does is not magic and is not beyond what others can do. My question is why they chose to have just 32MB for up to 80 cores when AMD can choose to have 32MB per 8-core chiplet. As a comparison, an IBM z15 mainframe CPU has 10 cores and 256MB per socket.

> As a comparison, an IBM z15 mainframe CPU has 10 cores and 256MB per socket. Well, that's eDRAM magic, isn't it? Most manufacturers are unable to make eDRAM on a CPU. > My question is why they chose to have just 32MB for up to 80 cores when AMD can choose to have 32MB per 8-core chiplet. From my understanding, those ARM chips are largely I/O devices: read from disk -> output to Ethernet. In contrast, IBM's are know…

Didn't Intel push eDRAM magic into various laptop chips around Broadwell?

> those ARM chips are largely I/O devices

Anything Neoverse-N1 is pretty good at general compute and databases. There's definitely a lot of Postgres running on AWS Graviton2 instances already :)

Re: AMD 3rd Gen EPYC Milan Review

#78
Kinda wish there was a 3rd gen 7282 equivalent, for those of us just building their home servers. 2 sockets with (... really need to replace my 2×E5-2630v2, it's getting quite old... but I guess a 2×7282 will do.)

[Ed.: nevermind, hadn't read to the "idle consumption" graphs yet... nope, I'll stick with Rome ...]

Re: AMD 3rd Gen EPYC Milan Review

#79

Nice bump in specs. Perhaps now they will announce the Zen3 Threadripper :-). As others have mentioned the TR can starve itself on memory accesses when doing a lot of cache invalidation (think pointer chasing through large datasets). If the EPYC improvement of having the chiplet CPUs all share L3 cache moved into the TR space (which one might assume it would[1]) then this could be a reason to upgrade. [1] I may be wr…

In fact, all Zen chips are equal in the cores part (except for clockspeed and other tuning) thanks to the reusability of chiplets. The only thing that differs between Ryzen, TR amd EPYC is the IO die. And the pins (TR and EPYC use the same package, yep).

With the notably exception of ryzen mobile, which doesn't use chiplets.

Re: AMD 3rd Gen EPYC Milan Review

#80

Earlier quoted context omitted.

There are benchmarks, yes, but Anandtechs' bechmarks are mostly synthetic benches from systems almost no-one uses (I don't run SPEC benchmarks daily, and ok, I compile stuff, but not clang, nor using clang) But Phoronix has synthetic benchmarks from systems quite a few people use (e.g. databases, rendering, simulation). SPEC is nice, but I wouldn't know where to look if I would want to apply that to e.g. postgres. Wi…

SPEC benchmarks are hardly synthetic. They're Perl programs like SpamAssassin, or GCC-compile times, and other "server-like" tasks. So one can maybe argue that those workloads don't match your use case. But... SPECINT is the "standard server benchmark" for a reason. I think there's been some suggestions that SPEC benchmarks are a bit small these days and maybe bigger code would be more realistic. But the actual progr…

> SPEC benchmarks are hardly synthetic. They're Perl programs like SpamAssassin, or GCC-compile times, and other "server-like" tasks.

That I didn't know.

SPEC doesn't really do much in regards to giving descriptive names to benchmarked items, so its hard to determine what the numbers indicate (other than "this benchmark, which emulates some workload, now has X higher performance"). Some names are descriptive-ish (I think I recognise 7 out of 22 names) but it's all gibberish without a link to why those benchmarks are run and what they are based on (at least not in a way similar to how SPECjbb is explained). It might just be me failing to find it, but searching SPEC in the page (or their website) doesn't seem to give me relevant links.

Does Anandtech have a page detailing the rationale behind their current (CPU) benchmark suite?

Post reply on HN