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

A Look at the AMD Zen 2 Core

fuse.wikichip.org

Post reply on HN
Print view View original

61–70 of 94 posts

Re: A Look at the AMD Zen 2 Core

#61

Post by eloff »

deaddodo wrote: post #53
eloff wrote: post #36

Earlier quoted context omitted.

Only partially. There are diminishing returns on cache size.

Only insofar as there are diminishing returns on increasing memory, in general. If you can map your entire application instructions in a low latency block of memory, you're going to see massive benefits over swapping in/out portions repeatedly (where RAM latencies come into play).

Memory access typically follows a pareto distribution with a long tail. So doubling the size of the cache increases access speed more towards the tail, so the speedup is always less than the speedup of the previous cache size increase. The actual effect will vary by application but if the data doesn't all fit in cache, and access patterns follow that long tail distribution, its true that increasing the cache size had diminishing returns. Which is the case for almost all applications.

Re: A Look at the AMD Zen 2 Core

#62

Post by mntmoss »

garkin wrote: post #18

Zen 2 is very good in number crunching and synthetics. But it has a problem - terrible memory latency. 70ns with 3600cl16. ( https://www.userbenchmark.com/UserRun/18168279 ) It distills to a not-so-good gaming frame times. It's 64mb L3 cache ( https://en.wikichip.org/wiki/amd/ryzen_9/3900x ) helps only partially. Few games will suffer greatly from it, but there are several titles with RAM bottlenecks, like PUBG and F…

A latency hit is not a prime concern for retail builds of AAA games. Cache coherency can be done to a very fine-grained degree in a AAA asset pipeline when a few developers are pointed entirely at that optimization problem, since most game scenes are mostly static or have "canned" dynamic elements that can be kept in static pools(e.g. up to 12 NPCs at a time). As such, a substantial part of inner loop processing will take place in cache: what's really at stake when discussing memory performance for games is how the architecture hides latency in its caching implementation, and how that interacts with existing software, since the software in most cases is making an effort to present favorable scenarios with a limited worse-case. Games tend to bottleneck not on the memory, but on single-core performance, since there's a ton of synchronization logic in the game loop that gets in the way of distributing the processing load across all cores, and this has historically been where the Core chips have had big wins over Zen.

For heavily dynamic applications like editing tools where the user is free to shape the data as they please and the worst case is much worse, latency becomes a much bigger issue.

Re: A Look at the AMD Zen 2 Core

#63

Post by deaddodo »

eloff wrote: post #61
deaddodo wrote: post #53

Earlier quoted context omitted.

Only insofar as there are diminishing returns on increasing memory, in general. If you can map your entire application instructions in a low latency block of memory, you're going to see massive benefits over swapping in/out portions repeatedly (where RAM latencies come into play).

Memory access typically follows a pareto distribution with a long tail. So doubling the size of the cache increases access speed more towards the tail, so the speedup is always less than the speedup of the previous cache size increase. The actual effect will vary by application but if the data doesn't all fit in cache, and access patterns follow that long tail distribution, its true that increasing the cache size had…

Sure, but that applies to main memory as well. Ergo, having a larger cache will offer a benefit over memory correlatively; it's only diminishing relative to itself.

Re: A Look at the AMD Zen 2 Core

#64

Post by monocasa »

rrss wrote: post #3

This isn't directly related to Zen 2 (sorry), but it's something I've been wondering about: How do processors that split ops into uops implement precise interrupts? I sort of understand how the ROB is used to implement precise interrupts even with pipelining and OOO, but I don't quite see how processors map uops back to the original instruction sequence.

My understanding on ISAs that require it is that the uops are marked with the PC of the instruction, and are in the ROB in program order so you can reverse the ROB. Intermediate results aren't fully committed until all of the uops have completed, so there's always the possibility of rollback.

Re: A Look at the AMD Zen 2 Core

#65

Post by imtringued »

jnordwick wrote: post #46
garkin wrote: post #18

Zen 2 is very good in number crunching and synthetics. But it has a problem - terrible memory latency. 70ns with 3600cl16. ( https://www.userbenchmark.com/UserRun/18168279 ) It distills to a not-so-good gaming frame times. It's 64mb L3 cache ( https://en.wikichip.org/wiki/amd/ryzen_9/3900x ) helps only partially. Few games will suffer greatly from it, but there are several titles with RAM bottlenecks, like PUBG and F…

This has been a problem with AMD for as long as I can remember. I remember about 10 years ago when AMD made a strong push against Intel and they traded memory latency for larger LL cache sizes and a directory based cache architecture where the better utilization was supposed to make up for the smaller L1/2 sizes. Didn't work. Intel smoked them, especially on server workloads that were cache optimized. I wonder if the…

Cache optimized means that either the processor is able to prefetch the data before it is needed or it is already in cache. It's exactly this situation in which memory doesn't matter at all. Workloads like web servers or databases that run on servers are generally not cache optimized at all. Your Java, python or php program is going to use a lot of pointers which will incur memory accesses. So yes Intel cpus would be better at this but calling these workloads cache optimized is completely wrong.

Re: A Look at the AMD Zen 2 Core

#66

Post by DSingularity »

rrss wrote: post #3

This isn't directly related to Zen 2 (sorry), but it's something I've been wondering about: How do processors that split ops into uops implement precise interrupts? I sort of understand how the ROB is used to implement precise interrupts even with pipelining and OOO, but I don't quite see how processors map uops back to the original instruction sequence.

The simplest solution is a dummy uop “check_int”.

Re: A Look at the AMD Zen 2 Core

#67

Post by jnordwick »

imtringued wrote: post #65
jnordwick wrote: post #46

Earlier quoted context omitted.

This has been a problem with AMD for as long as I can remember. I remember about 10 years ago when AMD made a strong push against Intel and they traded memory latency for larger LL cache sizes and a directory based cache architecture where the better utilization was supposed to make up for the smaller L1/2 sizes. Didn't work. Intel smoked them, especially on server workloads that were cache optimized. I wonder if the…

Cache optimized means that either the processor is able to prefetch the data before it is needed or it is already in cache. It's exactly this situation in which memory doesn't matter at all. Workloads like web servers or databases that run on servers are generally not cache optimized at all. Your Java, python or php program is going to use a lot of pointers which will incur memory accesses. So yes Intel cpus would be…

I'm taking specifically about the workloads I was interested in at the time where cache optimised means it took pains take advantage of larger L1s and took pains to get L1 hits. But this was a general problem too and noted at the time by many people.

AMDs smaller L1 was as definite negative at the time. This was back when hyperthreading could be a net negative because of the reduced L1 cache per thread so we would turn that off to.

Re: A Look at the AMD Zen 2 Core

#68

Post by loeg »

jchw wrote: post #45
garkin wrote: post #43

Earlier quoted context omitted.

2400 vs 3000 vs 3200 MHz RAM | Ryzen 2nd gen: https://youtu.be/TjMq-Nv6Mq8 It affects general tasks too, but with much less magnitude than gaming, because games are concerned with frame times and overall latency the most.

Well, sure... but doesn't increasing the RAM clock increase the throughput as well? What I'm asking is, is there a good way to test the effects of just memory latency?

You can manually increase the DRAM access latency in BIOS, leaving clock alone, and measure. It impacts throughput somewhat, but may be a little closer to an apples-to-apples comparison. I don't know that anyone has attempted to do this for video games on Zen 2 specifically (especially considering Zen 2 is only commercially available for the first time, like, today).

Re: A Look at the AMD Zen 2 Core

#69

Post by viraptor »

jchw wrote: post #37
garkin wrote: post #31

Earlier quoted context omitted.

I will distill your post to: most user builds are bad balanced to begin with and they wont see a difference and would had a better price / more cores. Valid point, i agree with it. Still could be argued about a need for a better memory for Ryzen. This equalizes total build cost and you need to be informed about this platform trait beforehand, which will results in even worse average build balance. Imagine prebuilt PC…

You seem pretty certain this will manifest as a noticeable performance hit. Can this kind of thing be easily measured in practice? I don't know if my workloads would be memory latency sensitive and worse, I don't even have a clue how I would find out. I'm not too concerned though, since I already use Zen 1 and it looks to be around the same. If I had to take a shot in the dark, I'm guessing it's just a consequence of…

> I don't know if my workloads would be memory latency sensitive and worse, I don't even have a clue how I would find out.

If you develop on something unix-ish valgrind's cachegrind will tell you about your L1 performance. On recent Linux you can get this straight from the kernel with `perf stat` https://perf.wiki.kernel.org/index.php/ (cache-misses are total misses in all levels)

The most basic question is: are you randomly accessing more then your processor's cache worth of memory?

Re: A Look at the AMD Zen 2 Core

#70

Post by vbezhenar »

jchw wrote: post #45
garkin wrote: post #43

Earlier quoted context omitted.

2400 vs 3000 vs 3200 MHz RAM | Ryzen 2nd gen: https://youtu.be/TjMq-Nv6Mq8 It affects general tasks too, but with much less magnitude than gaming, because games are concerned with frame times and overall latency the most.

Well, sure... but doesn't increasing the RAM clock increase the throughput as well? What I'm asking is, is there a good way to test the effects of just memory latency?

I think that linked list with randomly distributed nodes is a good benchmark. Each jump will be hit miss and cause load from RAM and you can't prefetch anything because next address depends on content of fetch. Performance of simple iteration of that linked list should correspond to random memory access performance.
Post reply on HN