cores sequence (suggestion to 0.8)

[erazortt]

For single CCX processors: Instead of cycling through the cores in sequence (or random) I would suggest to cycle the cores by always adding +3 to the current core number. This should also be better than random, because this way its never going to be two neighboring cores. The nearest are going to be two cores diagonally. But looking at the zen3 die shot this is actually quite far apart.

Explanation: Assuming AMD numbers the cores in a sensible way, these are the two ways to doing that (see also the die shot from above):

either: 0 | 1 2 | 3 4 | 5 6 | 7

or: 0 | 4 1 | 5 2 | 6 3 | 7

In both cases +3 would be a better choice than in sequence or than random. The full +3 sequence being: 0, 3, 6, 1, 4, 7, 2, 5

So an implementation could be: nextCoreNumber = (currCoreNumber + 3) % 8

[sp00n]

Hm. This algorithm fails for 6 core processors (5600X), so it'd only work for a 5800X. Additionally I'm not sure how the cores are organized on Zen2, which is designed differently (I think with two CCXs per CCD).

But I could add support for a comma separated list akin to the coresToIgnore setting, so you could define your own order for testing.

[erazortt]

Concerning the 6 cores, yes there is probably no way of knowing which cores are actually disabled, so there random is probably the best procedure indeed. For zen2, the core configuration is actually very similar to zen3: zen2 die shot The only difference between zen2 and zen3 is that for zen2 the IF-link is in between 2 groups of four cores. So additionally to the two possibilities I had for zen3 there would be this:

0 | 2 1 | 3 ///// 4 | 6 5 | 7

This would mean that if the is the core numbering AMD uses for zen2, indeed 3,6 and 1,4 would be consecutive in my suggested sequence. However these are also exactly those cores which are separated by the IF-link. So actually these cores are not next to eachother. Considering the geometry of zen2, the best sequence here would probably be to always jump to forth and back to first lower and upper groups of 4. So something like that: 0,4,1,5,2,6,3,7. Thinking about that, and considering that for both zen2 and zen3 the cores are all separated by the L3 cache, making these cores very far appart, this sequence is probably generally not a bad one for all 8 core CCDs.

But yes I admit, its getting too complicated, since there are just too many possible cases. So that random is probably in general the best.

[sp00n]

The next RC4 release will support a custom defined test order by using a comma separated list. Example: coreTestOrder = 5, 4, 0, 5, 5, 7, 2

This list will be processed in the provided order, which means you'll be able to test cores multiple times per iteration. The coresToIgnore setting still applies though, so if this was set to ignore core 5, the actual testing order in the example above would become 4, 0, 7, 2.