Pour essayer de voir l'impact du design utilisé par AMD sur les performances, nous avons comparé deux configurations 4 coeurs sur notre 1800X :

• Désactiver complètement un CCX (4+0)
• Désactiver la moitié de chaque CCX (2+2)

Cela nous permet de voir en pratique l'impact de la communication entre les CCX.

Comme pour au dessus, nous réalisons les tests à 3 GHz, le SMT est désactivé pour limiter la variabilité. De manière assez intéressante (on y reviendra), les 8 Mo de cache sont disponibles dans chaque CCX en configuration 2+2. En théorie, donc, cette configuration est avantagée, elle a accès à 2 x 8 Mo de L3, contre seulement 1 x 8 Mo pour la configuration 4+0.

Nous calculons un indice 100 de performances pour la configuration 4+0 :

Beaucoup de choses à dire sur ces résultats. D'abord sur les applications, on notera que cela va dans tous les sens !

x264 et x265, peu sensibles au sous système mémoire font des performances virtuellement identiques dans les deux modes.

Surprise cependant, les cas de WinRAR et 7-Zip, deux benchs très sensibles au sous système mémoire qui montrent des résultats bien différents.

Dans le cas de 7-Zip, c'est la configuration 2+2 qui est la plus intéressante. Il semblerait que le logiciel profite mieux de la présence des 16 Mo de L3. A l'inverse, WinRAR est plus pénalisé par la synchronisation et le cache L3 supplémentaire ne compense pas.

C'est cependant les jeux qui montrent le résultat le plus intéressant. Dans tous les cas, la configuration ou un CCX est désactivé est la plus performante. Le cache L3 supplémentaire disponible n'y change rien, les pertes sont très variables en fonction des titres mais pour certains la différence est massive : Battlefield 1 annonce un différentiel de presque 20% qui se traduit en pratique par 22 FPS d'écart ! La synchronisation des données semble extrêmement pénalisante dans ce titre. Project Cars et Civilization VI accusent aussi des pertes non négligeables.

Vraiment 2 x 8 Mo de L3 en 2+2 ?

Si l'on faisait abstraction dans le graphique précédent du cas de 7-Zip, on pourrait presque se demander si l'on a réellement deux fois 8 Mo de cache L3 en configuration 2+2 ? Sachant que le L3 dans le CCX est découpée en "slice", accolé à chaque coeur, on pourrait penser que désactiver un coeur désactive le slice de L3 ?

Nous avons réalisé une fois de plus notre test de latence en fonction de la taille des accès pour nous en rendre compte. Et une fois de plus, nous n'avons pas vraiment eu les résultats auxquels nous nous attendions. On vous rappellera une dernière fois qu'il s'agit d'un bench beta et que ses auteurs n'ont pas pu le tester sur Ryzen. Malgré tout, nous estimons que les résultats sont suffisamment intéressants pour vous les montrer :

Pour plus de lisibilité, nous avons limité le graphique autour de la taille du cache L3 (il n'y a pas de différence avant, sur les L1/L2, et après, sur les accès mémoires qui ont toujours la même latence). Pour éviter la variabilité, nous utilisons des accès linéaires dans ce test.

Comme vous pouvez le voir, nous avons regardé la latence sur toutes les configurations de CCX disponibles sur notre Ryzen. En bleu, on retrouve les configurations ou un CCX est désactivé, et en orange les configurations à deux CCX.

Nous étions passés rapidement sur la question de la latence sur les accès à 6 et 8 Mo page précédente. Nous allons maintenant nous y intéresser.

En pratique, les accès au L3 devraient être a peu près identiques, autour de 13ns sur la totalité du cache. Si la valeur est supérieure, c'est que l'une partie des accès se fait non plus dans le L3, mais en mémoire centrale.

Dans le cas des modes ou un CCX est désactivé (en bleu), dès 6 Mo on s'aperçoit que l'on est déjà parti en RAM. On ne se focalisera pas trop sur la variabilité une fois que le seuil des 13ns est dépassé : il y a environ 5ns de variabilité sur la latence mémoire d'un accès sur l'autre. Nous pensons que cela vient du design qui veut que les deux contrôleurs indépendants soient reliés eux aussi à la data fabric. Il est possible que l'accès à l'un soit légèrement plus rapide qu'au second à partir d'un CCX, ou que la data fabric ajoute une variabilité.

Ce qui compte, c'est l'ordre de grandeur et clairement tout le L3 ne semble pas accessible de la même manière en fonction des configurations. Ca n'est pas forcément anormal, mais cela va avoir un impact sur notre comparaison au dessus, ce qui fait que l'on se doit de vous le signaler.

En pratique, le mode 4+0, pourtant plus rapide en jeu, est handicapé au moins dans ce test.

Pour ce qui est de la raison précise, nous éviterons de trop spéculer. AMD dans les informations communiquées à Hot Chips indique que son L3 est mostly exclusive, ce qui laisse penser qu'une partie du L3 est réservée pour certains usages. Cela n'a rien d'anormal.

Pour expliquer la différence entre les modes où l'on a un et deux CCX actifs, il est probable que soit cet espace réservé soit placée sur le second CCX, ce qui du coup libère totalement le L3 ou nous effectuons la mesure (l'espace réservé pourrait aussi être coupé en deux). Il semble probable également qu'une partie de chaque slice soit réservé pour le coeur auquel il est accolé, s'il est actif.

En pratique ces détails n'ont pas d'importance : on notera juste que le mode ou un seul CCX est actif, le 4+0 dans notre test au dessus, était en prime légèrement désavantagé sur ce point.

Pour résumer

On commence maintenant à y voir un peu plus clair. Oui, la communication entre les CCX à un coût, et selon les applications il n'est pas forcément anodin.

Pour les applications peu sensibles, l'effet est quasi nul, c'est le cas des logiciels d'encodage vidéo par exemple.

Pour d'autres c'est largement plus marquant, comme par exemple Battlefield 1 où l'on perd 20% de performances.

Si l'on résume ce que l'on a pu voir jusqu'ici :

• La latence mémoire de Ryzen est plus élevée que la normale, possiblement à cause du design à deux contrôleurs indépendants, reliés tous deux aux CCX via le data fabric.
• Un seul lien relie le CCX au data fabric et y passent toutes les communications : RAM, synchronisation L3, et PCI Express. Sa bande passante est plutôt faible considérant les besoins, et largement inférieure à la bande passante du seul L3.

Il peut y avoir par dessus des facteurs aggravants. Sachant que la communication entre les CCX est gourmande, balader les threads d'un CCX à l'autre (Windows 10 adore déplacer en permanence les threads !) peut aggraver la situation, même s'il est difficile de quantifier en quelle proportion.

Les limites techniques, au final, priment.

Cela ne veut pas dire que les choses ne changeront pas pour Ryzen à l'avenir. La solution la plus évidente serait un patch pour le scheduler de Windows, afin de limiter les déplacements des threads d'un CCX à l'autre. AMD et Microsoft avaient collaboré pour un patch pour Bulldozer à l'époque, on peut imaginer à nouveau un patch pour Ryzen. Reste qu'AMD s'est montré très prudent et n'a pas voulu nous confirmer travailler ou non sur la question.

Un autre changement qui pourrait se révéler salutaire pour les jeux est l'arrivée du "Game Mode" de Windows 10, dont l'une des particularités serait justement là aussi, de moins bouger les threads. Reste que même accrochés à un coeur, les communications entre les threads resteront tout aussi coûteuses lors de l'utilisation de données partagées. D'un titre à l'autre, l'impact du Game Mode, s'il en à un, sera forcément variable.

AMD met également en avant la bonne volonté des développeurs qui pourraient adapter leurs titres pour contourner les éventuelles limitations de Ryzen et en tirer de meilleures performances. Cela n'est pas forcément un argument creux, dans le sens ou les coeurs Zen pourraient être utilisés dans des consoles assez rapidement. Reste que l'argument semble surtout tourné sur les particularités du SMT d'AMD. Rien ne dit que ces futurs SoC pour consoles utiliseront le même data fabric, aux mêmes fréquences, et avec les mêmes limitations.

Quelle partie de l'écart sera rattrapée par ces éventuels correctifs, patchs, et modifications ? C'est en l'état impossible à dire et il faut rester très prudent sur ce que feront, ou non, les divers développeurs concernés. Les contraintes techniques évoquées comme la latence plus élevée de la mémoire, et le bus unique où passent les données RAM, cache L3, et PCI Express elles n'évolueront pas, en tout cas pas avant une future révision de Zen.