Reprise du message précédent :

 
On doit pas avoir la même valeur du travail, 400h c'est justement rien du tout, 1 semaine de travail pour 10 personnes, n'importe quel studio digne de ce nom peut se le permettre haut la main, ne serait-ce que pour montrer qu'ils ont bien opti le jeu partout. Et à terme, ce ne sera même plus un effort puisque les jeux seront directement optimisés pendant leur développement, donc si ça viendra à n'en pas douter.

Oui mais l'optimisation du code ce n'est pas uniquement ça. Par exemple les instructions AVX/AVX2 sur intel sont plus performantes que celle de Rysen. Par contre les instructions SSE2/SSE3/SSE4 sur Rysen sont très performantes. Cela implique qu'une application qui va utiliser préférentiellement les instructions AVX/AVX2 va favoriser les derniers CPU intel:

 
Avec le x265, on voit que Rysen n'est pas plus rapide si on utilise les instructions AVX2 et parfois même moins rapide, alors que le gain peut-être de l'ordre de 20% avec Intel. Même si les instructions AVX/AVX2 sont beaucoup plus rapide chez intel que chez AMD, on ne devrait pas voir de baisse de performance avec Rysen quand on utilise les instructions AVX/AVX2. Cela implique que le code x265 n'est vraiment pas bien optimisé pour Rysen.
 
Je pense que l'on doit avoir des problèmes de ce type dans la plupart des applications/jeux: simplement un  équilibrage dans l'utilisation des ressources pour Rysen qui n'est pas optimal car les applications sont optimisées pour Intel. Je pense que désactiver tout simplement l'utilisation des instructions AVX/AVX2 au profit des SSE2/SSE3/SSE4 (quand c'est possible) devrait permettre à pas mal d'application (ou de jeux) de fonctionner un peu plus vite avec Rysen, en attendant des optimisation spécifique pour l'architecture Rysen.

Ryzen, 'z'.

sagittaire :

- sur le graphique je ne vois pas de cas ou c'est moins rapide en AVX2 que sans AVX2
- il est normal que ce ne soit pas plus rapide en AVX2 sur Ryzen puisque les FP sont 128-bit contre 256-bit chez Intel, dès lors le passage au 256-bit de l'AVX2 n'apporte rien alors que chez Intel la puissance de traitement est potentiellement doublée par rapport à l'AVX et au SSE

Pour ceux qui lisent pas le japonais (je pense qu'il y en a ), les barres claires sont les cas avec AVX2 off  
 

Peut etre. Apres on peut aussi dire que Ryzen n'est pas optimisé pour les encodeurs x265 actuels.
 

En dehors de l'encodage a mon humble avis il n'y a pas enormement de softs utilisant AVX2. A ma connaissance pas de jeu en tous cas.

 
pour un encodage x265 en 8bits ou x264 8 bits c'est le cas:

 

 
De plus les instructions AVX2 sont, je pense, tout de même censées faire gagner des cycles CPU même en 128 bits car elles permettent des optimisations bien plus avancées que les instructions SSE2/SSE3 ou SSE4?

Oui quand tu monte en version il y'a d'autres modifications mais entre AVX et AVX2 il n'y a que globalement que le 256-bit et le FMA.
 
Depuis HSW chez Intel en gros on peut avoir 2 FMA, 2 FMUL ou 1 FMA/FMUL+FADD par cycle. C'est aussi possible de faire deux additions par cycle mais l'unité FMA aura une latence > à l'unité FADD.
Avec Ryzen chez AMD on peut avoir en 128-bits 2 FMA ou 2 FADD+2 FMUL, et en 256-bits 1 FMA ou 1 FADD + 1 FMUL.
 
Donc en fonction de la charge liée au jeu d'instruction forcément ça ne réagit pas de la même façon.

bien joué AMD

le fond du soucis proviens des compilateurs, la plus part des dev ne s'en preocupe pas trop et utilise du compilateur intel qui optimise pour les proc intel sur la base que c'est les processeurs les plus nombreux sur le parc pc. Bilan les perf AMD sont dépréciés et cela donne un cercle vicieux où AMD à l'air moins performant donc moins acheté...

 
Ben quoi ? J'ai un Core 2 Duo E8400 avec une 4870 1G et j'arrive à me marrer sur rFactor2, Colin Mc Rae, Empire Total War, Silent Hunter 3-4, Far Cry 2 et last but not least, le démineur !!
Un peu de respect pour les antiquités !!

Source ? C'est plutôt celui de MS qui est utilisé. Pour celui d'Intel par le passé nous avions vu par le passé qu'il apportait des gains par rapport à VS/GCC sur Intel... et AMD (certes moins) !
 
Par contre le souci est au niveau de la détection auto des archis pour les instructions avancées qui ne marche qu'avec les Intel.

Et tu n'arrives pas à faire tourner ashes of the singularity a 144 FPS avec ?  

 
Ca à l'air en fait d'être très variable:
https://forum.doom9.org/showthread. [...] ost1801899
 
Ce qui rend les comparaisons très difficile: la compilation optimale pour le CPU X ne sera plus optimale pour le le CPU Y.  
A la limite pour tirer le max de chaque archi, faudrait tester avec un profil de compilation différent pour chaque CPU.
 
D'après mes propres test, VS 2017 est en effet très performant pour les CPU AVX/AVX2 mais GCC 7.0 reprend la main en SSE2/SSE3/SSE4.
GCC 7.0 semble obtenir des performances beaucoup plus homogène que VS 2017, en tout cas pour une compilation x265 avec mon CPU.
Par contre ICC semble un peu largué sur les compilations x265.

@zuf : pas essayé.. C'est bien ce truc ?

 
Puisqu'on source via twitter, un fil sur twitter indique qu'une correction /notable/ du patch pour AOTS serait finalement l'abus des écritures non-temporelles (qui bypassent les caches L1 et L2). Généralement utilisées pour du streaming (write combining) vers ou de la mémoire du GPU.
 
Il semble qu'elles causent un flush du cache, justement, sur RyZen.