8 ms·

Characterizing gaming workloads on Zen 4

65 points by zdw 3y ago

pizza234 3y ago
Golden quote describing Intel's trend: > AMD should be commended for not wasting area and power chasing bragging rights. [...] Matching Golden Cove’s 6-wide decoder would have been great for bragging rights, but won’t affect performance much.
- phkahler 3y ago
  Yeah but Zen 5 is going to widen the front end anyway, which is one of the things they had just said was a good choice not to do ;-)
  - deleted 3y ago
    [deleted]
  - DiabloD3 3y ago
    Except that isn't true either except in the very narrow case of "front end for the sake of front end": Lets say you have two, otherwise identical, use cases: You have the P and E Intel cores, and you have the equivalent over at AMD, Zen and Zen-c. The respective E cores are approximately 50-60% of the size of their matching generation P cores, yet use about 40-50% of the power to get roughly the same performance (ie, 2x E cores vs a single P core with both threads running sometimes is comparable to each other, especially with all the anti-meltdown/spectre protections). So, if you compare an P core, with two threads (which is 100% of the size of an P core, duh), or two E cores, each with a single thread, (which is 100% to 120% the size of that single P core), you have near equivalent performance often in less power usage. If I consider the otherwise equivalency of a P core vs 2x E cores, the front end has widened (indeed, 2x E core has more frontend than 1x P core), and I have not significantly widened the backend (E cores from both companies are tiny, and only some of it can be contributed to less cache area). I suspect AMD's end game is to eventually end dual-thread cores, and move to the model being done in Zen-c. One, it removes, forever, an entire class of possible security bugs (after all, Intel's knee-jerk reaction was to reissue series 8 as 9, with threads disabled and all cache assigned to first/only thread); two, it would make extremely high performance desktop and server chips that are better matched towards modern workloads; if AMD continues to make threaded cores, they will be 4/8 thread cores that are sold on specialty Epycs only (ie, the reverse of the current lineup of specialty Epycs being Zen4c, and no desktop Zen4c) "But, hey, what about single-threaded-only workloads?" you might ask. Workloads like that are generally memory latency bound first, memory bandwidth bound second, and then IPC bound third: AMD solved that by having an absolutely gigantic L3. Games are the poster-child of poorly optimized software, and AMD's giant L3 cache does magic here. If my next chip was a 16c/16t E-core desktop chip (to replace your common 8c/16t, the kind I recommend to desktop users, and use myself), I'd be happy.
    - phkahler 3y ago
      >> I suspect AMD's end game is to eventually end dual-thread cores I think not. They're going to widen the fetch/decode in Zen 5. That will help refill the pipe after all those misprints and cache misses, but my not help latency in refilling. One of the best ways to handle stalls is to let "the other thread" execute. I suspect Zen 5 will get huge gains on branchy multi-threaded code but more modest gains on single thread. They're after performance per watt and per dollar, while Intel keeps aiming for top single thread performance and market segmentation - two things some of us don't care about. That said, I'm sure there is a market for a 4 or 8 core chip without SMT that has 50 percent higher single thread performance, and I won't be surprised if Intel provides such a chip.
BryanLegend 3y ago
As a game developer, should I be thinking about reducing branches in performance critical loops?
- dminik 3y ago
  As a game developer, you should consider reducing branches in shaders. Though if you're CPU bound, then sure, it's something to think about.
- r1ch 3y ago
  Ideally try to design your loops so you're accessing memory sequentially (better cache locality) and predictably (i.e. don't branch on a condition that changes in every iteration). Using a branchless algorithm is only really beneficial if the branch is constantly being mispredicted. As always, profile first so you don't fall into the premature optimization hole.
- iforgotpassword 3y ago
  This isn't necessarily game-specific. I'm not up to speed with current gen, but in the past the simple answer was "it depends", as usual. :-) There are times where doing some bit-twiddling hacks outperform branching, or where (partial) loop-unrolling is faster than the higher code density of a firm loop, but in the end for trivial cases, the compiler often, but not always, would do these things behind the scenes if you tell it what CPU you want to target. And if you really want the best performance in a particularly hot section, you just have to benchmark every possible implementation and pick on a case-by-case basis, or even provide two or three different implementations and pick the best one at runtime.
  - clamchowder 3y ago
    (author here) I think it's not useful to eliminate branches in hot loops. These games have giant instruction footprints and a high branch rate. A loop will probably fit within the L1 BTB and uop cache, and probably won't benefit from eliminating branches. Exception would be a branch that's near impossible to predict, like one that depends on a randomly generated value or otherwise doesn't correlate well with global history.
rjh29 3y ago
I know it's not the article topic but I want to talk about mobile Zen4. Mobile Zen4 is obviously powering the ASUS ROG Ally and other handheld Steam Deck clones, and I'm very excited about it, but it's almost impossible to get laptops with it installed! The ones I found also have a discrete GPU which defeats the point. Having a low power draw, thin and light laptop that can also run fairly recent AAA games - amazing! In the end I got tired of waiting for a Thinkpad T14s with Zen4 and got the previous generation, which is about 20% slower but still pretty good.
- adrian_b 3y ago
  On the other hand, while in all the previous years there has been a delay of around one year between the appearance in laptops of some Ryzen model and its appearance in small NUC-like computers, this year a large number of companies have introduced small computers with AMD Phoenix (Ryzen ? 7?40) immediately after its launch. I am happy about this, because instead of carrying a big laptop, I prefer to carry a NUC-like computer, a 17" portable monitor and a compact keyboard, which all together are both lighter and much cheaper than a mobile workstation laptop, while being faster and more comfortable for working and also having more peripheral interfaces.
- deaddodo 3y ago
  > The ones I found also have a discrete GPU which defeats the point. Having a low power draw, thin and light laptop that can also run fairly recent AAA games - amazing! So, disable it? Most Zen4 laptops I've seen so far still fit the general thin and light category (albeit, at 15" vs 11-13") and is paired with a mid-range Radeon or GeForce (usually 4060/4070). Buy the laptop and put it in Eco mode in Windows (doesn't multiplex with discrete) or disable it in bios. The Framework comes with a Zen4 cpu. It's thin and light and the GPU can be disabled: https://youtu.be/L9Ww_7wwNkM?si=Zke0hCcubnwEl6oe https://youtu.be/L9Ww_7wwNkM?si=Zke0hCcubnwEl6oe As someone who owns an AMD laptop (with Radeon discrete), I should point out that AMD's muxing algorithm is pretty conservative, unless you put it into performance mode. Video playback, basic GL/VK/DX operations, desktop usage/web browsing, etc sticks to the integrated GPU. I've only seen the discrete kick in once obvious heavy 3d operations were running (video games, benchmarks, 3d modeling, etc).
hyperman1 3y ago
Can someone explain me why, if a branch is mispredicted enough, a CPU can't execute both the true and the false side? Then throw away half the work when the direction of the branch is finally known. The cost would be more unretired instructions, but the cost of prediction failure would also be lower.
- vlovich123 3y ago
  It’s definitely a thought I’ve had from time to time as well. I’m not a chip designer but my hunch is that it’s because one of the branches is likely to result in even more branches, likely very soon after that initial branch on one of the paths taken (ie you won’t get far before hitting another branch). Example is a condition that causes you to leave the loop - on every iteration of the loop you’d be trying to speculatively execute what happens after the loop. That means you’ve got an exponentially increasing number of speculative execution happening and it’s almost all worthless (ie 1/n^2) while competing for resources with the one real path. This is ignoring the practical challenges of managing all that speculation and any fun additional speculative attacks that might arise again. The best case for something like this is where you have a bunch of unpredictable branches. In those cases, it’s better for the compiler to convert it to “branchless” code (eg using the x86 cmov instruction). There’s also major performance problems unrelated to branches which are data dependencies. I think those are even more impactful these days as they completely inhibit the length of a deep pipeline. Those can only really be solved by fixing code.
- adrian_b 3y ago
  Some CPUs have attempted to do this, but the cost is enormous. Conditional branches are very frequent, so a modern CPU that has much more than one hundred instructions in flight might have ten or twenty branches past which it executes instructions speculatively. So it will not have two sides executed in parallel, but each side will be split in two at the next branch, then again at the next branch. The number of branches that must be executed speculatively in parallel grows exponentially, together with the ratio between executed instructions that must be discarded and useful instructions whose results are retained after the conditions of the branches are resolved. So such a CPU would have a huge power consumption due to doing mostly useless work, which would reduce its performance much more than what is lost during branch mispredictions when only one side is executed. For unpredictable branches, all modern CPUs offer conditional move or conditional select instructions, where both sides of a conditional expression are executed and then the result for the true condition is selected.

65 points by zdw 3y ago

Golden quote describing Intel's trend: > AMD should be commended for not wasting area and power chasing bragging rights. [...] Matching Golden Cove’s 6-wide decoder would have been great for bragging rights, but won’t affect performance much.

phkahler 3y ago
Yeah but Zen 5 is going to widen the front end anyway, which is one of the things they had just said was a good choice not to do ;-)
- deleted 3y ago
  [deleted]
- DiabloD3 3y ago
  Except that isn't true either except in the very narrow case of "front end for the sake of front end": Lets say you have two, otherwise identical, use cases: You have the P and E Intel cores, and you have the equivalent over at AMD, Zen and Zen-c. The respective E cores are approximately 50-60% of the size of their matching generation P cores, yet use about 40-50% of the power to get roughly the same performance (ie, 2x E cores vs a single P core with both threads running sometimes is comparable to each other, especially with all the anti-meltdown/spectre protections). So, if you compare an P core, with two threads (which is 100% of the size of an P core, duh), or two E cores, each with a single thread, (which is 100% to 120% the size of that single P core), you have near equivalent performance often in less power usage. If I consider the otherwise equivalency of a P core vs 2x E cores, the front end has widened (indeed, 2x E core has more frontend than 1x P core), and I have not significantly widened the backend (E cores from both companies are tiny, and only some of it can be contributed to less cache area). I suspect AMD's end game is to eventually end dual-thread cores, and move to the model being done in Zen-c. One, it removes, forever, an entire class of possible security bugs (after all, Intel's knee-jerk reaction was to reissue series 8 as 9, with threads disabled and all cache assigned to first/only thread); two, it would make extremely high performance desktop and server chips that are better matched towards modern workloads; if AMD continues to make threaded cores, they will be 4/8 thread cores that are sold on specialty Epycs only (ie, the reverse of the current lineup of specialty Epycs being Zen4c, and no desktop Zen4c) "But, hey, what about single-threaded-only workloads?" you might ask. Workloads like that are generally memory latency bound first, memory bandwidth bound second, and then IPC bound third: AMD solved that by having an absolutely gigantic L3. Games are the poster-child of poorly optimized software, and AMD's giant L3 cache does magic here. If my next chip was a 16c/16t E-core desktop chip (to replace your common 8c/16t, the kind I recommend to desktop users, and use myself), I'd be happy.
  - phkahler 3y ago
    >> I suspect AMD's end game is to eventually end dual-thread cores I think not. They're going to widen the fetch/decode in Zen 5. That will help refill the pipe after all those misprints and cache misses, but my not help latency in refilling. One of the best ways to handle stalls is to let "the other thread" execute. I suspect Zen 5 will get huge gains on branchy multi-threaded code but more modest gains on single thread. They're after performance per watt and per dollar, while Intel keeps aiming for top single thread performance and market segmentation - two things some of us don't care about. That said, I'm sure there is a market for a 4 or 8 core chip without SMT that has 50 percent higher single thread performance, and I won't be surprised if Intel provides such a chip.

BryanLegend 3y ago

As a game developer, should I be thinking about reducing branches in performance critical loops?

dminik 3y ago
As a game developer, you should consider reducing branches in shaders. Though if you're CPU bound, then sure, it's something to think about.
r1ch 3y ago
Ideally try to design your loops so you're accessing memory sequentially (better cache locality) and predictably (i.e. don't branch on a condition that changes in every iteration). Using a branchless algorithm is only really beneficial if the branch is constantly being mispredicted. As always, profile first so you don't fall into the premature optimization hole.
iforgotpassword 3y ago
This isn't necessarily game-specific. I'm not up to speed with current gen, but in the past the simple answer was "it depends", as usual. :-) There are times where doing some bit-twiddling hacks outperform branching, or where (partial) loop-unrolling is faster than the higher code density of a firm loop, but in the end for trivial cases, the compiler often, but not always, would do these things behind the scenes if you tell it what CPU you want to target. And if you really want the best performance in a particularly hot section, you just have to benchmark every possible implementation and pick on a case-by-case basis, or even provide two or three different implementations and pick the best one at runtime.
- clamchowder 3y ago
  (author here) I think it's not useful to eliminate branches in hot loops. These games have giant instruction footprints and a high branch rate. A loop will probably fit within the L1 BTB and uop cache, and probably won't benefit from eliminating branches. Exception would be a branch that's near impossible to predict, like one that depends on a randomly generated value or otherwise doesn't correlate well with global history.

rjh29 3y ago

I know it's not the article topic but I want to talk about mobile Zen4. Mobile Zen4 is obviously powering the ASUS ROG Ally and other handheld Steam Deck clones, and I'm very excited about it, but it's almost impossible to get laptops with it installed! The ones I found also have a discrete GPU which defeats the point. Having a low power draw, thin and light laptop that can also run fairly recent AAA games - amazing! In the end I got tired of waiting for a Thinkpad T14s with Zen4 and got the previous generation, which is about 20% slower but still pretty good.

adrian_b 3y ago
On the other hand, while in all the previous years there has been a delay of around one year between the appearance in laptops of some Ryzen model and its appearance in small NUC-like computers, this year a large number of companies have introduced small computers with AMD Phoenix (Ryzen ? 7?40) immediately after its launch. I am happy about this, because instead of carrying a big laptop, I prefer to carry a NUC-like computer, a 17" portable monitor and a compact keyboard, which all together are both lighter and much cheaper than a mobile workstation laptop, while being faster and more comfortable for working and also having more peripheral interfaces.
deaddodo 3y ago
> The ones I found also have a discrete GPU which defeats the point. Having a low power draw, thin and light laptop that can also run fairly recent AAA games - amazing! So, disable it? Most Zen4 laptops I've seen so far still fit the general thin and light category (albeit, at 15" vs 11-13") and is paired with a mid-range Radeon or GeForce (usually 4060/4070). Buy the laptop and put it in Eco mode in Windows (doesn't multiplex with discrete) or disable it in bios. The Framework comes with a Zen4 cpu. It's thin and light and the GPU can be disabled: https://youtu.be/L9Ww_7wwNkM?si=Zke0hCcubnwEl6oe https://youtu.be/L9Ww_7wwNkM?si=Zke0hCcubnwEl6oe As someone who owns an AMD laptop (with Radeon discrete), I should point out that AMD's muxing algorithm is pretty conservative, unless you put it into performance mode. Video playback, basic GL/VK/DX operations, desktop usage/web browsing, etc sticks to the integrated GPU. I've only seen the discrete kick in once obvious heavy 3d operations were running (video games, benchmarks, 3d modeling, etc).

hyperman1 3y ago

Can someone explain me why, if a branch is mispredicted enough, a CPU can't execute both the true and the false side? Then throw away half the work when the direction of the branch is finally known. The cost would be more unretired instructions, but the cost of prediction failure would also be lower.

vlovich123 3y ago
It’s definitely a thought I’ve had from time to time as well. I’m not a chip designer but my hunch is that it’s because one of the branches is likely to result in even more branches, likely very soon after that initial branch on one of the paths taken (ie you won’t get far before hitting another branch). Example is a condition that causes you to leave the loop - on every iteration of the loop you’d be trying to speculatively execute what happens after the loop. That means you’ve got an exponentially increasing number of speculative execution happening and it’s almost all worthless (ie 1/n^2) while competing for resources with the one real path. This is ignoring the practical challenges of managing all that speculation and any fun additional speculative attacks that might arise again. The best case for something like this is where you have a bunch of unpredictable branches. In those cases, it’s better for the compiler to convert it to “branchless” code (eg using the x86 cmov instruction). There’s also major performance problems unrelated to branches which are data dependencies. I think those are even more impactful these days as they completely inhibit the length of a deep pipeline. Those can only really be solved by fixing code.
adrian_b 3y ago
Some CPUs have attempted to do this, but the cost is enormous. Conditional branches are very frequent, so a modern CPU that has much more than one hundred instructions in flight might have ten or twenty branches past which it executes instructions speculatively. So it will not have two sides executed in parallel, but each side will be split in two at the next branch, then again at the next branch. The number of branches that must be executed speculatively in parallel grows exponentially, together with the ratio between executed instructions that must be discarded and useful instructions whose results are retained after the conditions of the branches are resolved. So such a CPU would have a huge power consumption due to doing mostly useless work, which would reduce its performance much more than what is lost during branch mispredictions when only one side is executed. For unpredictable branches, all modern CPUs offer conditional move or conditional select instructions, where both sides of a conditional expression are executed and then the result for the true condition is selected.