COMPTOIR
  
register

Le 5800X3D, sous Linux, il se débrouille comment ?

 

Ça n’est désormais plus un secret, le 5800X3D poutre bien sa maman en jeu, pour des gains éparses en applicatif variant grandement en fonction du programme ; et, si les performances d’origine ne vous suffisent pas, quelques cartes mères aventureuses vous permettront de l’overclocker. Cependant, nos tests ont été réalisés en majorité sous l’OS fenestré : qu’en est-il pour le manchot ? Hé bien, pour le savoir, le confrère Phoronix s’est attelé à la tâche du test comparatif 5800X versus 5800X3D (voilà qui rappelle des souvenirs), le tout sous un Ubuntu 22,04 au bon goût du noyau 5.17.

 

Surprise : mis à part Deus Ex (+36,4 %) et Shadow of the Tomb Raider (+29,8 %), les gains ont été minimes en jeu, voire négatifs ! En tout et pour tout, le 5800X3D ne finit en moyenne géométrique qu’un maigre pourcent devant som aîné : pas vraiment de quoi justifier le surcoût. De quoi en déduire que les titres sont tellement peu optimisés pour le pingouin que même l’ajout massif de cache n’y change rien ? C’est malheureusement fort probable, bien que Windows soit également sujet à ce même phénomène selon le moteur employé.

 

linux

 

En revanche, en applicatif, le constat est radicalement différents : si certaines tâches se voient peu accélérées comme le rendu 3D, ce n’est pas le cas du calcul scientifique, du machine learning ou encore de la compression et de l’encodage vidéo AV1, ce qui résulte en une moyenne de 3,9 % supérieure pour le 5800X3D. Pas encore de quoi convaincre notre Tomiche de passer son PC de stream sous Linux, mais définitivement de quoi donner du grain à moudre aux amateurs de libre à la recherche d’une nouvelle configuration professionnelle. À vous de voir !

 

 
Ryzen 7 5800X3D face avant

 

Un poil avant ?

NVIDIA reprendrait l'avantage en gravure avec Lovelace

Un peu plus tard ...

EXPO au lieu de RAMP pour la DDR5 avec les Ryzen 7000 ?

Les 8 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Nicolas D., le Mardi 26 Avril 2022 à 14h49  
Suite: dans la pratique, le découpage en sous-matrices permet d'arriver assez facilement à des puissances de calculs proches de la puissance crête de la machine, surtout sur des matrices carrées. Mis à part sur les petites tailles où les effets d'initialisation se sentent, une biblio optimisée fera globalement un bon taf.
Au passage, cette régularité des calcul est d'ailleurs ce qui est reproché à Linpack (et un bon tas de benchmarks synthétiques) comme mesure de la performance d'un supercalculateur : c'est trop facile à optimiser en hard pour représenter un cas d'usage moyen et un indice de performance fiable pour toutes les utilisation possible (c'est bien pour ça que nos tests CPU du comptoir sont si longs !).
par Nicolas D., le Mardi 26 Avril 2022 à 14h45  
par Ragot de Markov de Bretagne, le Mardi 26 Avril 2022 à 07h04
Effectivement, ça doit dépendre de l'optimisation architecture materielle versus logicielle. Un beau petit graphe ordonnée=temps de multiplication, abscisse=taille de la matrice (carrée) permettrait de voir l'apport à archi logicielle constante, genre sous fortran. Ca pourrait expliquer les meilleurs gains en jeu sous windows pour les sous-taches IA genre pathfinding à faire tourner en fond du graphisme ?
À mon avis, ce genre d'expérience est intéressant dans la théorie mais difficile à réaliser dans la pratique. Tout dépend ce que tu veux tester en fait : est-ce que tu veux étudier le comportement d'un processeur sur une multiplication de matrice faite quasi-naïvement et voir comment il se débrouille ? Dans ce cas là, on verra des effets de seuil assez marqués selon la taille des caches. Pour une implémentation plus maligne, cela va dépendre énormément de la taille choisi pour décomposer le produit de matrice en sous-matrice (cf crénelages ici).

"les meilleurs gains en jeu sous windows pour les sous-taches IA genre pathfinding à faire tourner en fond du graphisme" : Peut-être sur les titres natifs linux qui utilisent a priori des bibliothèques différentes que celles pour Windows, pas contre sous Wine/Proton le code est exécuté nativement, donc impossible que le souci vienne de là (par contre, le noyau et les appels systèmes peuvent polluer plus ou moins le cache, menant à des performances différentes.
par Nicolas D., le Mardi 26 Avril 2022 à 14h35  
par ockiller en Auvergne-Rhône-Alpes, le Mardi 26 Avril 2022 à 06h50
À propos de la corrélation entre impact d'un plus gros cache et le niveau d'optimisation d'un jeu, j'aurais tendance à dire l'inverse . Un bon moteur qui prend soin des accès mémoire, avec des données bien packées, des accès séquentiels et cohérents, idéalement les prefetchers feraient tout le boulot et on n'aurait même pas besoin de mémoire cache. C'est l'idée mais je néglige peut-être quelque chose d'important...
C'est un raisonnement totalement valide aussi, tout dépend de l'empreinte mémoire du boulot demandé et du profil des accès : en accès aléatoire (par exemple parcours d'une liste chaînée), difficile d'optimiser quoi que ce soit, mis à part en remplaçant totalement la structure de donnée (l'exemple est pourri, mais je veux dire que certaines applications ont par essence des accès irréguliers donc un profil mémoire qui bénéficie au cache). Cependant, vu la diversité des CPU et des caches (sur Skylake, le L3 maximum c'est 8 Mio (6700K), sur Alder Lake on est plus sur 35 (12700K) et 96 ici), difficile d'optimiser pour tout le monde ; d'autant plus qu'un jeu prend bien plus de 100 Mio de RAM (il me semble qu'on est sur quelques gigas) : il y aura forcément des données non cachées à attendre, même avec tout le soin du monde .
par Superubu, le Mardi 26 Avril 2022 à 13h15  
par Ragot de Markov de Bretagne, le Mardi 26 Avril 2022 à 07h04
Merci Nicolas pour ces compléments. Effectivement, ça doit dépendre de l'optimisation architecture materielle versus logicielle. Un beau petit graphe ordonnée=temps de multiplication, abscisse=taille de la matrice (carrée) permettrait de voir l'apport à archi logicielle constante, genre sous fortran. Ca pourrait expliquer les meilleurs gains en jeu sous windows pour les sous-taches IA genre pathfinding à faire tourner en fond du graphisme ? Bref, un petit taf et un petit papier pour des gens de l'INRIA pointant le type d'optimisation logiciel à proposer ?
Ça devient pointu pour le commun des mortels votre affaire!..Ceci dit je ne me plains pas, j'apprécie toute connaissance supplémentaire d'où qu'elle vienne...Tant que je suis capable de l'assimiler
par Ragot de Markov de Bretagne, le Mardi 26 Avril 2022 à 07h04  
Merci Nicolas pour ces compléments. Effectivement, ça doit dépendre de l'optimisation architecture materielle versus logicielle. Un beau petit graphe ordonnée=temps de multiplication, abscisse=taille de la matrice (carrée) permettrait de voir l'apport à archi logicielle constante, genre sous fortran. Ca pourrait expliquer les meilleurs gains en jeu sous windows pour les sous-taches IA genre pathfinding à faire tourner en fond du graphisme ? Bref, un petit taf et un petit papier pour des gens de l'INRIA pointant le type d'optimisation logiciel à proposer ?

par ockiller en Auvergne-Rhône-Alpes, le Mardi 26 Avril 2022 à 06h50  
À propos de la corrélation entre impact d'un plus gros cache et le niveau d'optimisation d'un jeu, j'aurais tendance à dire l'inverse . Un bon moteur qui prend soin des accès mémoire, avec des données bien packées, des accès séquentiels et cohérents, idéalement les prefetchers feraient tout le boulot et on n'aurait même pas besoin de mémoire cache. C'est l'idée mais je néglige peut-être quelque chose d'important...
par Nicolas D., le Lundi 25 Avril 2022 à 23h49  
par Un ragoteur sans nom de Bretagne, le Lundi 25 Avril 2022 à 18h48
En calcul matriciel lourd, ça doit poutrer encore plus ?

Larrabel fait une multiplication matriciel dans "oneDNN 2.6" mais il n'indique pas la taille de la matrice. Je serai curieux de voir si le 5800X3D plafonne et si oui, à quelle taille de matrice ? Ou bien si il reste supérieur quelque soit cette taille de matrice ? Un travail pour Nico & Eric ?
Si on suppose que c'est de la matrice carrée (ce qui a de fortes chances d'être le cas en CNN mais pas forcément en DNN dense) il suffit de regarder l'empreinte mémoire : 3*n^2 (tu gardes les deux matrices source et la destination), en supposant que ce soit de la demi précision ça donne 2 octets par élément donc sur 96 Mio de cache c'est 4096 x 4096 élements pour que ca reste totalement dans le cache. Dans la pratique il est souvent possible de packer un peu plus vu les politiques malignes de remplacement mais pas toujours. Usuellement, on "tile" le code de manière à ne faire que des calculs de sous-matrices dont la taille rentre dans le cache pouis combiner, donc les performances sont en général pas dégueues. Je ne serais pas étonné que oneDNN (Intel) soit opti pour les tailles de cache Intel et donc que le 5800X se débrouille particulièrement mal là dessus de base, alors que le 5800X3D surpasse ces limitations. C'est possible aussi que toute la matrice rentre dans le cache, alors qu'auparavant non (ca expliquerait le cas où les gains sont quasi d'un facteur 3).
par Un ragoteur sans nom de Bretagne, le Lundi 25 Avril 2022 à 18h48  
En calcul matriciel lourd, ça doit poutrer encore plus ?

Larrabel fait une multiplication matriciel dans "oneDNN 2.6" mais il n'indique pas la taille de la matrice. Je serai curieux de voir si le 5800X3D plafonne et si oui, à quelle taille de matrice ? Ou bien si il reste supérieur quelque soit cette taille de matrice ? Un travail pour Nico & Eric ?