TR Forums

A little CPU humor... You would think that AMD instead of just boosting one core, could find a way to turbo up several cores in a pattern that maximizes their die separation so they could run hotter and spread out the heat better. On a 16 core system, there could be several patterns of maximum separation that could be cycled through to keep the boost frequency maximized. AMD could call it Symmetric Multi Turboboost.

That overlaps with their SMT=Simultaneous Multi-Threading moniker though.

Secondly, I would imagine they're placing the physical cores to take advantage of separation as much as possible anyway. At least as much as all the other interconnects and resources allow. Core placement and all that has a direct impact on what actual clock speeds you can accomplish in the first place.

DPete27 wrote:

That overlaps with their SMT=Simultaneous Multi-Threading moniker though.

I know But it bugs me that the Ryzen and ThreadRipper boost mechanism does not take advantage of spatial symmetry.

Mr Bill wrote:

...does not take advantage of...

Doesn't or couldn't? I think you're making the assumption that the architecture team simply didn't notice a blatant benefit and that there were no other limitations keeping them from incorporating such a change.
Also keep in mind the physical size of a CPU die. TYPICALLY the entire CPU die is roughly the size of a postage stamp (threadripper the obvious exception). How how much real benefit does it make to load up two cores with such a small difference in physical distance between them?

Mr Bill wrote:

DPete27 wrote:

That overlaps with their SMT=Simultaneous Multi-Threading moniker though.

I know But it bugs me that the Ryzen and ThreadRipper boost mechanism does not take advantage of spatial symmetry.

If you keep moving the same high-frequency-benefiting task from core to core, you have to move a bunch of data from the caches in one core to the caches in another also, which is particularly significant if the cores are on different packages or otherwise don't directly share a cache. That limits the benefits.

Mr Bill wrote:

DPete27 wrote:

That overlaps with their SMT=Simultaneous Multi-Threading moniker though.

I know But it bugs me that the Ryzen and ThreadRipper boost mechanism does not take advantage of spatial symmetry.

It wouldn't be a huge speed boost if they did (assuming that this isn't already happening in some form).

Yes, spreading the heat around a bigger area is great... but spreading the data around to different caches isn't. Might end up being pointless from a performance perspective.

DPete27 wrote:

Mr Bill wrote:

...does not take advantage of...

Doesn't or couldn't? I think you're making the assumption that the architecture team simply didn't notice a blatant benefit and that there were no other limitations keeping them from incorporating such a change.
Also keep in mind the physical size of a CPU die. TYPICALLY the entire CPU die is roughly the size of a postage stamp (threadripper the obvious exception). How how much real benefit does it make to load up two cores with such a small difference in physical distance between them?

Very good points, the first in particular. If I were in marketing, I would try to make a big deal about how the architecture actually goes about balancing the frequency and heat load. That is, they do talk about it but no mention if they are taking advantage of any spatial symmetry. Maybe, after considering all those possibilities it is simply better to let each CPU indicate by its own internal measurements whether it can accept a boost.

Mr Bill wrote:

A little CPU humor... You would think that AMD instead of just boosting one core, could find a way to turbo up several cores in a pattern that maximizes their die separation so they could run hotter and spread out the heat better. On a 16 core system, there could be several patterns of maximum separation that could be cycled through to keep the boost frequency maximized. AMD could call it Symmetric Multi Turboboost.

Couldn't this be done by implementing a context switch between cores with the OS application scheduler? The scheduler would have to read the temperature sensor while considering the load across all the cores. The results would be moving a single heavy thread around in an otherwise idle system.

I think to lesser version of these already exists in the insanity of an OS scheduler, they just don't read the temperature sensor as a factor to do the migration. Rotating where process resides is a feature some schedulers will do to take maximum advantage of turbo.