Extraire les informations essentielles en utilisant powermetrics pour surveiller avec votre outil préféré. Toutefois, soyez prudent et demandez-vous si cela en vaut la peine.

Identifier les noyaux P/E

Contrairement à iOS, c'est heureusement assez facile sur MacOS. En utilisant la fonction intégrée powermetrics nous pouvons identifier les cœurs de performance (P) et les cœurs d'efficacité (E). Malheureusement, je ne possède pas de Mac équipé de Silicium d'Apple, donc ces captures d'écran sont une courtoisie de Matthew Panzarino sur Twitter . Si vous avez le temps, je vous recommande également de lire son article de TechCrunch sur le M1.

> sudo powermetrics -s cpu_power

(Probablement, je ne suis pas sûr à 100% de la commande)

Bien que je n'aie aucune source à ce sujet, je ne serais pas surpris que les cœurs 0-3 soient des cœurs E et les cœurs 4-7 des cœurs P sur toutes les puces M1. Néanmoins, je vous recommande de vérifier par vous-même.

Cool ! C'est parti pour les courses alors, hein ?

Le moniteur d'activité comme exemple

Activity Monitor dispose d'une fonctionnalité intéressante pour surveiller l'utilisation du CPU par cœur, cachée sous Fenêtre -> Historique du CPU (raccourci + 2 .) top/htop/Glances/iStats/Task Manager/quel que soit votre application d'état préférée a probablement quelque chose de similaire.

Cependant, vous remarquerez immédiatement un problème. Si la charge totale de chaque cœur est immédiatement visible, ce qui fait quoi et où ne l'est pas du tout. Vice versa, nous pouvons voir ce qui fait quoi assez facilement si nous regardons la fenêtre normale du moniteur d'activité, mais pas sur quel noyau. Même avec quelque chose comme htop, qui fournit des informations et des outils bien plus puissants que Activity Monitor, il n'est pas facile d'obtenir qu'il montre (même au niveau du processus) ce qui se passe sur tel ou tel noyau.

Programmation et autres (en quelque sorte)

C'est à ce stade que nous devons tenir compte du fait que les programmes ne fonctionnent pas toujours sur un seul cœur. Je vous préviens : Je ne suis en aucun cas un expert en système d'exploitation, je vais donc faire de mon mieux pour aborder les choses d'un haut niveau. S'il y a des erreurs, n'hésitez pas à les corriger ou à laisser un commentaire !

Les systèmes modernes contiennent généralement au moins un ordonnanceur, géré par le système d'exploitation (généralement au sein du noyau), qui décide de ce qui doit être exécuté à quel moment et sur quelles ressources physiques. Sous MacOS (et autres Darwin ), cela prend la forme d'une file d'attente dans le noyau Mach. Cependant, les systèmes d'exploitation d'Apple contiennent également une deuxième couche de bibliothèques conçues pour aider à cette tâche à un niveau supérieur. La bibliothèque Grand Central Dispatch ( GCD ) est en quelque sorte l'approche principale d'Apple à cet égard : il contient tout un tas de classes utiles qui peuvent être utilisées par les développeurs pour les aider à optimiser leur application. À son tour, GCD planifie le code pour qu'il s'exécute sur une variété de threads, qu'il laisse au système d'exploitation le soin de décider ce qui doit être exécuté sur tel ou tel noyau. Tout cela est constamment échangé et modifié pour utiliser au mieux les ressources matérielles disponibles.

J'espère qu'il est possible de voir comment les choses sont un peu désordonnées à ce stade. Bien que cela ne soit en aucun cas impossible à démêler, c'est un peu délicat, surtout lorsque tant d'outils ont été construits en supposant des cœurs homogènes.

Solutions

Idéalement, nous voudrions quelque chose qui (groupé par processus) montrerait combien chaque noyau individuel a été utilisé par tous les threads appartenant à ou utilisés par ce processus. Malheureusement, je n'ai rien pu trouver. Le problème est que tout ce que j'ai trouvé n'enregistre pas ce qui utilise quel noyau d'une manière facile à gérer. Par exemple Nous voulons savoir à quel processus appartiennent les threads et sur quel noyau un thread tourne. htop ? Facile, activez la vue arborescente et activez la colonne PROCESSOR. Mais vous voulez qu'elle soit triée en fonction des processus qui utilisent le plus de cœurs ? Bonne chance.

Même si je suis sûr qu'il y a un moyen de le faire fonctionner - au moins, ce sont des outils open source - ce n'est pas quelque chose de facile ou de direct à ma connaissance. En dehors de ces outils d'usage général, existe-t-il une autre option ?

Profilage

Comme avec une architecture CPU homogène, si vous voulez vraiment savoir ce qui se passe dans votre application, la meilleure façon de le faire est de la profiler. C'est le cas, entre autres, pour savoir sur quel cœur vous travaillez.

La manière dont vous allez procéder va dépendre de la façon dont votre application est construite. Pour les applications Mac natives, Les instruments d'Apple (intégrés à Xcode) peuvent fournir un excellent aperçu de ce qui est exécuté et où. Pour les applications Electron, vous pouvez utiliser les outils suivants Outils de performance d'exécution de Chrome puisque Electron est en fait Chrome ; cependant, je ne suis pas particulièrement familier avec lui.

Le problème, c'est qu'ils sont conçus comme des outils de développement. Ils demandent une certaine configuration, ils nécessitent (généralement) un accès au code source (ou quelque chose de similaire) pour bien fonctionner, ils fournissent beaucoup d'informations et ils ne sont pas toujours les plus faciles à utiliser. Ce qui nous amène au point suivant :

Pourquoi ?

Je suis comme tout le monde un adepte du savoir pour savoir ; c'est génial de pouvoir voir ce qui fait quoi et de jouer avec son flux de travail. Mais considérez une seconde ce que vous voyez réellement : des chiffres (probablement) très situationnels et compliqués avec lesquels il est franchement difficile de travailler. L'optimisation d'un logiciel est déjà assez difficile lorsque c'est votre travail ; en tant qu'utilisateur final, c'est un tout autre jeu.

Donc, même si j'aimerais le voir autant que la personne suivante, je suggère peut-être de ne pas trop s'en inquiéter. Regardez l'utilisation totale par cœur, bien sûr ; regardez la consommation d'énergie par application. Mais en termes de ce qui est sur quel cœur dans quelles conditions, ne vous inquiétez pas pour ça.

Bien sûr, si quelqu'un trouve un outil, j'aimerais le voir :)