**Avec des modèles très proches à 8, 6 et 4 coeurs, la gamme Ryzen offre beaucoup de choix. Que font gagner en pratique ces coeurs supplémentaires ? Et quel est l'impact du SMT
 
Lire la suite ...

 
En conclusion, les R7 sont un pari sur l'avenir  

Très bon article !!

Et donc AMD sur la bonne voie !

Mouais, beaucoup d'applications modernes tirent bien parti du multi core, mais j'avoue que j'appréhende certains usage avec de vieux logiciels ou des application qui ne peuvent pas tirer parti du multithread qui affichent des performances très dégradées parfois à peine au niveau de Ivy Bridge...
 
Les résultats ici sont très similaires au précédent focus qui s'intéressait à l'influence du nombre de coeurs :
 
Certaines applications/jeux tirent un avantages incontestable de l'augmentation du nombre de threads, mais d'autres y sont assez insensible, et les performances dans ce domaine évoluent très lentement !

Les R 1600(X) vont faire un carton !
Ils représentent l'équilibre même. Tout ce que l'on a besoin pour un PC.
Un rapport puissance/polyvalence/prix excellent !

 
Ils ont du chemin à parcourir encore!

Merci pour cet article, excellent

gg l'article !

Excellent esprit de synthèse, merci

 
j'apprécie ce passage en connaisseur. Cependant, en 2160p, le x265 se comporte exactement comme le x264 au niveau du threading sur des 8C/16T.
 
Par contre les gains apportés par le SMT sont absolument monstrueux, l'impact est le même avec l'HT?
 
a noter qu'avec le x264, vous pouvez choisir de modifier le nombre de thread logiciel (ils sont réglés par défaut à 3N/2 avec N le nombre de threads logique CPU) avec la commande --threads. Il est à noter que les augmenter au délà de la valeur par défaut peut augmenter encore la vitesse d'encodage (la perte de qualité est négligeable à moins de 0.1%) et on peut aller jusqu'à 256 threads logiciel. un petit test ici avec mon i5-3550 4C/4T avec une source 720x304:
 
1 threads: 28.44 fps (25% CPU Charge)
2 threads: 52.03 fps (50% CPU Charge)
4 threads: 77.37 fps (75% CPU Charge)
6 threads: 101.43 fps (95% CPU Charge) -> valeur par defaut
8 threads: 103.90 fps (99% CPU Charge)
16 threads: 106.16 fps (100% CPU Charge)
32 threads: 107.98 fps (100% CPU Charge)
64 threads: 109.33 fps (100% CPU Charge)
128 threads: 108.95 fps (100% CPU Charge)
256 threads: 109.66 fps (100% CPU Charge)

 
AMD doit encore progresser quand même sur les perf jeux (90% des forumeurs) , et également niveau overcloking.
 
je zappe cette génération, on verra Zen 2

Ça dépend des cas, sous x264 c'est 20% plutôt chez Intel. Ce qui ne veut pas dire forcément que l'HT est moins efficace dans ce cas, il y'a peut être simplement moins de temps mort à combler au niveau des cœurs.

Merci pour l'article, on voit que ceux qui avaient misés sur le nombre de cœurs/threads ont bien fait, les jeux profitant désormais de plus de 4 threads, et donc de l'HT sur les 4 cœurs.

Intéressant ton test, le choix de 3N/2 me paraissait surprenant, mais quand on voit que ça passe de 77 à  101 FPS (+31%), c'est impressionnant.

Ça veut aussi dire que pour maximiser les performances d'un 8C/16T sur ce type de charge, il faut pouvoir lancer 24 ou 32 threads différents. Sur de la compression vidéo, c'est simple, mais sur des jeux, on est pas encore près d'exploiter à 99% les 8C/16T.

Parler en nombre de thread pour un jeu ce n'est pas vraiment pertinent, ils seront forcément beaucoup plus asymétriques en terme de charge. Ce qui compte c'est autant le nombre de thread que le bon découpage de la charge entre eux, avoir 10 thread mais avec 1 qui fait la moitié de la charge CPU c'est ballot

C'est sûr, mais ça montre la difficulté pour profiter de l'HT sur un 8 cœurs : il faut en gros que le thread le plus lourd représente moins de 1/8 de la charge totale.

Votre article prépare assez clairement l'arrivée des Skylake-X
 
Est-ce que Intel tentera de contrer AMD en baissant le tarif d'entrée de leur nouvelle plateforme de riches ?

 
@hardware.fr
Il me semble que les i3 sont la seule exception où le ht est bénéfique pour l'instant.
Pour le i7 7770k vs i5 7600k (ainsi que pour les générations précédentes), il me semble que la différence de performances est majoritairement due à la différence de cache 8 Mo(i7) vs 6 Mo(i5).
 
Plusieurs benchmarks que j'ai vus vont dans ce sens, de façon indirecte :
i7 6700k (4c) et i7 3770 (4c) : https://www.techpowerup.com/forums/ [...] st.219417/
i7 5930k (6c) : https://www.youtube.com/watch?v=X1Hf88mThhc
 
Vous avez vous-même montré lors du test des ryzen r7 que le ht était non bénéfique en utilisation gaming pour un i7 6900k (8c) : http://www.hardware.fr/articles/95 [...] mt-ht.html
 
Un i7 4c/8t vs i7 4c/4t à fréquence égale donnent strictement les mêmes performances in game, dans la très grande majorité des jeux actuels en tout cas.
Il semble donc que pour une utilisation majoritairement gaming, le surcoût entre un i7 et un i5 est très injustifié (260 vs 400 euros entre i7 7700k et i5 7600k) puisque on paye uniquement la différence de cache (6 Mo vs 8 Mo), puisqu'à ma connaissance, i5 et i7 ne diffèrent que par la quantité de cache.
 
Pour en être sûr, ce serait vraiment bien si vous pouviez faire un test i7 7700k 4c/4t/8Mo-de-cache vs i5 7600k 4c/4t/6Mo-de-cache, à fréquence égale bien sûr sur quelques jeux de votre choix.
 
J'en profite aussi pour vous poser la question : pourquoi Intel fabrique des i5 qui n'ont pas 8Mo de cache ?
- Est-ce pour récupérer les déchets de fabrication ? Mais ils pourraient faire un seul i5 4c/4t bridé par le cache et moins cher que les autres i5.
- Est-ce pour mettre en avant les i7 (justifier leur prix) ? Donc ce serait un bridage logiciel pour la majorité des puces i5 en désactivant 2 Mo de cache.

Soit tu n'as pas lu l'article, soit tu ne l'as pas compris.
 
Il est normal que l'HT n'apporte rien en gaming sur un 8 cœurs Intel, il en vas de même chez AMD.
 
Le gain lié aux 6/8 Mo est faible et il y'a bien un gain entre un i7 configuré en 4C/4T et 4C/8T
 
Pour le bridage des i5 il n'y a pas de raison technique, il y a sûrement un peu des deux choses que tu envisage.

 
C'est clair que les jeux comme F1 2016 ou Watch dogs 3 semblent clairement sous-optimisé. Ils ne doivent pas bien identifier les threads (physique et logique) et au lieu de faire une répartition de la charge en priorité sur les cores physiques et ensuite sur les cores logiques si besoin, ils balancent la charge de manière indifférenciée sur tous les threads, en tout cas pour Ryzen. Un patch pour résoudre ce problème ne devrait pas pendre 400H de codage. Surtout quand on voit qu'il suffit d'interdire l'accès aux cores logiques pour obtenir immédiatement un gain de ~7% sur un 8C/16T.

Pour Watch Dogs (2 !) ce n'est pas spécifique à AMD c'est pareil sur un Intel. F1 par contre si comme deja évoqué.

 
Merci de m'avoir répondu.
J'ai bien compris que l'article montre que les Ryzen 4 coeurs ont de meilleures performances gaming SMT on vs SMT off (et même les 6 coeurs) contrairement aux 8 coeurs, et que l'article fait en conclusion un parallèle avec les i7 d'intel.
Oui on est bien d'accord sur ce point.
 

 
C'est ce point dont je parle.
Est-ce que tu as quantifié cela sur plusieurs jeux ? C'est par curiosité seulement que je pose cette question, si toi ou d'autres ont vu cette différence je ne le conteste pas, mais ça m'intéresse.
Le lien auquel j'ai fait référence est un test i7 6700k 4c/8t vs i7 6700k 4c/4t en janvier 2016 : https://www.techpowerup.com/forums/ [...] st.219417/
Kaby Lake devrait se comporter comme Skylake étant donné que c'est principalement un speed bump.
Est-ce qu'il y'a eu de l'optimisation logicielle qui s'est faite depuis cette période ?
Est-ce que les jeux dont tu parles ne font pas partie de cette liste ?
Ses 21 jeux sont :  
Alan Wake American Nightmare, Arma 3, Batman Arkham Origins, Battlefield 4, Bioshock Infinite, Call of Duty Advanced Warfare , Company of Heroes 2, Crysis 3, Dragon Age Inquisition, F1 2015, Far Cry 4, Hard Reset , Hitman Absolution, Max Payne 3, Metro Last Light Redux, Rainbow Six Siege, Serious Sam 3, Starcraft 2 Legacy of the Void, Tomb Raider , Watch Dogs, Witcher 3 Wild Hunt, et la tendance est unanime.
C'est uniquement par curiosité hein

Merci pour l'article! Trés intéressant! Je vais passer sur Ryzen (je suis actuellement sur FX 8350). Je me pose beaucoup de questions sur mes choix (quel processeur, quelle carte mère, quelle RAM...) et vos articles éclaircissent beaucoup ma réflexion. Merci encore à l'équipe HARDWARE.FR
 
Pour les grognons, chacun pense ce qu'il veut mais sachez que le processeur parfait n'existe pas ni chez amd ni chez intel. C'est comme pour tout, il faut faire des compromis et une fois de plus chacun fait les siens et il faut le respecter.
 
Sans être pro AMD, je salue les progrés manifestes réalisés par rapport aux FX même si on est loin de dépasser les processeurs intel. Cette concurrence apporte beaucoup de bien pour les consommateurs (sur les plans performance et prix).

Regarde la différence entre 2500K et 2600K par exemple dans notre protocole dans le test des r5
Sachant qu'il y'a environ 5% de gain hors HT entre 2500K et 2600K du fait de la fréquence et du cache à retrancher (j'ai déjà mesuré cet écart lié au cache par le passé mais ne me souviens pas si on a publié quelque chose là-dessus), ce qui fait que sous GTA V par exemple sur Intel l'HT entraîne une légère perte de perf.

Pour ce qui est des tests de Pierre Paul Jacques qui ne montrent pas de gain, que veut tu que je te dises ? On indique les jeux, scènes et réglages utilisés. Ces jeux sont p-e incapables de tirer partie de plus de 4 cœurs, testés en condition gpu limited (scene trop light et / ou réglages trop élevés pour le gpu)... je ne vais pas analyser tout son protocole on passe assez de temps à établir le notre

Comment les jeux se mettent à découvrir la topologie d'un processeur (F1 2016) ? Je veux dire normalement ils doivent créer n threads et laisser l'os les dispatcher sur les coeurs logiques. C'est pas très propre comme méthode de programmation, non ?

 
Ah d'accord je vois ce que tu veux dire.
Donc en gros le gain lié au cache est de l'ordre de 5-10% et c'est à peu près constant quel que soit le jeu, par contre s'il y'a une différence de plus de 10% entre i5 et i7 à fréquence égale (i5 2500k et i7 2600k ont quasi la même fréquence) c'est lié à autre chose que le cache, en l'occurence l'HT si je suis ton raisonnement.
Le cas de Watch Dogs 2 montre à peu de choses près le gain hors HT (comme tu l'appelles ).
Si tu as mesuré cela sur plusieurs jeux différents je pense que tu est bien placé pour faire la part des choses des gains du i7 vs i5 : gain hors HT (cache), gain lié à l'HT.
Comment réconcilier les 2 tests ? C'est une autre question, à voir du côté de la méthode différente qui montrerait des résultats différents.
 
Bref, c'était intéressant merci, toujours est-il qu'un petit test i7 HT off vs i5 à fréquence égale sur plusieurs jeux (on se doute de l'effet bénéfique sur les applications) serait un très bon complément à ce test que vous avez publié pour les ryzen ! Ce serait cool si ça pouvait être fait, mais bon je ne peux qu'espérer !

Super test, merci !
 
Par contre, depuis les tests de Ryzen; je CONSTATE plusieurs choses:
 
- Je ne vois plus personne tout d'un coup dire que les jeux ne gèrent que 2 à 4 Cores Maximum, et que l'HT est inutile.  
 
Quand bien meme les anciens protocoles de tests depuis 2013 montraient que la gestion des cores au-dessus de 4 et de l'HT etait de plus en plus apparente (merci au travail d'HFR -tests des CPU LGA 2011- qu'ils ont ignores).
 
- Les Core I7 6700K et 7700K deviennent magiquement les choix no 1 pour jouer; alors qu'avant Ryzen, c'etait "inutile" et on conseillait des Core I5 6600K et 7600K y'a pas plus de quatre mois de cela.
 
En temoigne les nombreux debats qu'on peut trouver sur le net a ce sujet...
 
- Personne n'a aussi plus magiquement l'air de se soucier de la chauffe et de la consommation, alors que l'I7 7700K consomme autant qu'un octo-core SMT qu'est le R7 1700X.
 
Seul l'I5 7500 fait mieux que Ryzen en ce qui concerne l'efficacite energetique, Ryzen l'emporte haut la main EN MOYENNE par rapport a Intel.
 
Pour ce qui est de la chauffe des I7 6700K et surtout I7 7700K, je n'en parlerais meme pas; je n'ai pas envie de Biaffin made by Intel.
 
 
A bon entendeur !
 
 
 
 
 
PS:
 
En tout cas, ceux ayant investi dans un 4 cores HT et au-dessus depuis Nehalem seront plus qu'heureux d'apprendre que leur plate-forme est toujours valide aujourd'hui.
Soit au moins 10 ans de rentabilite CPU, un record !
C'est un joli coup de maitre de leur part car ils peuvent attendre avec un bon OC des familles les CPUs gerant la DDR5.
 
Du coup, le meilleur choix pour au moins le moyen-terme aujourd'hui est sans conteste un R7 1700, a overclocker bien sur.
Car malheureusement, c'est bien les consoles qui dictent le marche du jeu video, ces dernieres etant elles-memes... equipes d'octo-cores.
 
PS2:
 
Aussi, je m'attends a ce que les memes personnes qui m'ont conspue de troll il y a 3 mois de le refaire ici, alors que meme HardwareFR vous dis que l'ere des quad-cores est finie dans ce focus.
 
Ces personnes etant "par coincidence", les memes court-termistes/les "y'a pas de preuve, donc on reflechis pas"/ les kikoos RGB only "hardcore gamers" et ceux qui ont conseille a bon nombre de futurs decus un Core I5 il y a pas plus de 4 mois de cela.
 
L'histoire Core 2 Quad inutile vs Core 2 Duo vient encore de se repeter ici, il y en a qui n'apprendront jamais...
 
Je ne peux -pour citer deux membres specialement-, "que me rejouir de voir combien [vous avez] tort" et qui "ne savent plus vraiment de quoi ils parlent".
Bisous, et a dans 20 ans plutot !
 
 
@HFR: Ceci est mon dernier post sur ce topic, etant donne que ceux qui me conspuent ne savent pas s'arreter quand il s'agit de screeching.

Non non, il y a des API pour détecter le nombre de coeurs. Il y a aussi des API Windows qui indiquent la présence de coeurs logiques, mais ca F1 2016 ne semble pas les utiliser.  
 
Ils semblent utiliser une détection de plus bas niveau, probablementles registres CPUID du processeur pour vérifier la présence ou non d'HT. Vu que leur moteur est multi plateforme, taper des API de bas niveau n'est pas une mauvaise idée, c'est juste qu'ils ne vérifient pas encore pour le SMT sur des puces AMD. Ca sera vite corrigé on imagine mais c'est souvent comme ca quand quelque chose de nouveau arrive, il peut y avoir des bugs. L'HT au tout début était aussi très très peu bénéfique dans le jeux chez Intel avant que les développeurs s'adaptent. Ici c'est juste détecter correctement, ce qui prendra peu de temps.  

Excellent, merci pour l'analyse.

Bon je me suis penché sur le problème de compression 7zip. Je trouve curieuse cette histoire de vitesse de compression qui serait liée à la vitesse mémoire. D'autant plus que le benchmark intégré à 7zip ne le prend pas du tout en compte.
 
7zip est une application qui s'utilise aussi en ligne de commande, ce qui est bien plus pratique pour accéder aux réglages avancés et pour automatiser les tests dans un fichier batch. Pour ce test j'utilise un dossier qui me sert à faire un benchmark x264 et x265 que vous pourrez trouver sous forme compressée ici:
http://jfl1974.free.fr/Benchmark/Benchmark.zip
 
1) influance de la qualité de compression avec l'algo LZMA2 par défaut
 
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark.7z C:\Users\JFL\Desktop\zip\Benchmark -bt -mx0
 
- mx0 est un mode non compressé et mx9 correspond à la qualité maximum de compression
- la taille du dossier non compressé est donc de 810 MB
- pour N thread actif, la charge maximum sera de N*100%. Ici avec mon i5-3550, la charge max est donc de 400%.
 

 
On constate donc:
- plus la qualité de compression augmente, plus le temps de compression est long
- plus la qualité de compression augmente, plus la taille de l'archive compressée diminue
- la qualité mx9 permet d'obtenir un taux de compression supérieure à celle par défaut dans le gui 7zip (510 197 Ko vs 512 324 Ko)
 
Bon c'était attendu mais on constate aussi que le taux de charge CPU va diminuer avec la qualité de compression. Plus la qualité de compression augmente et plus l'efficacité du MT sur l'algo LZMA2 sera faible. 7zip à un maximum d'efficacité de charge CPU avec la qualité mx4 sur mon i5-3550.
 
2) Influence du threading logiciel avec l'algo LZMA2 par défaut
 
L'application en ligne de commande mmt permet aussi de régler le nombre de threads logiciels actifs lors d'une compression
 
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark.7z C:\Users\JFL\Desktop\zip\Benchmark -bt -mx9 -mmt=1

 
bon ça n'aide pas beaucoup apparemment. On obtient une vitesse max avec 4 thread logiciel sur mon i5-3550 4C/4T.
Mais je remarque une chose, l'application semble se bloquer quand elle compresse certains fichiers du dossier, avec une brusque perte de l'efficacité MT.
 
3) Une manipulation intéressante.
 
Pour essayer de casser la structure de fichiers du dossier à compresser, je stocke le contenu du dossier dans un fichier .zip non compressé et ensuite je vais le compresser LZMA2 mx9.
 
7z.exe a C:\Users\JFL\Desktop\zip\test\Benchmark.7z C:\Users\JFL\Desktop\zip\Benchmark -bt -mx0 -mmt=1
7z.exe a C:\Users\JFL\Desktop\zip\Benchmark1.7z C:\Users\JFL\Desktop\zip\test -bt -mx9 -mmt=1
 
Et oh surprise on obtient ça:
 

 
Donc si on casse la structure du fichier du dossier en le stockant dans un fichier zip non compressé que l'on compresse ensuite, et bien on obtient de bien meilleures perfs en terme de vitesse de compression et d'efficacité du MT au prix d'une très légère perte de qualité de compression  (505 MB vs 499 MB). Et j'observe la même chose si je fait ça avec le gui de 7zip.
 
Alors pour être clair: je n'ai strictement aucune idée de pourquoi ça fait ça, si c'est un bug, si c'est reproductible sur une autre machine ou si ça peut expliquer le mauvais support du MT dans le test de HFR alors que le benchmark intégré est proche du max théorique. Mais en tout cas j'observe que c'est beaucoup plus rapide de faire une compression entropique via 7zip avec cette méthode sur ma machine.

Plus qu'à attendre 2 ou 3 mois que les drivers sortent, que les bugs se corrigent et que les prix baissent et profiter.

Tu peux trouver ça curieux si çà te fait plaisir, mais on l'a testé ici (et pleins de fois avant) et c'est net : http://www.hardware.fr/articles/95 [...] inrar.html

Le bench intégré n'a aucun intérêt et n'est pas comparable.

La mémoire joue un rôle important à cause des dictionnaires, cf la description de l'algo : https://en.wikipedia.org/wiki/Lempe [...] hm_details

Tu as redécouvert les tarball : https://en.wikipedia.org/wiki/Tar_( [...] ssed_files

 
Comme dis par C-Wiz pas mal de temps perdu pour vérifier quelque chose qui l'est déjà J'ajoute que chez Intel le passage de 6C/12T à 8C/16T fait gagner 30% de performances sur notre protocole, proche des +33% maximums théoriques, là ou chez AMD c'est donc 20%.
 
Sinon observations intéressantes à ceci près que les fichiers à compresser auront pas mal d'influence, on a des taux d'utilisations CPU bien plus importants que les tiens par exemple. Dans le cas de tes fichiers le zip non compressés doit probablement permettre à l'algo de LZMA2 de contourner certaines difficultés qu'il a de base sur ton répertoire.  

 
oui c'est ce qui n'a fait démarrer le test mais j'ai ensuite dérivé vers le support du MT. Pour cette raison que je poste le commentaire ici ...
 

 
Oui mais les tarball c'est plutôt des containers qui permettent de stocker des fichiers et de les décrire (un peu comme les containers vidéos avec des streams video, audio, sous-titres ... etc etc).
 
Mais ce qui est ici curieux, c'est que la compression du dossier est beaucoup moins efficace que si tu passes par un dossier.tar.
 
Ton lien n'explique pas pourquoi la compression d'un tel fichier est plus efficiente en terme de support du Multithreading?
 
pourquoi 7zip ne fait-il pas nativement et de façon transparente la conversion dossier -> dossier.tar -> dossier.tar.zip si c'est plus efficace (en tout cas sur mon système)?
 
De plus je constate qu'augmenter le nombre de threads logiciel au delà du nombre de threads logique permet de se rapprocher du max théorique N*100% uniquement si on passe par un fichier dossier.tar intermédiaire.
 
 

 
Ce n'est pas ce que je teste ici. Ou si peut-être avec la qualité mx qui utilise des dictionnaires de plus en plus grands (la RAM nécessaire augmente chez moi si mx augmente)
 
Mais ensuite je fais le test dossier -> dossier.tar -> dossier.tar.zip VS dossier -> dossier.zip à qualité de compression égale (mx9 et ram nécessaire constante même si le nombre de thread logiciel augmente), le support du MT est bien meilleur dans le premier cas avec un ratio proche du max théorique si on compare la compression sur 1 thread et sur 6 threads (avec mon i5-3550 4C/4T).

Mais non, c'est de la concaténation de fichiers les uns derrière les autres, strictement rien à voir.

C'est pour ca que tar existe, il est toujours plus efficace du point de vue du filesystem de travailler sur un fichier plutôt que X petits. Avec les SSD l'équation change mais pas totalement, accéder a 100000 fichiers de 1 Ko est toujours massivement plus lourd que un fichier de 100000 Ko.

...
Si c'est ce que tu veux faire il existe des utilitaires qui le font, c'est littéralement le principe des tar.gz/tar.xz. L'inconvénient est que l'archive n'est plus facilement modifiable. Supprimer, remplacer un fichier devient beaucoup plus long et compliqué, alors que l'opération est triviale en ayant compressé séparément les fichiers. Idem pour décompresser un seul fichier de l'archive etc...

Moi qui voulais partir sur un cpu 4c/8t à fréquence élevé comme le 6700k ou 7700k avec mon nouvel écran 144hz hmm.
ça à l'air plutôt risqué de partir là dessus même si cela m'offrirais sans doute une meilleure expérience de jeu qu'un R5 1600.  
Vous me conseillez de faire quoi ?

 
ben un container vidéo ça fait aussi ça, découper et ordonner les stream video et audio dans dans blocks consécutifs pour les rendre facilement lisible, notamment par des lecteurs optiques avec de long temps d'accès. Mais c'est pas le débat.
 

 
Oky là je comprend mieux l'utilité des tar et la limite de leur utilisation pour la compression-décompression.  
Mais par contre je ne comprend pas pourquoi un tel traitement (finalement assez simple) rendrait le multithreading de l'algo LZMA2 bien plus efficace.

 
Si tu en entendra de nouveau parler en gros quand ce sera une autre marque    
 

Je crois que tu ferais mieux d'arrêter de tout vouloir ramener à la vidéo, parce que c'est un peu ridicule. Un container entrelace le contenu, ca n'a rien a voir avec une concaténation séquentielle.  
 

Tu ne vois pas la différence entre compresser X fichiers et un fichier ? Relis mieux.

mille mercis pour ce genre d'articles. une aide très précieuse au choix lors de l'achat