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

151–160 of 175 posts

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

#151

Post by to11mtm »

londons_explore wrote: post #81
addaon wrote: post #8

Earlier quoted context omitted.

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.

Part of me is asking whether some of the 'mitigations' to various things in microcode have necessitated reads from RAM?

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

#152

Post by to11mtm »

gkhartman wrote: post #10
bitwize wrote: post #2

> Apparently we now think 64 cores is ‘lower core count’. What a world we live in. 64 cores is a high-end gaming rig. Civilization VII won't run smoothly on less than 16.

I can't help but think that this sounds more like a failure to optimize at the software level rather than a reasonable hardware limitation.

I mean, to some extent maybe.

A surprising number of video games have at least one 'master switch' statement for at least one important aspect of the game logic that has to evaluate on a single thread to maintain some level of 'coherency' while operating at any given frame rate.

The challenge with using threads without careful control of or understanding of the underlying system hardware is that you can wind up with various quirks (Every computer I had from 2000-2010 had this weird 'judder' with HL/TFC/HL2 and explosions, didn't matter the sound card type, CPU brand, or Video card brand,) at best or a rats nest of logic bugs at worst (i.e. the pains of coding multithreading.)

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

#153

Post by AnthonyMouse »

aurareturn wrote: post #108

Phoronix recently reviewed the 196 core Turin Dense against the AmpereOne 192 core. * Ampere MSRP $5.5K vs $15K for the EPYC. * Turin 196 had 1.6x better performance * Ampere had 1.2x better energy consumption In terms of actual $/perf, Ampere 192 core is 1.7x better than Turin Dense 196 core based on Phoronix's review. So for $5.5k, you can either buy an AmpereOne 192 core CPU (274w) or a Turin Dense 48 core CPU (30…

> In terms of actual $/perf, Ampere 192 core is 1.7x better than Turin Dense 196 core based on Phoronix's review.

You're comparing it to the highest MSRP Turin, which doesn't have the highest performance/$. People buy that one if they want to maximize density or performance/watt, where it bests Ampere. If you only care about performance/$ you would look at the lower core count Zen5 (rather than Zen5c) models which have twice the performance/$ of the 192-core 9965.

Doing the same for Ampere doesn't work because their 192-core 3.2GHz model is very nearly already their peak performance/$.

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

#154

Post by tryauuum »

menaerus wrote: post #62
justmarc wrote: post #52

Earlier quoted context omitted.

Surprise surprise, not every tool is right for every job.

Not sure if this comment was about to come out as snarky but the parent rightfully pointed out the not so obvious design of EPYC CPUs. CCD is a NUMA in disguise.

Not in disguise, there's a setting in BIOS, if you set NPS4 + L3 cache as NUMA domain then each CCD will be visible from OS as a separate NUMA node

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

#155

Post by bee_rider »

zamadatix wrote: post #128
bee_rider wrote: post #111

Earlier quoted context omitted.

512 MB of cache, wow. A couple years ago I noticed that some Xeons I was using had a much cache as the ram in the systems I had growing up (millennial, so, we’re not talking about ancient commodores or whatever; real usable computers that could play Quake and everything). But 512MB? That’s roomy. Could Puppy Linux just be held entirely in L3 cache?

CCDs can't access each other's L3 cache as their own (fabric penalty is too high to do that directly). Assuming it's anything like the 9174F that means it's really 8 groups of 2 cores that each have 64 MB of L3 cache. Still enormous, and you can still access data over the infinity fabric with penalties, but not quite a block of 512 MB of cache on a single 16 core block that it might sound like at first. Zen 4 also ha…

Hmm. Ok, instead of treating the cache as ram, we will have to treat each CCD as a node, and treat the chip as a cluster. It will be hard, but you can fit quite a bit in 64MB.

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

#156

Post by hypercube33 »

Dylan16807 wrote: post #139
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.

On the other hand, at the time we would have expected twenty years of progress to make the cores a thousand times faster. Instead that number is more like 5x.

On a different hand the way things were scaling 20 years ago (1ghz took 35 watts) we'd have 5,000W processors - instead we have 196 for 300 watts. If these are anything like ThreadRipper I wonder if they can unlock to 1000W with liquid cooling. On the flip side we are rolling about 1 to 2 watts per core which is wild. Also, can't some of these do 512bit math instructions instead of just 32bit?

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

#157

Post by conjecTech »

mtremsal wrote: post #137
conjecTech wrote: post #126

Earlier quoted context omitted.

The difference in throughput for local versus distributed orchestration would mainly come from serdes, networking, switching. Serdes can be substantial. Networking and switching has been aggressively offloaded from CPU through better hardware support. Individual tasks would definitely have better latency, but I'd suspect the impact on throughput/CPU usage might be muted. Of course at the extremes (very small jobs, ve…

Would you mind expanding on how SerDes become a bottleneck? I’m not familiar and reading the Wikipedia article wasn’t enough to connect the dots.

When you talk between remote machines, you have to translate to a format that can transmitted and distributed between machines(serialization). You then have to undo at the other end(deserialization). If what you are sending along is just a few floats, that can be very cheap. If you're sending along a large nested dictionary or even a full program, not so much.

Imagine an example where you have two arrays of 1 billion numbers, and you want to add them pairwise. You could use spark to do that by having each "task" be a single addition. But the time it would take to structure and transmit the 1 billion requests will be many multiples of the amount of time it would take to just do the additions.

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

#158

Post by conjecTech »

RobinL wrote: post #144
conjecTech wrote: post #126

Earlier quoted context omitted.

The difference in throughput for local versus distributed orchestration would mainly come from serdes, networking, switching. Serdes can be substantial. Networking and switching has been aggressively offloaded from CPU through better hardware support. Individual tasks would definitely have better latency, but I'd suspect the impact on throughput/CPU usage might be muted. Of course at the extremes (very small jobs, ve…

By way of a single example, we've been migrating recently from spark to duckdb. Our jobs are not huge, but too big for a single 'normal' machine. We've gone from a 2.5 hour runtime on a cluster of 10 machines (40,vCPU total) to a 15 minute runtime on a 32vCPU single machine. I don't know for sure, but I think this is largely because it eliminates expensive shuffles and serde. Obviously results vary hugely depending o…

Your measuring wall time, not CPU time. It may be that they are similar, but I'd suspect you aren't loading the worker nodes well. If the savings are from the reduced shuffles & serde, it's probably something you can measure. I'd be curious to see the findings.

I'm not against using simple methods where appropriate. 95% of the companies out there probably do not need frameworks like spark. I think the main argument against them is operational complexity though, not the compute overhead.

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

#159

Post by Dylan16807 »

hypercube33 wrote: post #156
Dylan16807 wrote: post #139

Earlier quoted context omitted.

On the other hand, at the time we would have expected twenty years of progress to make the cores a thousand times faster. Instead that number is more like 5x.

On a different hand the way things were scaling 20 years ago (1ghz took 35 watts) we'd have 5,000W processors - instead we have 196 for 300 watts. If these are anything like ThreadRipper I wonder if they can unlock to 1000W with liquid cooling. On the flip side we are rolling about 1 to 2 watts per core which is wild. Also, can't some of these do 512bit math instructions instead of just 32bit?

Well, a 286 was about 3 watts right? So if our medium point is 35 watts then the final would be 400 watts.

Or if our medium point is a 60 watt pentium 4 then our final point would be a 1200 watt single core with multiple millions of times the performance, and dropping down to 300 watts would still be crazy fast.

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

#160

Post by smolder »

kombine wrote: post #103
smolder wrote: post #85

Earlier quoted context omitted.

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

I don't play games so the X3D's cache doesn't really benefit me. 5950X should speed up compilation, but then, I mostly do Python at the moment :)

You might be surprised at what benefits from the big cache outside of games but that is certainly one of the main selling points. :)
Post reply on HN