Protocole de test CPU 2019

2
842

En cette année 2019, nous renouvelons notre protocole de test CPU. Pas mal de changement par rapport au précédent, datant de deux ans. Nous allons préciser ici ce qui est mesuré et comment.

Configuration de test :

Plateformes

Les CPU que nous testerons avec ce protocole appartiendront à une de ces plateformes. Voici le détail du matériel utilisé pour chaque :

La RAM a été configuré à 3000 MHz, contre 2666 MHz dans le protocole précédent.  Il y a deux ans, la mémoire rapide coûtait cher, les gens se contentaient souvent d’acheter de la mémoire à 2400 ou 2666 MHz, d’où notre choix de 2666 MHz. Mais maintenant la mémoire rapide est plus accessible, nous sommes donc passé à 3000 MHz. Cela permettra d’ailleurs à certains processeur de mieux pouvoir s’exprimer.

En plus de ces couples processeur-carte mère, le reste de la config de bench sera composé de :

  • Carte graphique : KFA² GTX 1080 Ti HOF
  • SSD : Crucial BX100 500 Go
  • Watercooling : Cooler Master MasterLiquid 240
  • Alimentation : Corsair CS 850M
  • Table de bench : Lian Li T60
  • OS : Windows 10 Familial 64 bits optimisé

La ventilation de la carte graphique sera réglée à 100 % via MSI Afterburner. En effet, une surventilation permet d’éviter complètement le thermal throttle. Or une légère variation de la fréquence GPU entraîne une variabilité non désirée des résultats dans les benchs 3D et dans les jeux.

OS et BIOS

Dans ce nouveau protocole, nous faisons la chasse aux écarts de mesures lors des benchs. Cela implique donc de limiter au maximum le lancement de petits services qui peuvent altérer les performances de la configuration pendant quelques secondes. C’est d’autant plus net lorsqu’on mesure les performances du CPU.

Dans cette optique, l’usage de la version familiale de Windows 10 allait de soi, puisque plusieurs services sont absents. Mais surtout, le Windows a été grandement allégé puisque nous avons désactivé (entre autres) :

  • Cortana
  • Windows Update
  • Windows Defender
  • Prefetch
  • La plupart des services dispensables

Bref, nous sommes en présence d’un Windows minimal afin d’avoir les données les plus stables possibles. De fait, cette meilleure stabilité entraîne un autre effet : nos tests seront donc légèrement plus concilliants avec les petits processeurs (plus fortement sujets aux process Windows en arrière plan) que dans la vraie vie. Cela reste largement acceptable mais nous préférons le souligner. Afin de minimiser toute sorte d’influences extérieures, le PC ne sera jamais connecté à Internet.

L’OS est protégé contre Meltdown et Spectre.

Dans ce Windows nous avons installé les drivers graphiques, en l’occurrence les ForceWare 419.35 WHQL. La mise à jour des drivers a été coupée. Notez que nous utilisons le mode de performances « élevé » afin que la baisse en fréquence ne perturbe pas les usages légers (benchs applicatifs typiquement) et pour couper court à toute polémique sur Ryzen.

L’OS, une fois mis en état est ghosté (sauvegardé). Nous faisons un back-up de l’OS depuis cette image avant tout test de processeurs.

Dans le BIOS nous laissons activées les options permettant au processeur de contourner le TDP. En effet, dans le cas contraire, nous pouvons avoir une fréquence très élevée, et une consommation qui l’est tout autant… pendant les 20 premières secondes, pour s’effondrer les secondes qui suivent. Ce qui pose un problème : quelle performance prendre en compte (celles des 20 premières secondes, celles d’après ?), et sur quelle durée ? Par exemple sur un Core i7 9700K, si on laisse le CPU gérer son TDP, il consomme 160 W (!!) les 20 premières secondes avant de s’effondrer à 95 W pour se maintenir à son TDP. En activant l’option dans le BIOS, le CPU consomme 120 W de manière stable et a une fréquence tout aussi stable. Ainsi nous avons une mesure de consommation beaucoup plus logique, et des performances bien plus stables dans la durée.

Types de mesure :

La liste suivante montre les processeurs qui seront préalablement benchés, dans le but de figurer dans les graphiques. Ces processeurs fourniront une base de comparaison pour les processeurs que nous testerons. À noter qu’ils subiront exactement les mêmes conditions que les processeurs supplémentaires qui seront testés.

  • Ryzen  1800X
  • Ryzen 7 2700
  • Ryzen 7 2700X
  • Core i5 8600K
  • Core i7 8700K

Les processeurs seront tous refroidis par le Cooler Master MasterLiquid 240. Cet AiO très efficace (cf le test) a l’avantage d’être compatible avec tous les sockets actuels. Les deux ventilateurs ainsi que la pompe fonctionneront à 100 % de leur capacité. En effet, le PWM aurait impliqué une vitesse de ventilation différente selon le processeur, et nous voulions qu’ils soient tous traités à la même enseigne.

Nous allons mesurer les performances de la plateforme abritant le processeur. Cette série de mesure sera séparée en 3 catégories :

  • Perfs réelles : applicatif
  • Perfs réelles : jeux
  • Autres mesures

Les mesures de performances sont toutes prélevées 3 fois d’affilée. La configuration est redémarrée, les mesures refaites, puis redémarrée et les mesures refaites une dernière fois. Les résultats que vous verrez sur les graphiques sont à chaque fois la moyenne des trois mesures. Le but est ainsi de lisser les aléas des résultats et d’augmenter la fiabilité des mesures. Nous n’hésitons pas à faire une 4ème voir une 5ème mesure si celles-ci présentent trop de disparités.

Mesures de perfs réelles applicatif :

Comme dit précédemment, les mesures seront ici effectuées 3 fois. Nous utiliserons la moyenne des 3 mesures sur nos graphiques. Tous les processeurs figureront sur le graphique, sans modification : fréquence d’origine, boost activé … le base clock sera fixé à 100 MHz pour éviter certains phénomènes.

Voici la liste des benchs qui seront utilisés :

  • AIDA64 : RAM et cache L1, L2, L3
  • 7-Zip 64 bits : Compression et Décompression
  • Photoshop
  • After Effects
  • Cinebench R20 (Single Thread et Multi Thread)
  • Corona
  • Handbrake (encodage x264 et x265)
  • Spike
  • Veracrypt
  • 3D Mark : FireStrike Physics et TimeSpy Physics
Gestion cache et mémoire :

Nous commençons avec des relevés effectués sur AIDA64. Ceux-ci concernent la cache L1, cache L2 et cache L3, en lecture, écriture et latence. Il en est de même pour la mémoire vive.

Archivage :

Pour la partie applicative, nous commencerons par de l’archivage avec 7-Zip. Nous lui ferons exécuter le benchmark intégré et nous relèverons les mesures de débit de compression et de débit de décompression en Mo/s. Ces mesures seront faites cinq fois chacune, puis moyennées. Ce lot ce 5 mesures sera exécuté 3 fois, comme les autres benchs, pour un total de 15 mesures. Voici les réglages utilisés :

Traitements photos et vidéos :

Nous continuons avec les performances applicatives sur la suite Adobe. Pour cela, nous utiliserons PCMark 10. Nous utiliserons le bench photo et vidéo. Ces benchs lancent une série de traitement photo et vidéo automatisés.

Pour la partie photo, nous regardons le résultat et additionnons le temps passé (en secondes) pour effectuer les opérations suivantes : Color Adjusting, Unsharp Mask 1, Noise Adding, Gaussian Blur, Unsharp Mask 2, Thumbnail Loading. Ce total en secondes est le chiffre qui apparaîtra dans nos résultats.

Pour le traitement vidéo, nous faisons la moyenne des résultats des opérations suivantes (en FPS) : Sharpening OpenCL, DesHacking OpenCL. Nous affichons cette moyenne dans nos résultats. 

Création 3D  :

Nous commencerons avec des relevés reflétant les performances en création 3D. Nous utiliserons Cinebench, un des benchmarks les plus connus de sa catégorie ainsi que Corona. Ceux deux benchs tourneront avec tous les threads disponibles. Cinebench tournera également en mono thread.

Cinebench R15 laisse la place à Cinebench R20, basé sur une version de Cinema4D bien plus actuelle. De son côté, Corona utilise le moteur Corona Renderer. Nous l’utilisons afin de diversifier nos mesures.

Encodage vidéo :

Pour l’encodage vidéo, nous utiliserons le logiciel HandBrake. Nous lui demanderons d’encoder une vidéo issue de fraps, en 1080p60. Le bitrate tourne autour de 800 Mb/s, ce qui est un bitrate extrêmement lourd. Nous effectuons un encodage en x264, pour lequel nous utilisons une vidéo de 2 minutes (12 Go). Le fichier de sortie pèse 257 Mo.

Nous effectuons ensuite un encodage x265 en 2160p60, plus lourd, sur une vidéo de 1 minute (6 Go). Le fichier résultant est un mkv de 220 Mo. Le temps est mesuré en secondes, grâce à la log. En connaissant le nombre de frames dans chacune des vidéos, nous pouvons simplement calculer le nombre de frames par seconde encodée. Le résultat affiché dans nos tests sera donc en frames par secondes.

Réseaux Neuronaux et cryptage :

Nous effectuerons ensuite des relevés dédiés aux réseaux neuronaux et au cryptage disque.

Pour les réseaux neuronaux nous utilisons Digicortex. Ce logiciel possède plusieurs benchmark intégrés. Nous utiliserons le « small 64 », qui malgré son nom n’est pas si small que ça pour un PC mainstream. En effet, cela correspond à un réseau constitué de 32768 neurones et 1,8 milliards de synapses. C’est moins que le cerveau d’un insecte mais plus que celui d’un ver de terre. Nous relèverons la vitesse de traitement des réseaux neuronaux en % de la vitesse réelle. Un CPU qui dépasse les 100% est donc capable de faire du temps réel sur ce réseau.

Pour le cryptage disque nous utiliserons le benchmark intégré au logiciel VeraCrypt. Nous regarderons la moyenne entre encodage et décodage sur de l’AES, qui est pour nous la plus parlante.

Benchs 3D

Nous finirons avec les benchs 3D. Nous en utiliserons 2 : Firestrike, que nous ne présentons plus. Nous utiliserons la scène « Physics » et relèverons ce résultat.

La nouveauté dans les benchs 3D est l’apparition de TimeSpy, le petit dernier de 3DMark. Il a comme avantage de tourner en DirectX12, et est donc clairement plus tourné vers l’avenir que les autres benchs. Là aussi, nous utiliserons le score du CPU Test.

Nous avons donc ici un bench 3D en DirectX 11 et un en DirectX 12.

Mesures de perfs réelles jeux vidéos :

Nous testerons également les processeurs dans les jeux vidéos. Nous avons voulu une liste qui se veut futureproof. 2 jeux sur les 6 sont en DirectX12, et 4 sont en directX11.

  • Shadow of the Tomb Raider (DirectX 12)
  • Hitman 2 (DirectX 11)
  • Watch Dogs 2 (DirectX 11)
  • Battlefield V (DirectX 12)
  • Assassin’s Creed Odyssey (DirectX 11)
  • Kingdom Come (DirectX 11)

Nous rappelons que les mesures sont faites 3 fois avec à chaque fois un reboot entre chaque relevé.

Tous seront testés en 1080p, et en graphismes équivalents grosso modo à très élevé, selon le jeux. Nous voulons en effet un réglage de jeu « réel » pour une config avec GTX 1080 Ti et non un réglage tout au minimum pour augmenter artificiellement les écarts entre CPU. Cependant, nous n’avons pas trop la main lourde avec les détails, de manière à ce qu’on soit très clairement au-dessus de 60 FPS, afin de ne pas tomber dans une situation clairement GPU Limited..

Nous choisirons  une scène facilement répétable, que nous jouerons pendant 1 minute selon les jeux. FRAPS tournera en arrière plan et mesurera les frametimes image par image. Nous demanderons à la fin une extraction des frametimes collectés. Nous en tirerons deux mesures :

  • FPS moyen = nombre de frame calculées pendant le bench divisé par le temps qu’a duré le bench à la ms près.
  • FPS mini = le 99ème centile des frametimes, passé à l’inverse.

Le choix des 99ème centiles est un choix de compromis de notre part. Cela permet de prendre en compte le micro-stuttering, si celui-ci est très présent, et surtout est une mesure assez stable, contrairement au 99.9 centile par exemple.

Shadow of the Tomb Raider

Nous choisissons le niveau Cozumel, au moment de la rivière en crue.

Voici les réglages graphiques utilisés. Ceux-ci sont issus du preset « Highest ».

Hitman 2

Nous utiliserons la mission finish line, dans laquelle nous faisons un parcours pré-établi. Cette scène a été choisie pour son grand nombre de PNJ.

Voici les réglages graphiques utilisés :

Watch Dogs 2

Nous utiliserons pour Watch Dogs 2 une scène in-game à l’extérieur du Hack Center. Nous effectuons un parcours pré-établi dans les aptés de maisons aux alentours, en déclenchant certains évènement, le principal étant l’explosion d’une bouche d’égout. 

Voici les réglages graphiques utilisés. Nous sommes sur le preset « Very High ».

Battlefield V

Dans Battlefield 1, nous utiliserons le tout début de la mission « le dernier Panzer ».

Voici les réglages graphiques utilisés. Ceux-ci sont issus du preset « High » :

Assassin’s Creed Odyssey

Nous utilisons une sauvegarde où le personnage est perché sur la statue d’Athènes. Il va se jeter dans le vide et parcourir un chemin précis dans la ville.

Voici les réglages graphiques utilisés, basés sur un preset « High ».

Kingdom Come

Nous réalisons un déplacement sur un chemin précis à côté de l’abbatiale. Nous utilisons le preset Elevé étant donné la gourmandise du jeu.

Autres mesures :

Ces autres mesures concerneront principalement l’overclocking et les nuisances des processeurs.
3 niveaux de charge pour la température et la conso

Nous regarderons ensuite la température du CPU et la consommation de la config. Pour ces deux mesures, nous la ferons en idle, en charge moyenne et en charge lourde. En idle, rien ne tournera sur la config. Par contre en charge moyenne, Watch Dogs 2 sera lancé. En charge lourde, Cinebench sera exécuté sans aucune limite de thread.

La distinction que nous faisons entre la charge moyenne et la charge lourde est là pour représenter par opposition une activité type jeu vidéo et une activité type modélisation 3D. La consommation et la température sont en effet radicalement différentes selon l’usage.

Mesures

Pour les trois niveaux de charge, nous procéderons de la même manière : nous utiliserons HWInfo. Nous laissons la config dans l’état correspondant pendant une quinzaine de minute afin que la température se stabilise. Nous relevons la température moyenne et la consommation moyenne de 300 derniers relevés, à hauteur de 5 relevés par seconde : nous avons donc la mesure moyenne sur une minute. Pour la température, notez que nous utilisons la « Température Package » et pour la consommation la « Consommation Package ». Dans le cas des Ryzen, nous utilisons la température du die.

Rappelons que le mode Windows « Performances Elevées » est utilisé durant tout le protocole. La seule exception est la mesure de conso et de température en idle, pour laquelle le mode utilisée est « Economie d’énergie ».

Overclocking

Dans cette section, nous regarderons quelles fréquences (par palier de 100 MHz)  le processeur est capable d’atteindre et quelle tension lui est nécessaire pour chaque étape. Nous commencerons avec une fréquence donnée (décrétée à 4.0 GHz sur les Ryzen et 4.5 GHz sur les Core i). Puis nous préciserons chaque palier de 100 MHz supplémentaires que le processeur est capable d’atteindre et à quelle tension. Sachez que ces valeurs ne sont pas à prendre au pied de la lettre, car elles peuvent varier d’un échantillon à l’autre. Dans le cas des Ryzen, lorsque nous nous approcherons de la fréquence maximum, les palliers seront plus faibles (50 MHz puis 25 MHz) puisque le CPU autorise les demi coefficients et quart de coefficient.

Voilà comment seront benchés nos CPU. En espérant que cela vous aide à mieux comprendre le choix de nos mesures et comment elles sont relevées. Vous pourrez ainsi reproduire des conditions similaires chez vous.

2
Poster un Commentaire

avatar
1 Fils de commentaires
1 Réponses de fil
0 Abonnés
 
Commentaire avec le plus de réactions
Le plus populaire des commentaires
2 Auteurs du commentaire
geekosaAluncard Auteurs de commentaires récents
  S’abonner  
plus récent plus ancien Le plus populaire
Notifier de
Aluncard
Membre
Aluncard

Mes félicitations pour ce nouveau protocole ! J’espère que vous pourrez tester les futurs Ryzen 3000. Vous êtes bien les dignes héritiers de HFR.