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

AMD's Turin: 5th Gen EPYC Launched

chipsandcheese.com

Post reply on HN
Print view View original

81–90 of 175 posts

Re: AMD's Turin: 5th Gen EPYC Launched

#81

Post by londons_explore »

addaon wrote: post #8
jeffbee wrote: post #6

The part with only 16 cores but 512MB L3 cache ... that must be for some specific workload.

Does anyone know if modern AMD chips allow mapping the L3 cache and using it as TCM instead of cache? I know older non-X86 processors supported this (and often booted into that mode so that the memory controllers could be brought up), but not sure if it's possible today. If so, that would sure make for some interesting embedded use cases for a large DRAM-less system...

If you keep your working set small enough, you should be able to tell the CPU it has RAM attached, but never actually attach any RAM.

It would never flush any cache lines to RAM, and never do any reads from RAM.

Re: AMD's Turin: 5th Gen EPYC Launched

#83

Post by puzzlingcaptcha »

smolder wrote: post #77

The weirdest one of the bunch is the AMD EPYC 9175F: 16 cores with 512MB of L3 cache! Presumably this is for customers trying to minimize software costs that are based on "per-core" licensing. It really doesn't make much sense to have so few cores at such an expense, otherwise. Does Oracle still use this style of licensing? If so, they need to knock it off. The only other thing I can think of is some purpose like HFT…

Windows server licensing starts at 16 cores

Re: AMD's Turin: 5th Gen EPYC Launched

#85

Post by smolder »

kombine wrote: post #56
swarnie wrote: post #47

Earlier quoted context omitted.

Unsure about the Epyc chips but Ryzen 5 series kit was being given away on Amazon in the week... I snagged a 9 5950X for £242

Thanks for pointing out, it's still up there for £253 - I might consider upgrading my 8 core 5800X3D.

Whether that's an upgrade depends on your use case, as the X3D has more cache.

Re: AMD's Turin: 5th Gen EPYC Launched

#86

Post by RHab »

smolder wrote: post #77

The weirdest one of the bunch is the AMD EPYC 9175F: 16 cores with 512MB of L3 cache! Presumably this is for customers trying to minimize software costs that are based on "per-core" licensing. It really doesn't make much sense to have so few cores at such an expense, otherwise. Does Oracle still use this style of licensing? If so, they need to knock it off. The only other thing I can think of is some purpose like HFT…

Abaqus for example is by core, I am severly limited, for me this makes totally sense.

Re: AMD's Turin: 5th Gen EPYC Launched

#87

Post by Uvix »

sph wrote: post #75
jsheard wrote: post #65

Earlier quoted context omitted.

When buying used Epycs you have to contend with them possibly being vendor-locked to a specific brand of motherboard as well. https://www.servethehome.com/amd-psb-vendor-locks-epyc-cpus-...

They sell this vendor lock-in "feature" as enhanced security?

Yes. It keeps the board from booting if the firmware is replaced with a version not signed by the board manufacturer (i.e. so an attacker can’t replace it with a version that does nefarious things). Preventing CPU reuse in other boards is just an (unintentional?) side effect.

Re: AMD's Turin: 5th Gen EPYC Launched

#88

Post by Uvix »

oivey wrote: post #37
lukeschlather wrote: post #12

Earlier quoted context omitted.

> 16 core CPU and it rarely peaked over 30% utilization, often averaging ~25%. 30% utilization means a 6 core part (barring frequency/cache differences) should be able to eat that at 80% load. As a rule I wouldn't be surprised if 90% of the stuff Civ 6 is doing can't be parallelized at all, but then for that remaining 10% you get a 16x speedup with 16 cores. And they're underutilized on average but there are bursts w…

If only 10% of the workload can be parallelized, then the best case parallelization speed up is only 10%. That doesn’t line up with the GP’s claim that Civ6 benefits from more cores.

They referenced the upcoming Civ7 (which does include 16-core chips on their highest recommended specs), not Civ6.

Re: AMD's Turin: 5th Gen EPYC Launched

#89

Post by justmarc »

zer00eyz wrote: post #59
justmarc wrote: post #50

Truly mind boggling scale. Twenty years ago we had just 1-2 cores per CPU, so we were lucky to have 4 cores in a dual socket server. A single server can now have almost 400 cores. Yes, we can have even more ARM cores but they don't perform as well as these do, at least for now.

700+ threads over 2 cores, can saturate 2 400gbe Nic's 500 wats per chip (less than 2 wats per thread)... All of that in a 2U package.... 20 years ago that would have been racks of gear.

With these CPUs one can definitely hit much higher rates.

800Gbps from a single server was achieved by Netflix on much lesser systems two years ago:

https://nabstreamingsummit.com/wp-content/uploads/2022/05/20...

If I were to guess, this hardware can do double that, also helping that we now have actual 800Gbps Ethernet hardware.

Indeed 20 years ago this would have been racks of gear at a very high cost and a huge power bill.

Re: AMD's Turin: 5th Gen EPYC Launched

#90

Post by bob1029 »

smolder wrote: post #77

The weirdest one of the bunch is the AMD EPYC 9175F: 16 cores with 512MB of L3 cache! Presumably this is for customers trying to minimize software costs that are based on "per-core" licensing. It really doesn't make much sense to have so few cores at such an expense, otherwise. Does Oracle still use this style of licensing? If so, they need to knock it off. The only other thing I can think of is some purpose like HFT…

Another good example is any kind of discrete event simulation. Things like spiking neural networks are inherently single threaded if you are simulating them accurately (I.e., serialized through the pending spike queue). Being able to keep all the state in local cache and picking the fastest core to do the job is the best possible arrangement. The ability to run 16 in parallel simply reduces the search space by the same factor. Worrying about inter CCD latency isn't a thing for these kinds of problems. The amount of bandwidth between cores is minimal, even if we were doing something like a genetic algorithm with periodic crossover between physical cores.
Post reply on HN