Lazer Posté(e) le 4 novembre Auteur Signaler Posté(e) le 4 novembre Je n'ai pas inventé cette formule de calcul, j'ai repris celle que j'ai trouvé quelque part... sans certitude, mais je crois que c'est de @Steven qui l'avais partagé sur le forum, à l'époque de la HC2. En fait cette formule est un grand classique du calcul d'utilisation CPU sur un ordinateur... les métriques remontés par le noyau donnent un temps processeur cumulé (en "tick" processeur, c'est l'unité élémentaire, basée sur le cycle d'horloge, donc le plus petit temps possible), cela pour l'ensemble des cœurs actifs. C'est valable pour les différents systèmes d'exploitation, Linux, AIX, etc... (Windows aussi je suppose, je n'ai jamais développé avec les API de performance sur cette plateforme). Il faut donc diviser le temps total mesuré par le nombre de cœurs installés pour obtenir le bon pourcentage d'utilisation moyen de la machine. Le facteur 4 c'est juste à cause du nombre de cœurs dans le processeur de la HC3, je crois de mémoire que c'est seulement 2 dans le cas de la HC3 Lite. D'où l'utilisation de la variable nbCPUs qui compte le nombre de cœurs dans la formule. Pour s'assurer de la fiabilité de cette formule effectuée en LUA, il faudrait effectuer un benchmark. Pour cela, écrire un code LUA dans un QuickApp, qui tourne en boucle "à fond la caisse", par exemple en faisant un calcul mathématique simple, et cela pendant de longues minutes. Le code LUA du QuickApp étant mono-threadé, il sera affecté à un seul cœur du processeur. Ce cœur sera donc à 100%. La HC3 disposant de 4 cœurs, la charge moyenne du processeur sera donc de 25% (en pratique un peu plus, car la HC3 fait aussi d'autre choses : moteur Z-Wave, autres QuickApps, scènes, et interface Web qui consomment tous un peu de CPU) La formule de calcul, devrait donc donner un résultat approximativement autour de 25% (1 cœur à 100%, divisé par 4 cœurs pour moyenner sur le processeur du système) Cependant, il y a une grosse limitation. L'API /diagnostics remonte les informations fournies par le noyau Linux, donc précises, sur l'ensemble du système (incluant donc la totalité des processus tournant sur la machine... tant les processus utilisateurs (QuickApps, Scènes, les différents binaires Fibaro) que les processus systèmes (noyau, librairies de gestion des entrées/sorties (stockage, réseau, etc). Cependant, la commande collectgarbage("count") utilisée en LUA pour récupérer la consommation CPU du QuickApp, ne compte que le processus utilisateur proprement dit (rappel : 1 QuickApp = 1 processus utilisateur sous Linux). Impossible donc, depuis un QuickApp, de mesurer l'activité induite par le QuickApp, à savoir les autres processus systèmes et noyau. Exemple, un QuickApp qui appelle l'API de la box fait travailler le serveur Web embarqué ainsi que d'autres processus Fibaro. Cette activité sera "vue" par l'API système /diagnostics, mais pas par l'API LUA locale. De même pour un QuickApp qui fait des requêtes réseau, des affichages dans la console de debug, ou déclenche des activités sur les autres modules (physiques ou QuickApps....) Quoi qu'il en soit, mon test de benchmark proposé précédemment, s'il se contente de faire un calcul mathématique simple en local (une simple addition suffit... ou même pas de calcul du tout, ça peut être une bête boucle infinie de type "while true do end") devrait théoriquement limiter l'activité externe induite par le QuickApp, et donc permettre d'approcher les 25% de charge moyenne de la box, tout en étant lui-même à 100% sur un seul cœur. Ou tout du moins, un bon ordre de grandeur (étant donné, encore une fois, que la box fait aussi autre chose en même temps) Pas simple l'analyse de performance en informatique... Il y a 5 heures, yves.guern a dit : Si un CPU à 4 cœurs est occupé à 20% au total (ie la valeur de cpuDelta/elapsedTime*100) cela signifie que les 4 cœurs sont aussi chargés à 20% (en moyenne) même s'ils n'ont fait chacun que 1/4 du travail total. Oui mais attention, ce cas que tu décris n'est qu'un cas particulier où la charge est équilibrée sur l'ensemble des cores, ce qui est hautement improbable (statistiquement on s'en approche tout de même sur un système chargé avec un grand nombre de processus, car le noyau Linux fait de son mieux pour équilibrer la charge sur les différents cores) Par ailleurs, si tu as suivi mon exposé, tu peux avoir 1 core à 100%, et les autres qui ne font rien, ça fait 25% en moyenne. Ou n'importe quelle autre combinaison de charge de travail (ce qui, dynamiquement, change un grand nombre de fois chaque seconde lorsque le noyau rééquilibre les processus sur les cores) Il y a 5 heures, yves.guern a dit : Dit autrement: 4 cœurs à 100% = 1 CPU à 100% ? Oui. 2
yves.guern Posté(e) le 5 novembre Signaler Posté(e) le 5 novembre Bonjour Lazer, Si tôt dit, si tôt fait, c'est ça le jeune retraité... J'ai fait le test que tu proposes sur un HC3 de secours qui n'avait que cela à faire (lui aussi ) Ce qui est sûr: Le 04/11/2024 à 14:05, Lazer a dit : Pas simple l'analyse de performance en informatique... Et en particulier si on mélange temps CPU et temps d'un core. J'ai donc fait une QA avec une boucle originale qui incrémente la variable j pendant 'un certain temps'. (code joint) Je mesure ce qui est mesurable à la fois par os.clock() & os.time() ainsi qu'avec api.get("/diagnostics") en parallèle sur la même exécution. Voici les résultats: (RQ: HC3 a un CPU 4 cœurs) Résultats de os.clock() & os.time() Durée du test: 66s, Occupation= Delta clock()/Delta Time() = 98.9% Résultats de api.get("/diagnostics") en ticks: | en %: Objet idle system user | idle system user Core 1 6340, 62, 52 | 98.2%, 1.0%, 0.8% Core 2 , , 6527 | 0.0%, 0.0%, 100.0% Core 3 6382, 58, 49 | 98.4%, 0.9%, 0.8% Core 4 6310, 98, 41 | 97.8%, 1.5%, 0.6% Total(CPU) 19032, 218, 6669 | 73.4%, 0.8%, 25.7% Commentaires: La QA s’exécute bien sur 1 seul cœur (ici le Core2) et l'occupation 'user' des autres est quasi nulle L'occupation de ce cœur est bien de 100% Le CPU est bien occupé à 25% (il n'y a que cette QA qui s'execute) Ce dont je n'étais pas conscient c'est que le résultat obtenu par os.clock() n'est pas un temps CPU mais un temps 'cœur' (celui de la QA où l'on pose la question) => si clock/time = 100% cela veut dire que la QA est à fond (mais pas que le CPU l'est). Donc tu as raison. Il faut diviser le temps obtenu via clock/time par le nombre de cœurs pour connaitre la charge que donne une QA au CPU. Ce que je retiens: (Delta clock()/Delta Time()) donne le pourcentage d'occupation du cœur sur lequel s’exécute une QA Une QA s'exécute dans un seul thread et(donc) sur un seul cœur. => Exprimé en % de temps CPU la charge maximale dont dispose une QA est de 25%. (je crois que c'est cette exécution mono thread dont je n'avais pas vu toutes les conséquences) Donc, pour une grosse QA mal foutue, clock/time est plus intuitif et les doses de dopamine plus fortes (4 fois environ) en cours d'optimisation par son auteur . A+ TempsCPU_HC3.lua 1
Lazer Posté(e) le 5 novembre Auteur Signaler Posté(e) le 5 novembre Au top ta mise en pratique Il y a 3 heures, yves.guern a dit : (Delta clock()/Delta Time()) donne le pourcentage d'occupation du cœur sur lequel s’exécute une QA Comme j'aime compliquer les choses, si on avait la possibilité de faire tourner des QuickApps Multi-thread, alors on pourrait faire exécuter notre code en parallèle sur 2, 3 voire 4 cœurs, maximisant ainsi l'utilisation du CPU, et cela afin de .... : Il y a 3 heures, yves.guern a dit : et les doses de dopamine plus fortes (4 fois environ) en cours d'optimisation par son auteur Sérieusement, si on appliquait la formule sans la diviser par le nombre de cœurs, notre QA multi-threadé nous ferait croire qu'on dépasse les 100% d'utilisation (puisque 2 ou plus cœurs travaillent simultanément), ce qui est impossible. Cela dit, je ne te souhaite pas de faire un jour de la programmation multi-thread, sauf si tu aimes te faire des nœuds au cerveau. C'est ultra puissant, mais ça peut vite devenir un vrai sac de nœuds, car on ne maitrise alors plus du tout l'ordre d'exécution du code des différents threads de notre programme, avec des effets de bords pas du tout sympa comme une variable qui est lue avant d'avoir été écrite, ou bien une autre variable qui change de valeur pendant le calcul d'une formule se basant sur cette variable. On doit alors utiliser des mutex et autres joyeusetés du même genre pour gérer de tels conflits d'exécutions... et assez rapidement on conçoit des programmes qui plantent tout seuls, sans prévenir, simplement parce qu'ils se bloquent si plusieurs threads s'attendent l'un et l'autre... Sur le LUA de la HC3, Fibaro nous a proposé un truc très sympa, qui est aussi mis en oeuvre dans tous les langages modernes (JavaScript, etc), c'est l'asynchronisme, dont il y a déjà plusieurs discussions à ce sujet sur le forum. Cela permet, tout en conservant un programme mono-thread, de faire s'exécuter le code de façon non linéaire, puisqu'une fonction peut se terminer (rendre la main au système), ou bien se mettre en attente (du retour d'une requête réseau, un timeout, etc) et ainsi permettre à d'autres bouts de code de s'exécuter. C'est une sorte de multi-thread simplifié, sans l'être vraiment. Tient, d'ailleurs, on peut faire du multi-thread sans forcément avoir plusieurs cœurs, 1 seul suffit... et ça fonctionne ainsi depuis les vieux ordinateurs mono-processeur et mono-cœur. De même, on peut n'avoir que des programmes mono-thread sur un ordinateur multi-processeur et multi-cœur, comme expliqué précédemment, c'est le job du noyau du système d'exploitation que de répartir les programmes et/ou threads sur les différents cœurs/processeurs de la machine. En revanche, comme dit, pour s'exécuter sur plusieurs cœurs et/ou processeurs, un programme doit impérativement être multi-thread. Conséquence de ça, lors de l'apparition des premières machines à plusieurs processeurs (mono-thread) puis des premiers processeurs multi-thread, les applications étaient plus lentes sur la nouvelle génération de machine, bien que vendue plus cher avec l'argumentaire marketing de la performance accrue. En effet, les applications en ce temps là (euh... c'est encore le cas aujourd'hui pour certains programmes.... les QA par exemple, bon mais c'est aussi vrai sur les PC, Smartphones, etc) étant développées en mono-thread, elles étaient incapables de bénéficier de la puissance de calcul supplémentaire apportée par les processeurs/cœurs supplémentaires, l'application est littéralement bridée, ce que démontre parfaitement ton benchmark, incapable d'exploiter la puissance de calcul totale de la machine. Pire que ça, la vitesse d'exécution était réduite, car à génération équivalente, un core sur un processeur mono-core est plus performant qu'un seul core sur un processeur multi-core... cela est dû aux mécanisme interne du processeur qui "perd" du temps à faire fonctionner plusieurs cores en parallèle, ne serait-ce parce qu'en interne, dans sa file d'attente des instruction à exécuter, il doit les diriger vers le bon core. Les joueurs sur PC connaissent bien ce phénomène, plusieurs fois, sur le dernier processeur Intel sorti les performances sont moindre, jusqu'à ce que le studio de développement propose une mise à jour du jeu pour mieux gérer le multithread et le spécificités du nouveau processeur. Déjà vu sur smartphone, avec les processeurs Qualcomm par exemple.
yves.guern Posté(e) le 5 novembre Signaler Posté(e) le 5 novembre il y a 4 minutes, Lazer a dit : Cela dit, je ne te souhaite pas de faire un jour de la programmation multi-thread, sauf si tu aimes te faire des nœuds au cerveau C'était un gros morceau de mon boulot avant la retraite, je crois bien que c'est pour cela que je me suis fait un nœud là . L’asynchrone rime facilement avec le multithread cela ne m'a donc pas réveillé Évidement tout cela ce n'est ni du temps réel ni des traitements complexes mais finalement je trouve que le HC3 fait beaucoup de choses proprement et vite. J'ai environ 40 QA qui tournent pour moins de 15% de CPU en tout: ya encore de la marge!
Lazer Posté(e) le 5 novembre Auteur Signaler Posté(e) le 5 novembre Ah bah alors tu as connu ça Oui, la HC3 est une chouette machine, dont on sous-exploite le potentiel. Je suis en moyenne autour des 11% de CPU la nuit (peu d'activité Z-Wave, et de déclenchement des scénarios instantanés GEA), tandis que ça oscille globalement entre 15 et 22% en cas de présence la journée, avec quelques petits pics au delà de 25%.
Messages recommandés