L’Apple M1 qui équipe tous les Mac Apple Silicon sortis jusque-là ainsi que les derniers iPad Pro est équipé d’un CPU doté de huit cœurs, quatre rapides et quatre économes. Ces derniers sont moins puissants, mais ils consomment aussi nettement moins et ils sont utilisés pour prolonger l’autonomie des appareils pour les tâches secondaires, celles qui nécessitent moins de puissance et celles qui tournent en tâche de fond.
Cette conception asymétrique est bien connue dans le monde mobile, puisqu’Apple l’utilise dans toutes ses puces destinées aux iPhone et iPad depuis 2016. Leur arrivée au sein de macOS offre une nouvelle opportunité : on peut analyser ce qui se passe au niveau du CPU, comment chaque type de cœur est utilisé et aussi la puissance relative des deux types. Plusieurs tests théoriques ont ainsi été menés, mais le développeur Howard Oakley a trouvé une méthode pour réaliser un test en conditions réelles.
Ce développeur a exploité à nouveau la méthode de Quality of Service (QoS) pour forcer macOS à exécuter du code sur les cœurs puissants, nommés Firestorm, puis sur les cœurs économes, nommés Icestorm. Cette qualité de service est une manière d’indiquer au système la priorité d’une tâche et c’est elle qui explique pourquoi les Mac Apple M1 semblent aussi fluides, comme nous l’avions détaillé dans un précédent article :
Comment l’iPhone a appris au Mac à mieux utiliser ses cœurs
Grâce à cette technique, il a mesuré le temps nécessaire pour chaque quatuor de cœurs pour exécuter quatre tâches basiques. Il s’agit à chaque fois d’un calcul réalisé sur des nombres flottants, une tâche de base qui est souvent utilisée pour mesurer les performances d’un processeur. Quatre méthodes différentes ont été utilisées pour ce calcul, du plus bas niveau (code assembleur) jusqu’au plus haut, avec du code Swift tel qu’on en croiserait dans une app macOS. Les performances ont été mesurées à chaque fois sur un Mac avec une installation de macOS de base, sans toucher au système et sans ajouter des extensions du noyau supplémentaires, ce qui était le cas pour les tests plus théoriques menés jusque-là.
Les résultats obtenus par le développeur montrent que les cœurs économes sont en effet plus lents, mais que la différence peut être limitée avec du code bien optimisé. Avec la méthode Apple simd, une solution bas niveau fournie par le constructeur, les quatre économes ne sont que deux fois plus lents que les rapides, une belle performance quand on pense qu’ils ne nécessitent qu’un quart de l’énergie des cœurs rapides.
L’écart se creuse plus on s’éloigne des langages bas niveau. Avec du Swift basique, les cœurs économes sont trois fois plus lents, mais en ajoutant du code plus complexe, souvent indispensable dans les apps, ils sont cinq fois et demi plus lents. À l’usage, les cœurs rapides gardent toujours l’avantage et c’est bien logique, mais même avec des tâches cinq fois plus lentes quand elles sont exécutées sur les cœurs économes, l’asymétrie de l’Apple M1 reste utile.
Les ordinateurs passent beaucoup de temps à effectuer des tâches qui ne sont pas urgentes et qui peuvent nécessiter plus de temps d’exécution sans problème. Pour macOS, c’est le cas notamment de l’indexation Spotlight ou encore de l’analyse de la photothèque, pour donner deux exemples. Ces tests prouvent que dans certains cas, un développeur peut aussi optimiser son code pour limiter l’écart et utiliser au maximum les cœurs économes pour son app.
