A l'occasion de l'arrivée prochaine des processeurs Ryzen d'AMD, nous avons consacrés ces dernières semaines a l'élaboration d'une nouvelle version de notre protocole de test CPU. Le précédent datant d'aout 2014.

Au delà du choix des logiciels, nous avons souhaités moderniser notre approche, une démarche qui est une étape supplémentaire dans une refonte globale de nos outils, qui avait démarré avec l'utilisation de graphiques HTML5 et plus récemment (vous ne l'avez pas vu) de la refonte de notre interface de publication.

Nous vous présentons aujourd'hui la partie applicative de notre nouveau protocole de test.

Un nouveau protocole applicatif... sous Windows 10

Le premier changement majeur est le passage à Windows 10. La version précédente de notre protocole tournait pour rappel sous Windows 8.1.

Utiliser le dernier Windows est nécessaire pour profiter des dernières nouveautés, notamment côté scheduler pour la gestion fine du multithreading et de la répartition entre les cores, et pour les jeux avec la disponibilité de DirectX 12. Quoique que l'on puisse penser de Windows 10 côté utilisateur, pour nous testeurs cette version apporte des modifications qui vont pratiquement toutes dans le mauvais sens.

Nos besoins sont en effet très différents de ceux d'un utilisateur classique. Nous avons besoin de stabilité côté versions, ce qui va a l'encontre des mises à jour automatiques imposées (dont nous ne renions pas l'utilité pour l'utilisateur) côté système... et côté pilotes !

L'autre problème que nous avions remarqué dans notre test des solutions de streaming est l'augmentation du nombre de tâches systèmes de maintenance pouvant se lancer inopinément. Certaines ne sont pas nouvelles, le .NET App Optimizer était déjà présent sous Windows 8, tout comme Windows Defender (qui était désactivable, aujourd'hui Windows 10 aime le réactiver automatiquement).

Là encore, il n'est pas question de faire un débat sur l'intérêt ou non pour l'utilisateur de ces outils, ou sur l'entêtement de Windows 10 à imposer sa volonté indépendamment de celle de l'utilisateur. Mais en pratique le lancement inopiné d'une tâche gourmande pouvant saturer un coeur est tout simplement inacceptable si l'on veut assurer la constance et la fiabilité de nos tests.

Pour essayer de minimiser au maximum les problèmes, nous avons choisis d'utiliser une version Entreprise de Windows 10, qui offre un peu plus de possibilités. Nous désactivons un grand nombre de choses :

• UAC
• Windows Defender
• Windows Update
• Superfetch
• Le maximum de télémétrie possible
• XboxDVR/GameDVR

La liste est non exhaustive, et une fois de plus nous insistons sur le fait que nous ne recommandons pas cela pour une utilisation classique. Par rapport a une version de Windows ou ces services ne seraient pas désactivés, la différence de performances "maximale" est nulle, ces changements permettent cependant d'éviter une chute de performance inopinée comme nous en avions subis massivement dans notre article sur le streaming.

Avec ces modifications, nous retrouvons une marge d'erreur similaire à celle des versions précédentes de notre protocole, en dessous d'un pour cent.

Côté "version" de Windows 10, nous optons aujourd'hui pour la version Anniversary Update en sachant que nous réévaluerons la question dans les semaines à venir, au cas ou des changements sur le scheduler Windows modifierait les performances. Idéalement nous souhaitons garder une version fixe pour minimiser d'éventuelles variations, même si ce but sera peut être difficile ou impossible à atteindre dans la durée.

Une même philosophie, des applications à jour

Nous souhaitons garder au maximum la philosophie de nos protocoles précédents. L'idée directrice est de tester des d'applications autour de grand thèmes (rendu 3D, retouche photo, etc) avec pour chaque cas deux applications différentes et si possibles représentatives. Ces applications profitent, au moins en partie du multithreading même si ce n'est pas toujours dans les mêmes proportions.

Voici donc les logiciels que nous avons retenus pour l'instant, en notant que certains versions pourraient évoluer :

Compression de fichiers

Nous passons aux dernières versions disponibles pour WinRAR et 7-Zip, en gardant les mêmes fichiers de tests qu'auparavant (nous compressons les fichiers du jeu Arma II) :

• WinRAR 5.40 : Nous utilisons le format de compression RAR5 en mode Ultra
• 7-Zip 16.04 : Le format de compression LZMA2 en mode maximal (9) est utilisé là aussi

Dans les deux cas, la compression est fortement multithreadée. Les versions 64 bits de ces logiciels sont utilisées.

Compilation C++

Là encore, nous mettons à jour les compilateurs :

• Visual Studio 2015 Update 3 : La dernière version en date de Visual Studio est utilisée pour compiler les bibliothèques C++ Boost .
• MinGW 64/GCC 6.2.0 : Nous mettons également à jour GCC qui passe en version 6, nous compilons également les bibliothèques C++ Boost .

On notera qu'avec l'arrivée de l'édition "gratuite" de Visual Studio (Community), beaucoup de projets Open Source ont malheureusement mis de côté le support de MinGW/GCC, c'est une des raisons qui nous a poussé à passer du code source de Blender utilisé précédemment à celui des bibliothèques Boost. Dans les deux cas, le niveau de multithreading est très bon !

Traitement des photos RAW

Nous gardons les deux logiciels de retouche photo que nous utilisions précédemment, dans des versions à jour :

• Adobe Lightroom 6.7 : Nous utilisons la dernière version en date d'Adobe Lightroom. Nous désactivons l'accélération GPU et effectuons des traitements d'export avec notamment une correction d'objectif. Le niveau de multithreading n'a pas beaucoup été amélioré par rapport à l'ancienne version que nous utilisions, nous continuons donc d'effectuer deux exports en parallèle.
• DxO Optics Pro 11.2 : La version 11.2 de DxO Optics Pro est désormais utilisée, nous désactivons les accélérations GPU/OpenCL et réglons le nombre d'images traitées en simultanée sur la valeur maximale supportée (en pratique, le nombre de coeurs physiques, soit 4 pour un 4C/8T). Nous effectuons un export RAW avec là aussi une correction d'objectif.

Dans les deux cas, nous conservons les mêmes bibliothèques d'images que dans notre protocole précédent.

Encodage vidéo

Nous conservons les logiciels x264 et x265, le dernier a particulièrement évolué depuis notre dernière mise à jour du protocole.

• x264 r2744 : Nous utilisons une build 64-bit compilée par komisar  avec GCC 4.9.2.
• x265 2.1 (18/12) : Nous utilisons une build 64-bit compilée ici  avec GCC 6.1.0.

Nous effectuons dans les deux cas un encodage en une passe type CRF. Une version récente de FFmpeg  sert de serveur d'images.

IA d'échecs

Nous gardons là aussi cette particularité de notre protocole, les moteurs d'intelligence artificielle pour les échecs :

• Stockfish 8 : Nous utilisons la dernière version en date du moteur d'échecs open source Stockfish, l'un des deux meilleurs moteurs du moment. Trois exécutables sont disponibles, une version basique, une version SSE4 (popcnt) et une version BMI (Haswell et supérieurs). En fonction des instructions supportées, nous utilisons la version adéquate.
• Komodo 10 : L'autre moteur que nous testons est Komodo qui est passé devant Stockfish et Houdini dans les derniers classements. Il s'agit d'un moteur commercial . Contrairement à Stockfish, un seul exécutable est fourni.

Ces IA sont utilisées dans l'interface Arena , en version 3.5.1.

Rendu 3D

Nous conservons le rendu 3D en mettant à jour les versions de nos logiciels.

• Mental Ray : Nous utilisons la version de Mental Ray livrée avec la version 2017 de 3DS Max.
• V-Ray 3.4 : La version 3.4 de V-Ray, compatible avec la version 2017 de 3DS Max est utilisée.

La scène utilisée dans les deux cas est identique, elle est préparée par Evermotion.

En bref

Globalement ce protocole modernisé reste assez proche de l'ancien dans son esprit, tout en profitant un peu mieux par endroit du multithreading et de logiciels plus à jour.

Afin d'éviter tout problème, nous lançons tous les benchs applicatif deux fois, en redémarrant le système au milieu. Nous conservons le meilleur résultat des deux.

Un protocole automatisé

Pour la première fois nous avons entrepris d'automatiser au maximum notre protocole de test. La liste des benchs à réaliser est longue et demande quasiment une journée pour un seul CPU, réclamant ponctuellement notre attention pour lancer un bench, noter les résultats ou dans de rares cas (Lightroom !) chronométrer manuellement.

Des tâches rébarbatives qui augmentent les risques d'erreurs, il nous est arrivé plusieurs fois de devoir relancer un bench parce que l'on avait raté un résultat affiché trop brièvement (les anciennes versions de DxO !) ou que l'on avait oublié que le bench tournait, tentant de travailler sur autre chose.

Le temps nécessaire pour passer au protocole chaque processeur limitait assez fortement notre capacité à tester un grand nombre de modèles, que ce soit dans les générations précédentes, ou dans les modèles un peu plus d'entrée de gamme.

C'est pour tenter de résoudre tous ces points que nous avons entamé l'automatisation. Elle n'est pas complètement nouvelle, il y a toujours eu une certaine dose d'automatisation dans nos protocoles que ce soit sous la forme de fichiers batchs, ou d'outils customs. Cependant nous n'avions jamais entrepris une automatisation complète.

En pratique, elle commence juste après l'installation de Windows ou un premier utilitaire s'occupe de configurer un Windows 10 Anniversary Update afin de le rendre conforme à nos standards évoqués plus haut. Divers prérequis utilisés par certains benchs ou notre procédure de test sont également installés. Après un dernier redémarrage, la machine redémarre automatiquement dans l'interface de test.

Un bouton en bas à gauche nous permet d'installer en un clic toutes les applications sur le système, de manière 100% automatisée là aussi. C'est un gros gain de temps tant certains applications peuvent être pénibles, et longues à installer (Visual Studio 2015 s'est amélioré par rapport aux versions précédentes, mais demande toujours 17 minutes pour s'installer !). Cela nous permet très rapidement de reconstruire en deux clics un système de bench complet sans devoir utiliser d'images disques, qui nous ont parfois causé beaucoup de problèmes avec les multiples générations de plateformes !

En pratique il faut un clic de plus pour lancer le protocole de bout en bout. Histoire de vous montrer à quoi cela ressemble, nous avons capturé une petite vidéo que vous pouvez voir ci dessous :

La vidéo, vous l'aurez vu, est accélérée, il faut une cinquantaine de minutes (sur un Core i7 6950X !) environ pour réaliser une passe de la seule partie applicative des tests (nous réalisons les tests applicatifs deux fois).

Un autre logiciel nous permet enfin de parcourir et vérifier les résultats, et de générer enfin les graphiques que l'on vous propose dans nos articles :

Et les jeux !

Nos tests processeurs incluent en plus de la partie applicative, une partie jeux sur laquelle nous travaillons encore actuellement.

Les challenges sur les tests de jeux sont cependant plus nombreux. Si l'on peut utiliser les mêmes méthodes sur l'aspect technique, c'est l'environnement des jeux qui a changé ces dernières années qui pose le plus de problèmes. La main mise de Steam sur une grande partie de la distribution des titres crée une situation qui pose quelques problèmes, notamment sur la question des versions.

Si Steam autorisait il y a quelques années que l'on bloque complètement les mises à jour pour un jeu, ce n'est aujourd'hui plus le cas. On a au mieux le choix entre une mise à jour dès que disponible, ou au lancement du jeu. Un problème qui ne se résout malheureusement pas en mode offline, puisque au bout d'un certain nombre de lancements, Steam invalide les exécutables obligeant a se connecter... et donc forcer la mise à jour.

Rester sur une version fixe est important pour garantir l'équité lors de nos tests et si nous avons du combattre aussi les mises à jour automatiques avec Windows et certaines applications, le problème est beaucoup plus présent dans le cadre des jeux.

Nous reviendrons dans les prochains jours sur la question dans un second article, en vous présentant notre sélection.