Obligement - L'Amiga au maximum

Jeudi 17 août 2017 - 11:29  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


En pratique : Présentation et utilisation de Hieronymus
(Article écrit par Mathias Parnaudeau - septembre 2010)


Hieronymus : mais qui es-tu ?

Un nom et une fonctionnalité qui laissent perplexe ! Lors du week-end Amigâteries, début mars 2010, Daff m'a fait remarquer qu'il serait bon d'avoir un article décrivant à quoi sert Hieronymus, ce qu'il fait et comment il le fait. Communiquer plus sur lui devint, après coup, une évidence. L'autre remarque de Daff (décidément toujours pertinent) fut que le mieux placé pour en parler... était son créateur. Il faut vraiment tout m'expliquer ! En retour, c'est donc moi qui vais tout vous raconter.

Le chasseur de lenteurs

Parmi les outils de développement, il en existe qui sont destinés à traquer les goulots d'étranglement d'un programme, à comprendre où il passe son temps. On les appelle des profileurs, comme les policiers chargés d'analyser des faits et des comportements pour comprendre comment fonctionne un criminel. Sauf qu'ici, la cible, c'est un programme lent ! Un programme peut déjà lui-même collecter des informations à publier lorsqu'il se termine, incrémentant des compteurs ou additionnant des durées. Par exemple, dans Sonix, qui contrôle une webcam, je mesure le temps mis pour récupérer une image, pour la décoder, pour l'afficher. Il ne sert à rien de vouloir optimiser la fonction de décodage si le transfert est déjà 20 fois plus lent. Le résultat ne sera pas visible. La collecte manuelle de ces informations reste fastidieuse.

Dans la suite d'outils associés à gcc, il existe gprof depuis des années. L'exécution d'un programme compilé avec des options particulières permettra, automatiquement cette fois-ci, de savoir combien de fois chaque fonction a été appelée, pendant combien de temps, etc. C'est déjà pratique mais il faut recompiler le code spécifiquement pour collecter des données et cela peut avoir une influence sur le comportement du programme, bien que si quelques fonctions sont responsables de la majorité du temps passé, elles seront détectées.

C'est statistique, mon cher Harry

Hieronymus est un profileur statistique simple dont le fonctionnement de base repose sur un outil Linux appelé oprofile. Le principe repose sur l'abonnement à une source d'interruption qui va périodiquement suspendre le programme en cours dans le système pour donner la main à un "handler" d'interruption. Ainsi, à une fréquence donnée (50 fois par seconde dans notre cas), cette fonction handler est appelée avec en paramètre un contexte d'interruption indiquant l'état du processeur au moment où l'interruption est survenue. Ce contexte (voir l'include "exec/interrupts.h") contient les valeurs de tous les registres du processeur et notamment celui qui nous intéresse directement pour la fonctionnalité de base : le pointeur d'instruction (IP). Il indique à quelle adresse le système devra sauter quand l'interruption aura été traitée pour reprendre l'exécution normale du programme suspendu.

Cinquante fois par seconde, Hieronymus sauve dans un tableau d'échantillons la valeur du pointeur d'instruction. Pour chacune de ces valeurs, une autre fonction du système permet à partir de cette adresse de déterminer le processus concerné et à quel endroit (offset) on se trouve dans le code du programme.

La dernière étape consiste à trouver à quelle fonction l'offset correspond. Pour cela, il n'y a pas d'autre solution que de trouver l'exécutable (au format ELF) et de chercher à quel symbole l'offset appartient. Par symbole, on entend dans notre cas le nom de la fonction associée.

Après ces indications techniques, prenons un peu de distance pour mieux comprendre le fonctionnement général. Avec une durée d'échantillonnage suffisamment grande, on sait déterminer la proportion du temps passé dans chacun des programmes du système mais on obtient aussi le profil d'exécution d'un programme, c'est-à-dire le nombre de fois où il se trouvait dans telle ou telle fonction quand il a été interrompu. On appelle cela du profilage statistique : si de manière périodique, dans 60% des cas où on interrompt un programme, on constate qu'il se trouve dans une fonction donnée, on peut dire que le programme passe 60% de son temps dans cette fonction (à traiter de toute urgence !).

Avantages, usage et résultats

Par rapport à un outil comme gprof, Hieronymus ne demande aucune modification du programme, il suffit que ce dernier ait été compilé avec l'option de débogue classiquement utilisée en cours de développement, afin d'avoir accès aux symboles cités plus haut. Il n'est donc pas intrusif.

Un autre avantage est qu'il trace ce qui est en cours d'exécution, ce qui inclut aussi les bibliothèques dynamiques, contrairement à gprof. Cela donne une idée pour savoir si un problème vient de la lenteur d'un algorithme dans le programme ou si ce dernier appelle trop souvent des fonctions système liées au graphisme, au réseau, etc.

Enfin, Hieronymus est simple à utiliser. Il n'y a qu'à le lancer, via un Shell, sans aucun paramètre. Le seul argument actuellement disponible dans Hieronymus est le temps d'acquisition (défaut = 8 secondes) que l'on peut modifier avec "hieronymus duration=20" pour par exemple passer à 20 secondes. Il va alors collecter tranquillement les informations sur l'activité du système et des programmes qui s'y exécutent jusqu'à ce que le temps imparti soit écoulé, après quoi il affiche un rapport d'analyse comme on le voit ici avec Word Me Up XXL. Le rapport est légèrement simplifié ici pour ne pas être trop long :

count = 0029, percent = 01, name = LIBS:ft2.library
  Offset = 0x00052974, Count = 0029, Function = <NOT FOUND>
count = 2019, percent = 84, name = Kickstart/kernel
  Offset = 0x00011e18, Count = 0026, Function = <NOT FOUND>
  Offset = 0x0000cf68, Count = 1969, Function = HAL_TaskPostTerm
  Offset = 0x00025ec0, Count = 0005, Function = Internal_MemCpy
  Offset = 0x0001bfbc, Count = 0005, Function = _impl_FindTask
  [couic !]
  Offset = 0x000274c4, Count = 0001, Function = _impl_CacheClearE
  Offset = 0x00042b60, Count = 0001, Function = _FindTagItem
count = 0012, percent = 00, name = Kickstart/timer.device.kmod
  Offset = 0x000019d8, Count = 0012, Function = <NOT FOUND>
count = 0186, percent = 07, name = Kickstart/rtg.library
  Offset = 0x00062430, Count = 0186, Function = <NOT FOUND>
count = 0007, percent = 00, name = CLASSES:datatypes/png.datatype
  Offset = 0x00006b58, Count = 0007, Function = <NOT FOUND>
count = 0008, percent = 00, name = CLASSES:datatypes/picture.datatype
  Offset = 0x00003ee4, Count = 0008, Function = <NOT FOUND>
count = 0008, percent = 00, name = Kickstart/graphics.library.kmod
  Offset = 0x00012a28, Count = 0008, Function = <NOT FOUND>
count = 0004, percent = 00, name = WordMeUpXXL
  Offset = 0x00005d24, Count = 0004, Function = <NOT FOUND>
count = 0022, percent = 00, name = LIBS:xadmaster.library
  Offset = 0x0003ae1c, Count = 0022, Function = <NOT FOUND>
count = 0028, percent = 01, name = CLASSES:datatypes/aiff.datatype
  Offset = 0x000011b0, Count = 0028, Function = <NOT FOUND>
count = 0013, percent = 00, name = LIBS:Picasso96API.library
  Offset = 0x00000e14, Count = 0013, Function = <NOT FOUND>
count = 0056, percent = 02, name = Kickstart/ATIRadeon.chip
  Offset = 0x00000750, Count = 0056, Function = <NOT FOUND>

Summarized results :

Percent | Program
    1   | LIBS:ft2.library
   84  | SYS:Kickstart/kernel
    0   | SYS:Kickstart/timer.device.kmod
    7   | SYS:Kickstart/rtg.library
    0   | CLASSES:datatypes/png.datatype
    0   | CLASSES:datatypes/picture.datatype
    0   | SYS:Kickstart/graphics.library.kmod
    0   | Games:WordMeUpXXL/WordMeUpXXL
    0   | LIBS:xadmaster.library
    1   | CLASSES:datatypes/aiff.datatype
    0   | LIBS:Picasso96API.library
    2   | SYS:Kickstart/ATIRadeon.chip

Qu'est-ce qu'on peut en dire ? On constate que 84% du temps est passé dans le noyau mais toujours dans la même fonction. Ça ne veut pas dire que le système consomme toutes les ressources, on est ici en présence de la fonction IDLE, elle attend qu'un programme nécessite du temps d'exécution pour le scheduler. Word Me Up XXL n'est donc pas gourmand : lui et ses dépendances consomment 16% du temps processeur, dont la moitié dans la "rtg.library".

Dans le cas de DOSBox, l'essentiel du temps est passé dans la fonction qui décode les instructions à émuler, les résultats sont similaires à ce que donne oprofile sous Linux PPC. Pour OWB, on revient à un cas semblable à Word Me Up XXL, à savoir 17% d'utilisation du processeur dont 7% dans le programme lui-même et 6% dans la "rtg.library".

Hieronymus
ScummVM vu par Hieronymus

Hieronymus
Giana Sisters vu par Hieronymus

Un bonus pour la route

Une autre fonctionnalité a été ajoutée dans le but d'étudier la performance d'un programme, où plutôt l'impact sur les caches du processeur. En effet, depuis plusieurs années, les processeurs intègrent des aides au diagnostic concernant des dizaines ou des centaines d'événements qui se passent dans le processeur et sont regroupés sous l'appellation "performance monitor". Comme cela touche à des points très précis et compliqués, je ne parlerais que du type d'événements utilisés ici : les fautes de caches ou "cache misses" en anglais.

Quand un accès mémoire est effectué, le processeur regarde en premier si la donnée est présente en cache de niveau 1. Si elle l'est, c'est tant mieux (il s'agit d'un "cache hit" en L1), l'opération est rapide, sinon, la recherche est faite dans le cache de niveau 2. Là, encore, si la donnée ne s'y trouve pas (on parle de "cache miss" en L2), on y accède en mémoire centrale, ce qui est lent et fait la raison d'être des caches.

Quand l'accès concerne la lecture d'une instruction qui va être exécutée, on touche au cache d'instructions, sinon cela concerne le cache de données. Durant la durée du profilage, Hieronymus va utiliser les événements de "cache miss" sur les caches L1 et L2 pour les instructions et les données, afin d'afficher à la fin le nombre de ces événements :

Report of cache misses :

L1 inst cache misses : 4110166
L2 inst cache misses : 202610
L1 data cache misses : 10298347
L2 data cache misses : 775383

Ces informations sont beaucoup moins pratiques à utiliser que le reste du rapport de profilage mais comme ces informations sont disponibles sur les processeurs PowerPC G3 et G4, pourquoi ne pas en profiter ? Si deux versions d'un programme donnent des résultats très différents alors les modifications effectuées ont un impact visible sur les caches, dont l'utilisation influe directement sur les performances. A noter pour information que le PPC440 est dépourvu de performance monitor ainsi que de cache de niveau 2.

L'inspecteur mène l'enquête

Pour terminer cet article, tout d'abord un mot sur le nom, Hieronymus. En cherchant un nom, j'ai pensé à la fonction de ce logiciel et cela m'a évoqué un inspecteur des programmes. Ça a fait tilt : étant un grand fan des romans policier de Michael Connelly et de son personnage principal, j'ai immédiatement pensé à ce dernier qui n'est autre que Harry Bosch, dont le vrai prénom est Hieronymus. On apprend dans un des livres que sa mère lui a donné ce prénom par attrait pour le tourmenté peintre néerlandais du XVe et XVIe siècle, Hieronymus van Aken, dit Jérôme Bosch.

En cette année 2010, l'inspecteur prend du grade puisque Hieronymus a été intégré dans la mise à jour du SDK d'AmigaOS 4 ! Il se trouve plus exactement dans SDK:Local/C/Hieronymus. L'idée de ce développement m'est venue en utilisant oprofile sur Linux pour le portage et l'optimisation de DOSBox 0.73. Et puis dans mon travail, je m'occupe de tests, de tests de performance et de profilage...

Attention, crash en vue ! Bien que Hieronymus ait été intégré dans le SDK, un bogue dans le système fait planter l'application ou même le système sur Sam et Pegasos. Le bogue a été isolé et remonté aux développeurs de l'OS. Espérons qu'il soit corrigé dans la prochaine mise à jour.

Cet outil devrait être très utile à tous ceux qui programment des applications gourmandes et ont à coeur d'optimiser pour le confort des configurations les plus modestes, comme on le fait depuis 25 ans sur Amiga !


[Retour en haut] / [Retour aux articles]