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

131–140 of 175 posts

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

#131

Post by smolder »

Tuna-Fish wrote: post #49
Salgat wrote: post #35

Earlier quoted context omitted.

I wonder how this compares to the 7950x3d. So much cache and a high boost clock. https://www.amd.com/en/products/processors/server/epyc/9005-...

Great if you have 16 independent workloads, terrible for things that care about communication between threads. It has 16 CCD, each with only one thread enabled, latency between CCD is ~150ns.

150ns is actually surprisingly high! I didn't realize it was so bad. That's about 2-3x as much latency as fetching from DRAM based on what I see in peoples AIDA64 results.

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

#132

Post by justmarc »

RobinL wrote: post #121
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.

I wonder what percentage of 'big data' jobs that run in clusters would now be far faster on a single big machine with e.g. duckdb rather than spark

I often think about huge, fancy cloud setups literally costing silly money to run, being replaced by a single beast of a machine powered by a modern, high core count CPU (say 48+), lots of RAM and lots of high performance enterprise-grade SSD storage.

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

#133

Post by bitwize »

deaddodo wrote: post #120
cubefox wrote: post #107

Earlier quoted context omitted.

Old habit. I'm a kid of the 1990s, and we were convinced there wasn't anything cooler than a) video games and b) replacing letters with numbers. It retrospect, we might have been a little biased.

Well, just for future reference; if you're a kid of the 90s, you're well into your 30s now. It's weird/juvenile to be typing a phrase in a manner similar to a preteen, well after 20+ years have passed. Especially in the middle of an otherwise normal message/conversation.

We thought that was dorky, skiddie shit even back in the 90s. It was even more stale by the time Piro and Largo turned it into a personality trait.

Though I think this guy just did it the way a 2000s kid would say "vidya gaems".

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

#134

Post by tpurves »

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…

AMD also wins on perf/Watt which is pretty notable for anyone who still believed that X86 could never challenge ARM/Risc in efficiency. These days, lot of data centers are also more limited by available Watts (and associated cooling) which bodes well for Turin.

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

#135

Post by yusyusyus »

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…

new vmware licensing is per-core.

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

#136

Post by CraigJPerry »

Aurornis wrote: post #129
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…

Many algorithms are limited by memory bandwidth. On my 16-core workstation I’ve run several workloads that have peak performance with less than 16 threads. It’s common practice to test algorithms with different numbers of threads and then use the optimal number of threads. For memory-intensive algorithms the peak performance frequently comes in at a relatively small number of cores.

Is this because of NUMA or is it L2 cache or something entirely different?

I worked on high perf around 10 years ago and at that point I would pin the OS and interrupt handling to a specific core so I’d always lose one core. Testing led me to disable hyperthreading in our particular use case, so that was “cores” (really threads) halfed.

A colleague had a nifty trick built on top of solarflare zero copy but at that time it required fairly intrusive kernel changes, which never totally sat well with me, but again I’d lose a 2nd core to some bookkeeping code that orchestrated that.

I’d then tasksel the app to the other cores.

NUMA was a thing by then so it really wasn’t straightforward to eek maximum performance. It became somewhat of a competition to see who could get highest throughout but usually those configurations were unusable due to unacceptable p99 latencies.

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

#137

Post by mtremsal »

conjecTech wrote: post #126
RobinL wrote: post #121

Earlier quoted context omitted.

I wonder what percentage of 'big data' jobs that run in clusters would now be far faster on a single big machine with e.g. duckdb rather than spark

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.

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

#138

Post by cjbprime »

justmarc wrote: post #132
RobinL wrote: post #121

Earlier quoted context omitted.

I wonder what percentage of 'big data' jobs that run in clusters would now be far faster on a single big machine with e.g. duckdb rather than spark

I often think about huge, fancy cloud setups literally costing silly money to run, being replaced by a single beast of a machine powered by a modern, high core count CPU (say 48+), lots of RAM and lots of high performance enterprise-grade SSD storage.

(Oftentimes part of the reason the huge, fancy cloud setup costs more is that any component can fail, all the way down to the region-level, without loss of service.)

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

#139

Post by Dylan16807 »

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.
Post reply on HN