Reprise du message précédent :

D'après ce que j'ai put en comprendre, le scheduler des GPu est logiciel et donc s’appuie sur le CPU. En dehors de marginalement fausser les tests de conso GPU (dont on se fout ici), ça a forcément un impact sur la charge CPU.
En imaginant que leur système fonctionne idéalement, et que le charge soit uniformément réparti, alors de toute façon, on sera à 100% de charge plus rapidement sur les cores en question. Schématiquement.
Les sources sur le sujet sont rare, et la, j'en ai pas sous la main, désolé.
Après, je n'ai rien à dire sur votre méthodologie de bench en elle même, hein. C'est toujours un équilibre instable entre nécessité de se mettre au plus prêt de l'utilisateur, tout en aillant besoin d'avoir des résultats synthétique, facilement reproductible, et fiable. Ce qui est généralement contradictoire avec le premier besoin.
Le problème ici est que contrairement aux bench habituels de CPU Intel, qui sont relativement insensible au GPU utilisé, ici, les résultats peuvent montrer des écarts en fonction du GPU utilisé, ce qui complique grandement votre tache. Je ne vouas accuse pas de partialité, hein. Si je vous trouvais partiaux, je ne serais pas ici. ^^

J'arrive plus à retrouver de source la.  
Et si j'étais sur de mon coup à 100%, je viendrais pas vous demander votre avis.

Ah, merci, j'avais lu ce truc, je n'arrivais pas à le retrouver!

@Zumb Cf. message précédent + http://forum.hardware.fr/hfr/Hardw [...] #t10116126

Bah mon bon vieux I7 2600K de 2011 acheté 250 € était vraiment l'affaire du siècle !!!

 
Il faut être prudent avec ces benchs. Contrairement à DX11, chaque moteur DX12 représente une implémentation particulière qui ne permet pas de généralisation. AMD et Nvidia manipulent tous deux la réalité pour tenter de pousser la presse à faire ressortir des tendances (type fonction intrinsèque - ou shader replacement - activée uniquement sous DX12/Vulkan). Je ne sais pas trop ce qu'il se passe dans ce cas précis, Tomb Raider ne représente pas une implémentation extraordinaire de DX12. Par exemple ce n'est pas impossible que Digiworthy ait oublié de décocher l'option bi-GPU spécifique au mode DX12 et que cela entraîne un bug avec une seule GeForce.
 
Autant sur Radeon que sur GeForce l'exécution des tâches est pilotée par un mix software/hardware. L'avantage d'AMD est de disposer d'un hardware plus évolué et flexible pour l'exécution concomitante de différentes files sous DX12/Vulkan (ce qui s’apparente à du SMT sur CPU, même si la définition du thread est différente sur GPU). Ca permet d'obtenir plus facilement certains gains niveau GPU. Mais cela n'a aucun rapport de près ou de loin avec les performances CPU ou l'utilisation d'un certain nombre de threads sur le CPU. Un moteur de jeu peut alimenter une seule file de commandes avec 36 threads s'il le veut que ce soit sur GeForce ou sur Radeon, le choix du nombre de threads sous DX12/Vulkan est celui du moteur, non du pilote.
 
Certains détails peuvent avoir un impact sur les performances CPU avec l'un ou l'autre pilote, mais il s'agit alors en général d'une erreur des développeurs. Par exemple un point de synchronisation mal défini entre files de commandes ou groupes de commandes peut passer inaperçu lors du QA sur le hardware actuel mais ressortir par la suite avec un couple CPU / GPU différent. Les nouvelles API demandent plus de rigueur de la part des développeurs pour éviter ces soucis.

@Marc&Tridam: Merci, j'avais lu ça aussi.
Effectivement, i lfaut séparerles deux problématiques: l'implémentation de directX12 par Nvidia.
La manière dont sont géré les queues par le pilote Nvidia, qui apparement intercepte et réparti les appels sur plusieurs core, la ou le pilote AMD laisse plus de boulot au GPU, mais est du coup dans l'incapacité de splitter la charge en directX11 sur plusieurs cores.
Je pense qu'il n'y a pas uniquement la méthode utilisé par le jeu pour interagir avec l'APi qui joue, mais aussi et surtout la manière dont le jeu réparti la charge de son moteur sur les threads, indépendamment de la partie graphique. Il ya des jeux directX11 bien mieux multithreadé que des jeux directX12, et pas uniquement à cause de l'API.
Dans le cas de Tomb Raider, l'auteur du test a relevé des différences de comportements très importantes entre les différentes phase du jeu, qui laisseraient penser que le benchmark intégré n'est pas du tout représentatif de la charge moyenne en jeu, parce qu'il charge beaucoup plus le CPU qui n'importe quel autre partie du jeu, avec un nombre d'objet à l'écran bien supérieur à la moyenne. Si c'est avéré, quel valeur peut on donner à un tel benchmark, pour déterminer un comportement en situation réelle? Je pense pas que l'éditeur ai choisi ce passage pour faviriser qui que ce soit, plus porbalement parce que c'est une des parties les plus jolie visuellement, et qu'il utilise ce benchmark comme une démo de son jeu. Néanmoins, on ne peut pas s'y fier pour savoir quel est le matériel le plus adapté pour jouer à son jeu...

Autant pour moi, je voulais dire SSSE3 (qui est utilisé par Feral pour compiler ses versions Linux de plus en plus souvent).

 
Tu mélanges beaucoup de choses là, ça ne fonctionne pas comme ça. Un pilote ne peut pas intercepter quelque chose et le répartir sur plusieurs threads, le surcoût serait ridicule. Encore une fois, les différences de fonctionnement au niveau de la prise en charge des files multiples par les GPU n'ont aucun rapport de près ou de loin avec l'utilisation des threads CPU. AUCUN.
 
Sous DX12 il n'y a aucune différence niveau prise en charge des threads CPU entre AMD et Nvidia (sauf si le développeur veut en créer une). Sous DX11, pour simplifier très fort, l'avantage de Nvidia est d'avoir conçu des pilotes suffisamment robustes pour pouvoir alléger certaines vérifications redondantes et certains mécanismes de synchronisation qui sont de méchants freins au multithreading.

 
Merci d'avoir partagé ton expérience

Ben j'ai fais justement la manip, avec Cinebench, en partant des fréquences stock jusqu'à 4.4Ghz.
Puis reporté sous Excel et calculé les ratios % : oui, c'est complètement proportionnel.
J'ai fait pareil avec un 3770k, que j'arrive a monter plus haut (4.8Ghz toujours en Airflow), toujours proportionnel et ce "4C/8T@4.8Ghz" arrive bien a s'en sortir Vs le 7700K autant en multi http://valid.x86.fr/bench/9p4xje/8 qu'en Single http://valid.x86.fr/bench/9p4xje/1
Le reste de la conf ici http://valid.x86.fr/9p4xje

N'importe quoi, les gamers sont de plus en plus déconnectés de la réalité!!!
Les 15 à 20% de différence (en attendant la sortit du patch Windows 10...) font du Ryzen un CPU mauvais en jeu!

Faux, j'ai fais la manip entre stock et 4.8Ghz (step de 100Mhz) pour un 3770K avec Cinebench puis CPU-Z, report puis calcul des ratios sous Excell, c'est completement proportionnel.
Et ce 4C/8T/@4.8Ghz arrive 3ième juste apres 7700K et 6700K en Multi http://valid.x86.fr/bench/9p4xje/8 et 4ième juste apres 7700K,6700K,6600K en Single http://valid.x86.fr/bench/9p4xje/1.
Le reste de la conf ici http://valid.x86.fr/9p4xje

Cinebench est purement arithmétique, on ne peut pas comparer ça a des apps ou la mémoire à une influence, encore moins à des jeux. Le scaling sera différent en fonction de la charge.

 
+1 : Même constat sur un Intel 3770K en jeu (PlanetSide 2 en 5760x1080 tout en Ultra + occlusion etc) avec Radeon Pro Duo (donc pas limité par le GPU), c'est nettement plus fluide, je suis plus descendu sous les 55fps, l'indicateur gabote entre 55-62fps (écrans 60hz et "lissage activé" )

 
Du coup ça marche quand même un peu comme ça. Le 7500 dont tu parles est 38% plus performant qu'un 2500k@3.3 GHz (en applicatif). Avec un OC à 4.5-4.7, j'avais calculé un gain théorique de 4.6/3.3 = 39%.
 
Alors oui en jeu, le gain est moindre (+24% par rapport au 2500k@3.3GHz).
 
N'empeche je plussois nic02, ce serait top si HFR ajoutait au comparateur un 2500K@4.5 pour que l'on puisse se faire une idée. Tous les gens que je connais qui possédé un 2500K l'ont OC à 4.2-4.7. Du coup en lisant le test, j'arrive pas bien à savoir si ça vaut (enfin) le coup d'en changer.

 
J'suis parfaitement d'accord avec vous, j'ai bien fini par comprendre mes résultats : comme je suis limité à de la DDR3@2400Mhz, que je n'ai pas de "Maxi turbo core" ou XFR ou équivalent des CPUs récents, je soupçonne que les résultats des SkyLake, KabyLake, Rysen, ... (en fait tous les autres CPUs du comparatif sauf le 2500k limité à 2133Mhz) bref que la VRAIE différence entre les CPUs, c'est leur gestion de la mémoire, leur capacité a gérer des fréquences hautes.
J'ai reporté tous les résultats (les miens, ceux de tests du Web, les conditions de réalisations, les spécifications des CPUs, bref tout ce que je trouvais) sous Excel, j'ai fais des tableaux croisés dans tous les sens, calculé des ratios, calculé des tendances (variations relatives), pour moi je n'en ressort qu'une seule et unique conclusion : la fréquence mémoire est la seule explication qui fait la différence entre les 4C/8T (ils ont tous 8Mb de L3) à Ghz équivalent, les résultats des R5 (surtout du 1400) deviennent alors parfaitement compréhensibles ...

Déjà c'est 3.4 en charge 4C donc 32% d'écart de perf. Ensuite le scaling n'est pas parfait dans les jeux notamment, ce sera plutôt 20-25%. Mais ces CPU s'oc aussi

 
le gars a réussi son coup    
même après avoir été déboîté par la maréchaussée, son post revient nous hanter

Donc un petit comparo rapide OC des derniers proc intel/amd les plus intéressants serait une bonne idée
   

D'ailleurs, la MAJ de la base OC pour les AMD AM4 est prevue bientot ?

J'aurais été curieux de voir les performances du 6850k dans le test puisqu'en dehors du fait que les résultats m'intéressent (J'ai un 5820k et un 5930k sur mes 2 configs), son positionnement 6 coeurs 6e génération en socket 2011-v3 donnerait une idée à ceux équipés en X99 de faire ou non le pas vers le dernier CPU 6 coeurs intel ou passer chez AMD (J'upgrade souvent avant que les CPU perdent trop de valeurs)

Je me suis un peu perdu en route, et je plaide coupable.
Cela dit, si, il y a une différence de prise en charge entre AMD et NVidia au niveau du pilote.
On peu la voir dans ce test:
http://www.anandtech.com/show/8962 [...] ar-swarm/4
sous directX11, la 980:

La 290X

On voit une charge répartie sur tout les cores, que ce soit sous directX11 ou 12 pour une 980, quand elle n'est répartie sur tout les coeurs que sous directX12 pour la 290X, avec un core saturé à 100% sous directX11 pour la même carte.
Avec le même CPU et le même benchmark, je vois mal autre chose que le pilote provoquer une telle différence de comportement, même si c'est un cas extrême, étant donné que ce truc est justement codé pour ça.

Zumb -> relis mieux le message que tu viens de citer.

Bon, je vais me coucher, j'en ai besoin visiblement. ^^

C'est peanuts.
 
Le die est certes un chouia plus gros que celui d'Intel (en LGA1151) mais le coût par wafer doit être similaire, ils proposent des R7 plus chers que le plus cher des i7 sur le socket mainstream et on va avoir les gammes "pro" avec un Naples qui devrait toper les 5000€ pièce (1000€ par die Zeppelin, soit presque le double du R7-1800x) sans nécessité de monter terriblement haut en fréquence.
 
Alors, ils désactivent sur le cœur de cible? Oui, mais quand le budget R&D est limité, faut faire des choix, et AMD a choisi de proposer tout un panel de processeurs basés sur le même die du 4C au 32C dans le but de diminuer les coûts fixes en amont sans rien retarder, et en particulier en se contrefoutant de la plateforme mainstream qui peut n'avoir qu'une durée de vie d'1 an...
 
Si tu regardes chez Intel, c'est pas la joie non plus avec les i3/Pentium/Celeron qui ont tout l'air d'utiliser le même die que les i5/i7, et ça pour une raison simple... à 122mm² (~9x13mm), enlever 2 cores le ferait passer à 100mm² (~9x11mm). 100mm², c'est la région des processeurs à 50€ grand max (Atom/Kabini), donc ça donne une idée du coût à l'unité (et du coup du prix d'un wafer), mais pas des coûts fixes. Plutôt que de dépenser une fortune dans des masques "die économique" pour grapiller des clopinettes sur le long terme (20% de dies en plus par wafer dans le cas de Skylake), à un moment vaut mieux juste segmenter artificiellement...
 
Dans le cas de Zeppelin, je suis pas convaincu qu'AMD aurait pu faire un die 4C ne serait-ce que 20% plus compact (chaque CCX occupe 44mm², le reste est pour ainsi dire incompressible), du fait de sa nature de SoC... c'est vraiment pour Raven Ridge que la problématique sera concrète, car il va falloir que l'IGP justifie un surcoût par rapport aux R3/R5 4C.

Bonjour à tous, Et merci pour les informations précédente.
Simple question dans le test ci-dessus, quel est le ventirad utilisé pour chaque cpu?

Pour tous les Ryzen, Noctua NH-U12S SE AM4.
 
Pour tous les autres, Noctua NH-C12P SE14.

Ok un grand merci, ce qui explique surement pourquoi j'ai 10° de plus avec le ventirad d'origine avec mon ryzen 1700 avec 6c 12ht @3.7.
Autre question lors du test d'oc et donc de la température le logiciel utilisé est bien prime 95? Si oui quel mode avez-vous choisi?

Je crois que c'est marqué, mais sinon mode Custom, FFT in line min/max à 256.

Oui je les vue indiqué dans le test des ryzen7, un grand merci

En appliquant le même mode que votre test en 6/12ht @3.7ghz avec le ventirad d'origine j'arrive @ 68-69° valeur indiqué dans ryzen master ( dernière version) et hwinfos64 dernière version Beta.
Juste pour infos
J'ai comparé avec le ryzen 5 1600 vs ryzen 7 1700 en mode 6c/12ht

Le 1700 est là sinon pour info : http://www.hardware.fr/articles/93 [...] tique.html
 
On fait les tests hors boitier sinon pour être précis, on note surtout les températures a titre indicatif (et parce qu'avec les offsets sur certains X c'est flou).

Oui j'avais vue merci .
Oui effectivement à y perte la tête mais je voulais surtout me rassurée vis à vis de la température que j'obtenais, car depuis la mise à jour du bios en 1.3 sur la msi b350 tomahawk, la sonde sous hwinfos déconne complément en idle en tout cas, elle passe de 35° à 45° pour redescendre à 40° comportement étrange....

Pour le coup pas testé cette MSI, mais les constructeurs de CM peuvent appliquer des corrections aux valeurs, ce qui n'arrange pas grand chose (Sense MI skew chez Asus par exemple). Le 1700 est sans offset en théorie sur tCTL mais bon les BIOS font des choses  parfois bizarres

Sa je confirme lol.
En tout cas merci pour tes infos et concernant l'AGESA 1.0.0.4 avec cette msi en bios 1.3, le code ne change pas il reste en 1.0.0.3 mais le micro code et le smu on bien changé donc à mon avis, l'AGESA doit lui aussi être à jour mais hwinfos lui indique toujours 1.0.0.3 mais bon, pas très grave en soit.
Encore merci

 
+1  

En tout cas je possédais un i5 2500k oc @4.7ghz.
Alors oui bon cpu mais dans certain jeux bf1, the division,ghost recond widland,wach dog, le cpu saturé @100% du coup j'avais des drops de fps ma gtx 980 attendais sagement le cpu.
Depuis je suis passer au ryzen7 1700 et maintenant le cpu ce tourne carrément les pousses et ma gtx980 respire .

Donc ajoutez 80% de l'écart en fréquence pour avoir l'indice applicatif et 50% pour l'indice jeu ce qui prends 30s pour avoir une idée très proche plutôt que de demander de relancer des protocoles à telle ou telle fréquence qui durent des plombes

Un test "plateformes" par contre ça pourrait être sympa, mais dispensable en effet

 
HFR fait une une comparaison à 3 Ghz entre Rysen et Broadwell-E:
http://www.hardware.fr/articles/95 [...] 3-ghz.html
 
Mais reprenons avec ton raisonnement avec une application lourde, tirant partie de toutes les SIMD modernes et particulièrement optimisée pour cela. Puisque tu le suggère toi-même, le cas le plus favorable à AMD. Et en plus qui scale de manière quasi-parfaite avec la fréquence CPU, sans dépendre de la fréquence RAM. Bon, ça tombe bien, il y a une application qui correspond parfaitement à tout ça: le x264.
 
Prenons les CPU 4C/8T et scalons tous les résultats obtenus par HFR avec le x264. On obtient les classement suivant:
 
On a 3 Ghz le classement suivant:
Rysen: 8.95 fps  
Kaby Lake: 9.55 fps
Haswell: 8.40 fps
 
On a 4 Ghz le classement suivant:
Rysen: 11.93 fps
Kaby Lake: 12.74 fps
Haswell: 11.20 fps
 
On a 5 Ghz le classement suivant:
Rysen: N/A
Kaby Lake: 15.92 fps
Haswell: 14.0 fps
 
Donc si tu compare un R5 1500X à 4.0 Ghz à un i7-7700K à 5.0 Ghz, tu arrives effectivement à 33% de mieux.  
 
Après je ne sais pas si c'est la meilleure méthode de comparaison car un r5 1600X ou un R7 1700 feront mieux qu'un i7 7700K à 5.0 Ghz tout en consommant largement moins par exemple.  
Je pense qu'ici la meilleure méthode de comparaison serait de voir en fait les courbes d'efficacités respectives en fps/watts et fps/core/watts en fonction de la fréquence et ensuite quelle serait la meilleure solution à 100 watts pour encoder en x264 le plus rapidement possible. Et ici il n'est pas certain que Kaby Lake fasse mieux que Rysen car l'archi d'AMD semble très efficace:
http://www.hardware.fr/articles/95 [...] tique.html