Ce que les benchmarks nous disent… ou pas
Si puissance ne rime pas toujours avec efficacité, à quoi servent les tests que nous publions régulièrement. Sommes-nous des pousse-au-crime encourageant l’achat de matériel onéreux sans fondement ? C’est tout le problème des logiciels de test, et de la m
Tors qu’ un ex te courant constructeur sort une nouvelle puce, il nous appartient d’en évaluer les apports en termes de gains de performance. Pour le faire, des outils spécifiques sont utilisés. Souvent les mêmes d’une génération à l’autre afin de conserver une base de comparaison aussi pertinente que possible. Mais ces outils ont un défaut : ils sont bien faits. En effet, ils permettent d’évaluer différents scénarios d’utilisation, utilisant par exemple un coeur ou plusieurs, en limitant les fréquences ou en les poussant à fond, en utilisant ou non tel ou tel jeu d’instructions, etc. Pour les CPU, l’un des outils préférés des testeurs est Ce dernier simule un rendu 3D, et est parfaitement « multi-threadé », c’est-à-dire qu’il sait parfaitement utiliser tous les coeurs CPU disponibles. D’où un avantage très net aux architectures bourrées de coeurs, comme les derniers Threadrippers d’AMD par exemple.
Ne pas sauter à la conclusion
Le piège serait de sauter directement à la conclusion et d’en déduire que le processeur X ayant obtenu un score 30% supérieur à celui du processeur Y au même test sera plus performant ( primo) et dans les mêmes propor tions (deuzio). En effet, les benchmarks ne livrent que des résultats théoriques. Une théorie qui, pour devenir réalité, voudrait que les logiciels que vous utilisez au quotidien soient programmés de la même manière. Si vous faites de la vidéo par exemple, tous les éditeurs n’utiliseront pas votre matériel de la même façon. Et au sein de chaque programme, différentes actions ou modifications pourront faire ou non appel au plein potentiel de votre machine. Un exemple concret : disposant des dernières versions de Lightroom CC (via abonnement au Creative Cloud), nous avons récemment voulu convertir des années de fichiers RAW de chez Nikon et Fujifilm en DNG Adobe, puisque le format prend moins de place et conserve les mêmes informations. Sélection des milliers de photos, lancement du module de conversion et… surprise devant les temps de traitement annoncés, incroyablement longs. En analysant les sollicitations hardware du processus, on se rend compte qu’en 2018, cer tains modules de programmes au demeurant bien multi-threadés n’utilisent encore qu’un seul coeur CPU et aucun GPU. Et pour couronner le tout, en passant sur Mac, on se rend compte que le même module de conversion du même programme est là capable d’utiliser tous les coeurs CPU et de solliciter le GPU. L’exemple est intéressant car il permet de mesurer la difficulté à laquelle on fait face lorsqu’on veut optimiser son travail : chaque programme est codé différemment, et à l’intérieur de ces programmes différents modules et différentes actions sont aussi codées de différentes manières. Rappelonsnous des débuts du support du GP-GPU dans l’édition vidéo : chez la plupart des éditeurs, le GPU ne servait à l’origine qu’à fluidifier la prévisualisation des effets appliqués dans la timeline… mais ne servait pas à accélérer les rendus d’exportation. De ces exemples, on tirera plusieurs conclusions, la première étant que le matériel n’est jamais en cause. Ce n’est pas de la faute d’Intel, AMD ou nVidia si les éditeurs ne modifient pas ou pas assez bien le code de leurs outils pour qu’ils puisent dans le potentiel offer t par le matériel. La seconde leçon est que l’optimisation est une tâche extraordinairement ardue nécessitant une connaissance très approfondie des outils logiciels que vous utilisez. Connaissance souvent rendue opaque par la complexité de ces mêmes outils. Ce sont de vrais couteaux suisses disposant de divers modules permettant d’effectuer autant d’opérations (par exemple pour la vidéo : monter, placer des transitions, des effets, ajuster la colorimétrie, etc.). Troisièmement enfin, les benchmarks ne mentent pas et permettent d’affirmer qu’une puce est plus puissante qu’une autre et dans quelles proportions. Ce que le benchmark ne sait pas faire, c’est sortir du cadre purement théorique et plonger dans le détail de votre flux de travail.