Live data from Hacker News

A Look at the AMD Zen 2 Core

fuse.wikichip.org

51–60 of 94 posts

Re: A Look at the AMD Zen 2 Core

#51
post #44

This is a really good article. I am finally at the point in my college education where I can understand what they are talking about! Are there any articles like this about Apple or Intel chips? I like hearing about actual implementations, not just educational processors. (I am looking through the other articles on this site.)

Check out the WikiChip tops level page. Covers both Intel, AMD, and ARM. Nothing particular to Apple though. https://en.wikichip.org/wiki/WikiChip

Also a great book though maybe dated by now is Modern Processor Design by Shen.

Re: A Look at the AMD Zen 2 Core

#52
post #44

This is a really good article. I am finally at the point in my college education where I can understand what they are talking about! Are there any articles like this about Apple or Intel chips? I like hearing about actual implementations, not just educational processors. (I am looking through the other articles on this site.)

https://www.anandtech.com (Ian Cutress et al.) has good regular "deep dive" pieces. David Kanter at https://www.realworldtech.com is worth a read, although his site is not as active.

Re: A Look at the AMD Zen 2 Core

#53
post #36

Earlier quoted context omitted.

But Zen 2 has HUGE L3 cache. I think that this cache would compensate for that latency.

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).

Re: A Look at the AMD Zen 2 Core

#54
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…

I think people get a little over zealous with CPU requirements on games. If my eight year old Xeon 5676 can handle every past and present game I throw at it, I think you'll be beyond spec for years to come with a Zen 2(or any modern processor).

it depends a lot on the type of game and what you care about for that type of game.

if you're playing a AAA singleplayer game, the GPU will almost certainly be the bottleneck. any i5/i7 tier CPU from the last eight years will be powerful enough not to starve the GPU most of the time. when I play this sort of game, I mostly just care about the average framerate. I don't care too much if every 10-15 minutes a complex scene causes a brief stutter. if this is the only kind of game I played, I would just get a cheap midrange processor (unless I had requirements due to unrelated workloads).

on the other hand, when I play a fast-paced multiplayer game (especially fps), I care a lot more about worst case framerates than average. in a game like counterstrike, framerate drops tend to happen when there are smokes, flashes, and/or multiple players onscreen simultaneously. in other words, they happen in the most important moments of the game! while I'm happy to average around 45-60 fps in the witcher, I want the minimum in csgo to be no less than 120. if you have a goal like this, even an old source engine game becomes pretty demanding.

there are also games like factorio where the simulation itself is difficult or impossible to split into multiple threads. singlethreaded performance and memory bandwidth set an upper bound to how big your base can be while still having a playable game.

Re: A Look at the AMD Zen 2 Core

#55
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.

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, you need to store a list of PCs of the inflight instructions somewhere (although it is heavily compressed), so having a small ID tag to help reconstruct a given uop's PC isn't too onerous.

Ideally, multiple instructions may map to a single uop, but either none (or up to one) can throw an exception. The hard one here is something like load-pair uops; since each load can throw an exception. Some machines, if a fault is encountered, will refetch the pair and re-execute as independent/unfused loads. Other designs will just pay the pain of tracking which of the pair excepted and do some simple arithmetic off of that.

Re: A Look at the AMD Zen 2 Core

#57
post #13
post #5

The post states: >"Perceptrons are the simplest form of machine learning and lend themselves to somewhat easier hardware implementations compared to some of the other machine learning algorithms." Can someone explain what is it about perceptrons that make them easier to implement in hardware?

There's a very approachable explanation in the following (around the 1:01:40 mark): https://youtu.be/8I_1TSs695I?t=1h1m40s -- part of Design of Digital Circuits - Lecture 18: Branch Prediction II (ETH Zürich, Spring 2019). Related readings: https://safari.ethz.ch/digitaltechnik/spring2019/doku.php?id... . These lectures are pretty great, by the way, highly recommended to anyone interested in computer architecture: ht…

These are fantastic links, thanks! I've watched many of Onur Mutlu's CMU lectures he's a wonderful teacher. Cheers.

Re: A Look at the AMD Zen 2 Core

#58
post #25
post #4

"Zen employs a dynamic predictor known as a hashed perceptron." When will Hollywood tap into this wealth of cool vocabulary? Is this a gimmicky marketing term, or is it logical\descriptive\rational?

A perceptron is a simple type of neural network that is very fast to use when already trained. So it is a real network, I don't know what hashed perceptron is but I'd guess it would have to do something with hashing the inputs to the perceptron?

"Hashed" in this case simply means they did some extra work to deal with the perceptron's XOR problem, since a straight mapping of PC and branch history would led to an inability to distinguish XOR patterns.

Re: A Look at the AMD Zen 2 Core

#59
post #5

The post states: >"Perceptrons are the simplest form of machine learning and lend themselves to somewhat easier hardware implementations compared to some of the other machine learning algorithms." Can someone explain what is it about perceptrons that make them easier to implement in hardware?

All you need for a perceptron is to add up all of the inputs after they’ve been multiplied by their weight. This would probably be done in parallel with a fused multiply add circuit which is fairly simple and some place to store the weights. When they change the perceptron all they need to do is record the current weights and load in the new values.

Makes sense, thanks for the explanation.

Re: A Look at the AMD Zen 2 Core

#60
post #9

Earlier quoted context omitted.

I'm not an expert but I believe what accomplishes this task is the reorder buffer. This allows the instruction execution and its side effects to be separated.

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 phase drains it in order from the oldest first, retiring the oldest instruction if and only if all the corresponding PRF registers have been written to. This is the point where any and all side-effects are made visible.
Post reply on HN