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

81–90 of 94 posts

Re: A Look at the AMD Zen 2 Core

#81

Post by fulafel »

fulafel wrote: post #78
_chris_ wrote: post #55

Earlier quoted context omitted.

First, most uops can't throw exceptions, so fusing a shift and an add instruction together doesn't require any complex tracking here. If a uop throws an exception (let's say a fused add+ld), each uop can have a tag that helps you backtrace to its PC (instruction address) of let's say the start of the sequence, so you know what to inform the Privileged Architecture as to what "instruction" excepted. For many reasons,…

Instructions such as shift and add that have memory operands can throw exceptions on x86/amd64. (This was some of the motivations of RISC, separating loads/stores from ALU ops made exception handling cleaner). Heh, random note, I just looked up shift instructions on x86, there are 6 different ones, not RISC. But today there's a lot over 1000 instructions so a few shift variants are peanuts.

Correcting myself, the issue was uops and not instructions. But this turns out to be still similar: at least intel nowadays keeps the memory addressing part in uops (most cases) and doesn't split instructions into load/store uops + alu ops.

Re: A Look at the AMD Zen 2 Core

#82

Post by tempguy9999 »

Tuna-Fish wrote: post #60
tempguy9999 wrote: post #15

Earlier quoted context omitted.

The parent's ROB is the reorder buffer. AIUI it causes the instructions to be retired in order (with exceptions stored until retirement, then exposed). The original question, though is how a particular u-op is mapped back to the original macro-instruction, so we know what macro-instruction excepted. And I don't know. I guess is if each u-op is tagged with the instruction address within the process, that would do, but…

Your alternative is sort of close. What happens is that every x86 instruction is assigned a ROB entry. Every uop that has results (stores are handled separately) is assigned a clean register out of the physical register file, and the address of this register (or multiple registers in case of multi-uop instructions) is stored in the corresponding ROB entry. The ROB acts like an in-order circular list -- the retire pha…

I realise you're describing a dataflow engine. Suddenly it's starting to fall into place. Tomasulo's algorithm (which this is about?) is starting to fall into place.

Which is a) amazing and b) OMG the frigging complexity of something that has to run at sub-ns speeds. It's like sausages, the closer you look the less there is to enjoy.

Thanks!

Re: A Look at the AMD Zen 2 Core

#83

Post by snvzz »

lstamour wrote: post #77
snvzz wrote: post #71

Earlier quoted context omitted.

>67ns at 3733C17 I'd go for that.

I was curious as to what Intel’s number’s look like. Found the 2nd gen Ryzen matched the random latency for the 7th gen i7, but while the 3rd gen at 3733CL17 gets 67ns, it’s 53-54 ns for the 8th and 9th gen i7/i9. So that’s narrowed to 13 ns slower, a 24% drop in performance (or a 20% improvement, depending on how you look at it...) While it does matter, we’re comparing 8 core parts to 12 core parts, so it’s possible…

Memory latency is one metric out of many.

For memory latency to matter, you need the worst case scenario to play out, which is a miss on all caches.

For cache to be made entirely irrelevant in performance, you'd need a situation where every access is a cache miss.

Yet even a pattern of completely random memory accesses will hit cache once in a while. And even then, a completely random access pattern is absolutely in disconnect with real world applications.

Thus, performance is not determined by memory latency. It is only a factor. And latency has actually improved, like other metrics, when compared to previous generations.

In short, wait for benchmarks. Just some three hours left for NDA lift.

Re: A Look at the AMD Zen 2 Core

#84

Post by ksec »

cptskippy wrote: post #50
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…

> Few games will suffer greatly from it, but there are several titles with RAM bottlenecks, like PUBG and FarCry. The memory bottlenecks you encounter with the games you mentioned revolve around bandwidth and timing, not latency.

It is unfortunate the comment was not downvoted and stays there that spreads wrong information.

Re: A Look at the AMD Zen 2 Core

#85

Post by tw04 »

garkin wrote: post #31
jchw wrote: post #21

Earlier quoted context omitted.

Not sure why your original comment disappeared. I was kind of curious what the latencies might be for other contemporary processors/builds, and I'm not sure 70ns is actually really outside the normal margins. Here's an i7-8700k build that is already pretty close to 70ns: https://www.userbenchmark.com/UserRun/18173216 - Also acknowledging that, this is not the 'best case' performance. But seems to be not so unusual ei…

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 keep claiming this is going to ruin gaming performance based on napkin math. Why wouldn't you just reference ACTUAL benchmarks, which show your theory to be incorrect?

https://www.anandtech.com/show/14605/the-and-ryzen-3700x-390...

Re: A Look at the AMD Zen 2 Core

#86

Post by rrss »

Tuna-Fish wrote: post #60
tempguy9999 wrote: post #15

Earlier quoted context omitted.

The parent's ROB is the reorder buffer. AIUI it causes the instructions to be retired in order (with exceptions stored until retirement, then exposed). The original question, though is how a particular u-op is mapped back to the original macro-instruction, so we know what macro-instruction excepted. And I don't know. I guess is if each u-op is tagged with the instruction address within the process, that would do, but…

Your alternative is sort of close. What happens is that every x86 instruction is assigned a ROB entry. Every uop that has results (stores are handled separately) is assigned a clean register out of the physical register file, and the address of this register (or multiple registers in case of multi-uop instructions) is stored in the corresponding ROB entry. The ROB acts like an in-order circular list -- the retire pha…

Thanks. The bit im not sure about is how to prevent ending up Ina state in the middle of a single instruction if one instruction gets split into multiple uops. Like if one instruction gets split into two uops and the first one completes but the second one raises an exception.

Re: A Look at the AMD Zen 2 Core

#87

Post by tempguy9999 »

rrss wrote: post #86
Tuna-Fish wrote: post #60

Earlier quoted context omitted.

Your alternative is sort of close. What happens is that every x86 instruction is assigned a ROB entry. Every uop that has results (stores are handled separately) is assigned a clean register out of the physical register file, and the address of this register (or multiple registers in case of multi-uop instructions) is stored in the corresponding ROB entry. The ROB acts like an in-order circular list -- the retire pha…

Thanks. The bit im not sure about is how to prevent ending up Ina state in the middle of a single instruction if one instruction gets split into multiple uops. Like if one instruction gets split into two uops and the first one completes but the second one raises an exception.

OK, let me try (Tuna-Fish, put me right at any point).

> Like if one instruction gets split into two uops and the first one completes but the second one raises an exception.

That's not a problem. It's just one of n exception types that instruction can raise. Suppose a macro (say x64 instruction, if something like this exists) division instruction where one operand could be fetched from memory, you could have

  r2
where ^r4 fetches the contents of memory at address held in r4.

suppose it's split up into u-ops

  tr6
you could have a division by zero at u-op 2, or an invalid address exception for u-op 1. Either of those are valid exceptions for the original single macro-op.

Extrapolating from what Tuna-Fish said, the ROB is list of macro instructions, each instruction I assume will be tagged with its actual macro-op address, and each u-op must link back to the originating macro-op so macro-op retirement can take place, so we have a small (8 bit? Because ROB queue is small) pointer from each u-op back into the macro-op in the ROB.

Follow the 8-bit u-op ptr to the ROB, get the originating macro-op address, raise exception at that address.

Assuming I'm right, and assuming I understood you question correctly. I'll have to read his answer more carefully again.

edit: swapped ^ for asterisk as deref operation, as stars interpreted as formatting. Edit 2: slightly clearer.

Re: A Look at the AMD Zen 2 Core

#88

Post by lstamour »

snvzz wrote: post #83
lstamour wrote: post #77

Earlier quoted context omitted.

I was curious as to what Intel’s number’s look like. Found the 2nd gen Ryzen matched the random latency for the 7th gen i7, but while the 3rd gen at 3733CL17 gets 67ns, it’s 53-54 ns for the 8th and 9th gen i7/i9. So that’s narrowed to 13 ns slower, a 24% drop in performance (or a 20% improvement, depending on how you look at it...) While it does matter, we’re comparing 8 core parts to 12 core parts, so it’s possible…

Memory latency is one metric out of many. For memory latency to matter, you need the worst case scenario to play out, which is a miss on all caches. For cache to be made entirely irrelevant in performance, you'd need a situation where every access is a cache miss. Yet even a pattern of completely random memory accesses will hit cache once in a while. And even then, a completely random access pattern is absolutely in…

True, and the benchmarks told a very different story for Ryzen 3700 and 3900, that for most of these workloads, the gains from the extra cores far outweigh anything else including tiny RAM timing differences. The tests I saw ran with 3600 speed RAM though, for both.

Re: A Look at the AMD Zen 2 Core

#89

Post by topspin »

m3kw9 wrote: post #47

Man, just tell me how fast it runs on practical apps.

The verdict is in. Aside from games Ryzen 3000 is a big win; "practical" application run substantially faster on these CPUs. Intel still has a small absolute lead for a bunch of traditional gaming benchmarks, but work loads like compression, rendering, compiling, transcoding are nearly all faster than anything Intel offers.

Expect large price cuts from Intel soon.

Re: A Look at the AMD Zen 2 Core

#90

Post by monocasa »

fulafel wrote: post #81
fulafel wrote: post #78

Earlier quoted context omitted.

Instructions such as shift and add that have memory operands can throw exceptions on x86/amd64. (This was some of the motivations of RISC, separating loads/stores from ALU ops made exception handling cleaner). Heh, random note, I just looked up shift instructions on x86, there are 6 different ones, not RISC. But today there's a lot over 1000 instructions so a few shift variants are peanuts.

Correcting myself, the issue was uops and not instructions. But this turns out to be still similar: at least intel nowadays keeps the memory addressing part in uops (most cases) and doesn't split instructions into load/store uops + alu ops.

I thought there was two different uop ISAs on big x86 cores with two different purposes these days. One is pretty close to the original instructions, just decoded and fixed width (on AMD at least, this is what's in the uCode ROM). Then those are cracked to another ISA that the ROB knows about because instructions will cross functional unit boundaries.

So in say 'rol mem_addr, shift', your inner ISA would be cracked to something like.

    ld  reg_temp0, mem_addr
    rol reg_temp0, shift
    st  reg_temp0, mem_addr
This is all hearsay though; I could have certainly misheard/misremembered.
Post reply on HN