Reprise du message précédent :

Je crois que tu parles du turbo. Ici, il est question de désactiver un die (et activer NUMA) pour se mettre dans une situation plus favorable au jeu, ce qui n'a rien à voir avec le turbo.
Comme le dit l'article, c'est pas très propre, mais ça a le mérite d'exister.
 
En passant, comme l'a montré les tests, les jeux ne scalent pas aussi bien que les applis. bien multithreadées. Si tu paies cher un 32c@2Ghz, il sera assurément moins bon qu'un 4c@4GHz en jeu, mais il le déboitera sur l'applicatif. Qui est le plus puissant selon toi dans ces conditions ?

 
Intel c'est exactement la même chose: plus on monte en gamme et moins c'est performant dans les jeux. Simplement parce qu'en montant en nombre de coeur, on doit baisser la fréquence, et les jeux ne savent pas utiliser plus de 6-8 threads efficacement. Si tu regarde en applicatif, AMD a une progression perf/prix bien meilleure qu'intel ...

Est ce que vous pourriez faire un graphique rapport qualité prix pour la config totale par rapport à l'offre d'intel ?  
par exemple, les 240€ de diff entre un 1920x devient négligeable à partir de 3000-3500€ à peu près (prix à partir du quel les 5% de perf en moins se traduisent par moins de 5% de prix en moins)
 
Enfin bon c'est sans compter que la plateforme AMD propose plus de lige PCIe et donc qu'on ne peut pas les comparer que sur la perf brute

 
Il ne faut pas non plus oublier qu'on est dans un nombre de noeuds qui pose de gros soucis d'interconnexions. Avec 4 coeurs, on peut facilement réaliser une interconnexion complète (ie, chaque CPU peut taper dans les données des autres), et plus on augmente le nombre de coeurs, et plus ce genre d'architecture ne peut plus fonctionner car trop complexe. Du coup, on passe à du mesh comme Intel en ce moment, ou des réseau en anneau comme il y a eu sur les GPU AMD il y a quelques temps... En ce moment, le nombre de coeurs utilisé fait qu'une architecture prévue pour bcp de coeurs est pénalisante car justement, on n'a pas assez de coeurs pour sentir qu'elle ne bride "pas trop". J'entends par là que selon des articles, c'est plutot à partir de 32/64 coeurs qu'on devrait avoir un scaling plus régulier avec le nombre de coeurs (attention cependant, à cause des interconnexions, on ne se sera pas à doubler les perfs en doublant le nombre de coeurs, mais on sera sur un gain relativement "régulier" )
 

Vous avez mis que le mode gaming = un die désactivé, et anandtech indique lui que c'est le smt qui l'est, qui a bon
et félicitations pour le test

 
Clair, concis, direct.
 
Et j'ajouterais même : et plus c'est moins cher.

 
Au contraire c'est vachement cool, ils font l'OC max et le mettent dans tous leur test. Très utile pour les gens qui OC (soit une proportion non négligeable de lecteur de ce genre de test). Et t'es franchement de mauvaise foi, ça fausse rien du tout, les exemplaire OC sont précisés dans tous les graphes. Suffit de pas être aveugle...

A t on plus de précisions sur les die physiques du TR?
Guillaume/Hfr a écrit:

Tomshardware a écrit http://www.tomshardware.fr/article [...] 718-2.html :

Est ce vraiment comme Toms le décrit, que le TR intégre 2 die Zepellin et 2 dies non gravés?

 
Ce que je trouve étrange c'est que ce serait les die qui feraient office de cales... Alors que j'ai toujours cru que c'était l'IHS qui supportaient toutes les charge justement pour protéger les dies.

Nope.  
 
L'histoire du "silicium brut" (!) est une mauvaise compréhension de la chose très floue qu'a dit AMD. Ce sont des vrais dies.

Physiquement connectés ? défectueux ?

Je n'ai pas la réponse à la première question, ils utilisent exactement le même montage que les Epyc donc probable qu'il soit "connecté" par défaut dans le sens assemblage physique du terme. Mais probablement fused off. AMD ne rentre pas dans ce genre de détails.
 
Défectueux très probablement oui
 
Ce qu'a dit AMD précisément, deux dies sont *actifs* et deux *servent* de *mechanical stabilizer*.

 
T'espère les débloquer?

http://www.tomshardware.fr/article [...] 65033.html

j'espère que comme pour les Phenom II X2 550BE (déblockable en Phenom II X4), ils pourront se débloquer en 32coeurs d'ici quelque temps      

Cela serait Epyc ! ;D

avec 360W de TDP, ce serait infernal

 
Utiliser les dies défectueux, c'est effectivement une bonne idée : ayant subit la même techno, ils font nécessairement pile poile la même hauteur.

Bonjour
Jai une question
Peut être déjà répondue il y a trop de messa ce avant.
Le lien externe qui relie les die entre eux est 4x plus plus rapide que le lien interne entre ccx.
Ça ne serait pas pour que dans le de epyc avec 4 die les 4 die puissent faire une requête en même temps et du coup ne pas être limité ?

C'est un peu juste pour chauffer le bain d'huile pour les frites

 
 
http://www.tomshardware.fr/article [...] 64469.html
 
99.9% des dies Zeppelin seraient opérationnels.
Donc on aurait 2 dies potentiellement fonctionnels mais inactifs dans le TR, comme on a des cores probablement fonctionnels mais désactivés dans les R5 et R3.
 
Finalement, seul le R7 et les Epyc 32c sont 'propre' dans le sens ou ils sont les seuls à utiliser tous les cores et dies.

 
Ben je trouve leur graphique pas très clair au contraire: ils mettent les CPU OC et non OC dans le même graphique, ce qui les rends très peu lisible. Y compris sur les conclusions. Il faudrait, a mon avis, qu'ils fassent 2 graphiques distinct pour que cela soit plus clair.
 
De plus ils testent bien trop d'applications. Oui ils veulent être exhaustif, mais bon tester correctement une application nécessite de bien la connaitre. En applicatif, ils doivent faire presque une cinquantaine de tests différent. Pour parler de la partie que je connais bien, faire un test d'encodage est un exercice difficile. Après discussion avec un développeur sur x265, pour lui la meilleur méthode, c'est d'encoder directement en haute qualité une Raw 4K 4:4:4 10 bits ou 12 bits. Mais bon il n'y que les pro qui encodent comme ça avec des raw qui prennent 30 GB/min en 24 fps. T'as donc intérêt à avoir un SSD qui dépote pour faire le test. Mieux vaut donc tester à partir d'une source H264 ou H265 haute qualité, ce qui sera plus conforme à la réalité des usages. Faut donc veiller à prendre un serveur de frame qui va te prendre un minimum de ressource au décodage pour tester vraiment la vitesse d'un encodage x264/x265. Ce n'est pas le cas de la plupart des tests qu'on voit qui utilisent des gui comme handbrake. Ces gui utilisent souvent des pre-process (souvent via avisynth) qui utilisent beaucoup de ressources. Ainsi faire un encodage en mode rapide en x264 en 2K à partir d'une source 4K H265 n'a strictement aucun sens par exemple car tu ne teste pas uniquement le x264. Et je ne parle même pas des débats entre spécialiste sur l'utilisation de multiples instances qui permet d'être sûr de saturer un CPU mais qui ne correspond à aucun usage en pratique.  
 
Cela les conduit à faire des tests dont les résultats sont parfois aberrant sans qu'il ne sache l'expliquer:

 
 

On peut pinailler sur tous les points, mais comme tous les processeurs sont logés à la même enseigne, les rapports devraient rester à peu près les mêmes modulo la scalabilité du programme sur le nombre de coeur/thread.

 
Ce n'est pas ce que je comprends: ils disent que 99.9% des dies seraient utilisables. Cela ne signifie pas 99.9% pleinement fonctionnel et utilisable en 8C/16T mais que 99.9% peuvent être utilisé pour faire des R3, R5, R7, Threadripper et Naples. Tu peut donc à priori avoir effectivement 1 ou 2 dies partiellement foiré dans Threadripper ... ou pas.
 
Après si AMD considère qu'un die foiré qui sert en fait de cale dans Threadripper est un die utilisable, alors le 99.9% s'explique très bien. C'est même ettonant que cela ne soit pas 100% dans ce cas ... ;-)

Y a aussi l'histoire de symétrie dans un CXX, nan ?
Je veux dire, un 3+4 coeur fonctionnel sur un die ne donne qu'un 3+3 coeur utilisable ? et donc avec cette logique, si 4 coeurs sont désactivés, c'est peut être parce qu'il y a 2 coeur HS.

une belle bête de course, ça va être bon pour nos serveur avec pleins de VM dedans !!

 
C'est pour cela qu'il faut privilégier le décodage hardware GPU en amont pour les sources H264/265 et même MPEG-2.
Avec Avisynth il faut utiliser DGIndexNV (DGDecodeNV)comme filtre source même si payant mais licence très modique.
Après il me semble que Handbrake peut utiliser le décodage hardware CPU via Intel quickSync mais ici on teste justement un CPU AMD donc effectivement les test Handbrake à partir de sources H264 que l'on voit ici et là sont un peu faussés en faveur de l'Intel 7900X.

La baffe est donnée amd passe devant pour les cpu MERCI

c est aussi ce que je disais plus haut.
Finalement, si on veux du AMD, le choix peut etre entre une plateforme TR et une Epyc! Les TR montent plus haut en fréquence et sont O/C, mais les Epyc sont plus flexibles avec une offre plus importante en cores et 8 channels:
 
https://en.wikipedia.org/wiki/Zen_(microarchitecture)
par ex en 16C/32T, AMD offre les CPU suivants:

1 Ghz de plus que les Eypc proches, c'est une sacrée belle perf pour le TR.  

Vivement que les prix baissent me plairait bien un TR 16C/32T, mais là la note est trop salée.

Très belles performances ^.^
Quand on connait le prix et le potentiel d'optimisation, c'est vraiment bon.

pro ou perso? pour faire quoi? à part l encodage video, j ai du mal à saisir les applications pertinentes hors entreprise.

Perso !
C'est une machine de dev, mais surtout le Nightly builder d'un projet open-source, bien que parfois j'enchaine les builds de commits.
Je fais des paquets Debian stable et unstable 32 et 64 bits, Ubuntu, Cross-compilation de paquets pour Windows installer 32, 64 bits, ReadyToUse, bundle macOS.
Mais bon mon 1700X me convient amplement, on verra plus tard si le code grossi trop vite..

R7 meilleur cpu < $500 du 1er semestre, mais il devrait être bien bousculé au 2nd semestre par les i7 6c/12T coffee lake, qd on voit les bonnes perfs du i7 7820X (et i7 7800x 6c/12t sur d autres tests, comparable au R7 1800x)

Faut pas rêver, rares sont les défauts rendant un die juste "partiellement défectueux"...  
 
Moins performant ou totalement foireux ok, mais y'a vraiment pas grand chose qui justifie la segmentation à outrance, surtout pour les CPU AMD en fait (du fait que tout est débloqué en overclocking, ils auraient pu nous proposer des R5(1600) et R7(1700), voire des "x" avec cTDP et basta, les R5 utilisant les "mauvais" dies avec plus de jus).

Certains geeks ont plusieurs vm à la maison et bouffent 32Gio sans forcer.
J'imagine que niveau core c'est pareil.

http://www.tomshardware.fr/article [...] 65041.html
128GB qui risque de coûter plus cher que le TR plus la CM ..

Avec tous ces CPU qui sortent je ne sait pas pour quel config opter?????
Viser un max de coeurs pour plus de pérennité ou bien ce contenter d'un 4 coeurs pour le jeu???
Ma principal utilisation etant du jeu de l'internet et de temps a autre du reencodage mais tres rarement.
Donc bon quoi penser de tous ça aujourd'hui j'avoue je suis un peu perdu.

 
Ben, perso, j'ai un i7 980, et je sais pourquoi : il m'arrive qu'il tourne pour des simulations en mode h24 (surtout en hiver, car vu que je chauffe à l'électricité, ca ne me coute rien que ce soit en alimentant mon CPU OC avant de produire de la chaleur). Bref, ca fait un moment que je suis donc 6C/12T OC + 24 Go, et je passerai volontiers au double (si c'était un peu moins cher !)

 
Ben d'après les info qui sortent chez intel et AMD, les CPU 4C/4T, cela sera bientôt le bas de gamme. Donc à mon avis attend de voir le tarif et les perf des nouveaux CPU Intel 6C qui vont bientôt sortir: il sera temps de se décider à ce moment là. En tout cas acheter un i7-7700K ou un i5-7600K aujourd'hui ne fait pas sens. Surtout quand on sait que les CM ne seront p'tete plus compatible avec les nouveaux 6C de chez Intel.

Les 6c me semblent les plus adaptés pour du moyen terme. Pour les 8c et au-delà, c'est plus parier sur un meilleurs multithreading des applis/jeux ce qui n'est pas gagné. Après, si tu fais surtout du jeu et internet, la fréquence est à privilégier sur le nombre de coeurs.