• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Zen 6 Speculation Thread

Page 291 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
gdansk said:
Most probably each step itself can be. But it ends up waiting for the slowest "substep" of each step, then add synchronization time on top of that. There are truly problems which scale poorly. I'm not sure if this is one but it easily could be the outcome of having a modular plug-in architecture where each plug-in expects memory not to be modified beneath it between its own actions.
Click to expand...
Sure there are some cases where some code cannot be parallelized. But in the case you mentioned, you can potentially also parallelize even within each substep.

And my main point is that in many cases SW developers are lazy or poor and do not parallelize the code even when it’s possible to do so. It’s unfortunate, because it does not make use of the available cores which makes the execution take much longer than it has to.
 
Fjodor2001 said:
Sure. I was thinking there would be someone brave enough to take a guess already now, based on process tech, arch, core count, or whatever. I mean people are brave enough to out their perf estimates in the Hulk table.

In my case I’ll probably evaluate Zen6 vs NVL-S at approx 120W and see which one performs best. For me it’s not worth almost twice the power consumption as needed when maxing it out, just to get 10-20% extra perf or whatever.
Click to expand...
I'd guess that there are three main factors that will have a big influence on the Performance-Power Curve of Zen6 compared to Zen5:

Obviously the new process will generally give you more Performance for a given Power input. So, the whole curve will get elevated a bit.

The new interconnect will lead to a smaller part of IOD consumption which might be pretty significant for let's say below 80w. So the curve will start higher and be less steep in the left half - a bit more like the curve of the 285K in your picture.

The core increase will keep the per core consumption in a more efficient range for longer. So even at 200w total consumption, 24c will not be as much in the diminishing returns as 16c are today. So from 80w to 200w the curve should be steeper than today. For when it will start to flatten, I obviously can't say.

So all in all I am expecting the curve to look more like the 285K but without the kink (is there an explanation for this?) and altogether on an elevated level.
 
StefanR5R said:
An audio compressor, for example. Duh!
(sound compressor, not data compressor; edit: in realtime processing, not "offline" batch processing)
Click to expand...
Actually this might be MT possible as well. Plugin developers are starting to model the actual components and circuits within analog devices and not just make functions to "transform" a given input to a desired output.

If there are circuit in the model that require more compute than others than it might be possible these bottlenecks could be reduced by allocating cores to these "compute hotspots." I'm not an expert here just thinking out loud?
 
Maybe parts of the computation can be spread over more than one core. [Though given how wide and fast modern vector arithmetic units are per core, it might not be worthwhile.] But the main point is that there is data dependency across all tracks of multitrack audio when it comes to a compressor. At least from what I understand.
 
Fjodor2001 said:
Based on what you wrote in the rest of that post I have more of a despise for poorly written SW. 🙂
Click to expand...
Audio processing is highly parallelizable IMO. Certainly, Compression and other algorithms rely on a window; however, this only complicates the stitching windows, it doesn't eliminate parallel computing ability.

I know LOTS of software engineers that tremble at the thought of the words "Thread" or "Semaphore".
 
OneEng2 said:
Audio processing is highly parallelizable IMO. Certainly, Compression and other algorithms rely on a window; however, this only complicates the stitching windows, it doesn't eliminate parallel computing ability.

I know LOTS of software engineers that tremble at the thought of the words "Thread" or "Semaphore".
Click to expand...
Let me guess why. Not ever having worked as a software engineer. Let me know how I do.

You are on a team that is understaffed and perfectly obeys the pareto distribution, that is, the square root of the total number of people on the team do half of the work.
Second, you have certain design objectives put down from the execs. that are going to nearly impossible to meet with currenting staffing and hour available.
On top of this there are plenty of bug reports that have to be worked out along the way.

So let's see, my priority is just to get the software working and I'm going to make that happen in the easiest way possible. We'll worry about optimizations later. Later never happens.
 
BorisTheBlade82 said:
The core increase will keep the per core consumption in a more efficient range for longer. So even at 200w total consumption, 24c will not be as much in the diminishing returns as 16c are today. So from 80w to 200w the curve should be steeper than today. For when it will start to flatten, I obviously can't say.
Click to expand...
This should also mean we'll hopefully get quite an impressive MT perf increase going from Zen5->Zen6 at default TDP.
 
Fjodor2001 said:
This should also mean we'll hopefully get quite an impressive MT perf increase going from Zen5->Zen6 at default TDP.
Click to expand...
Given two node jumps and 50% more cores, a 40% MT improvement at ISO power does not seem too optimistic IMHO. If things (the node jumps especially) go well and IPC % improvements come with less % power increase (as AMD always targets), it might be even significantly more.
 
BorisTheBlade82 said:
Given two node jumps and 50% more cores, a 40% MT improvement at ISO power does not seem too optimistic IMHO. If things (the node jumps especially) go well and IPC % improvements come with less % power increase (as AMD always targets), it might be even significantly more.
Click to expand...
We should get that, at a minimum, but it will 100% depend on the power level chosen. The performance delta will be greater at 230W than it is at 200W for example. While Zen 5 doesnt scale much from 200 to 230, Zen 6 certainly will. Likewise, delta at 65W or lower could easily be 150% or more if AMD cuts idle power to sub 15W for Zen 6.

Performance delta might look like below due to those two factors above. It could be a strange phenomenon where you either want to be very low or very high power to get the best perf deltas , with middling power levels having the worst.

1762294090689.png
 
Last edited:
Hulk said:
Let me guess why. Not ever having worked as a software engineer. Let me know how I do.

You are on a team that is understaffed and perfectly obeys the pareto distribution, that is, the square root of the total number of people on the team do half of the work.
Second, you have certain design objectives put down from the execs. that are going to nearly impossible to meet with currenting staffing and hour available.
On top of this there are plenty of bug reports that have to be worked out along the way.

So let's see, my priority is just to get the software working and I'm going to make that happen in the easiest way possible. We'll worry about optimizations later. Later never happens.
Click to expand...
LOL. Always. Do the impossible .... with nothing ..... by tomorrow 😉.

"There is never enough time to do it right ..... but there is always time to re-do it".
Fjodor2001 said:
This should also mean we'll hopefully get quite an impressive MT perf increase going from Zen5->Zen6 at default TDP.
Click to expand...
Seems inevitable really. 50% more cores and a double node shrink.

I am thinking that the IPC improvement is going to be anemic though. Any ST improvement will likely be through clock speed increases.
 
Tarkin77 said:
Lisa on the Q3 earnings call: first Venice Platforms online at CSPs
Click to expand...
As a sidenote, for non-native speakers, it's sometimes useful to write out very commonly used acronyms.

Coming from a software-dev background and being a non-native speaker, my first associations were: Content Security Policy, Credential Service Provider, and after a bit of thinking, even Common Spatial Pattern, but none seemed to fit the bill at all 😀

I had to look the acronym up on Wikipedia and read to the very end to arrive at the obvious conclusion (in hindsight), that it's Cloud Service Providers.

Now, that's obviously my fault, not anybody else's, but just writing "cloud providers" in the first place doesn't seem that much longer.
 
Last edited:
Josh128 said:
We should get that, at a minimum, but it will 100% depend on the power level chosen. The performance delta will be greater at 230W than it is at 200W for example. While Zen 5 doesnt scale much from 200 to 230, Zen 6 certainly will. Likewise, delta at 65W or lower could easily be 150% or more if AMD cuts idle power to sub 15W for Zen 6.

Performance delta might look like below due to those two factors above. It could be a strange phenomenon where you either want to be very low or very high power to get the best perf deltas , with middling power levels having the worst.

View attachment 133183
Click to expand...
Absolutely agree in this.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top