Optimiser son code pour Tiger Lake, oui, c'est intéressant !

Si, avec l’avènement des systèmes d’exploitation grand public, en particulier Windows, et les efforts bienvenus des géants des semiconducteurs, nous avons désormais l’habitude d’avoir du matériel (presque toujours) fonctionnel et performant peu après leur sortie officielle, cela n’est en rien une règle générale. En effet, les nouvelles fonctionnalités des CPU next-gen nécessitent parfois des modifications logicielles, la plus simple d’entre elles étant la recompilation du projet, assortie d’une option indiquant la famille de processeur pour laquelle optimiser, si tant est qu’Intel ou AMD ait préalablement effectué l’ingénierie nécessaire sur ledit compilateur.

Fort heureusement, tel est souvent le cas, un fait confirmé chez Phoronix, notre confrère spécialiste de Linux, qui s’est attelé à la tâche dans un sympathique dossier étudiant les variations de performances selon l’architecture spécifiée au compilateur pour l’optimisation. Les expériences sont réalisées avec un ordinateur portable — forcément, il n’y a que cela de disponible pour du 10 nm — de marque Dell, plus précisément un XPS 9310 Intel EVO qui intègre un Core i7 1165G7, Tiger Lake bien entendu, le tout sous Ubuntu 20.10 et GCC 11.0.

Tiger Lake, finalement plus qu’une simple mise à jour des contrôleurs intégrés ?

Et, globalement, plus on optimise pour une architecture récente, mieux c’est : l’architecture par défaut, X84-64 (générique) se retrouve tout derrière, suivi par Sandy Bridge, puis Haswell, Skylake, et, juste avant notre compétiteur, nous trouvons, à une certaine distance... Icelake. Étrange, puisque la microarchitecture Sunny Cove, à l’œuvre dans les cœurs de ces processeurs, est censée être extrêmement proche du Willow Cove de Tiger Lake. Pourtant, les tests révèlent 4 % de performances supplémentaire en moyenne géométrique, un score loin d’être anodin. Y aurait-il d’autres améliorations non divulguées dans Tiger Lake ? Des correctifs pour des nouvelles failles intégrées en hardware pour gagner du temps ? Ou, tout simplement, Intel aurait-il stoppé son optimisation de GCC pour Ice Lake, étant donné la faible présence de ce dernier sur le marché ? Impossible de trancher dans les conditions actuelles. Par rapport à un binaire sans optimisation, les gains sont alors de 9 % : pas si mal ! Pour plus de détails, notamment les tâches les mieux optimisées par GCC, il va falloir passer sur le site originel, en anglais !