Profiling - Page 1

Martial Demolins (./1) :
Est-ce qu'un programme fait ça en en surveillant un autre de manière totalement externe ?

Ca peut (Voir http://oprofile.sourceforge.net/news/ ).

Martial Demolins (./1) :
Est-ce que ça nécessite une compilation particulière (par exemple pour exporter les noms de différentes fonctions ?

Si c'est disponible, tu as ses infos, Sinon tu les as pas.

Martial Demolins (./1) :
Est-ce que ça nécessite l'implantation d'un code particulier lors de la compilation (via une lib statique), voire directement dans le code ?

Oui pour l'option -pg de gcc (et donc gprof).
Non pour oprofile ( http://oprofile.sourceforge.net/doc/overview.html#getting-started ).

Ca marche pas du tout sur TI !
Ca peut pas marcher, à moins de hacker tiemu en récupérant les informations de déboggage et de l'implanter à ce niveau.

Valgrind est aussi dans la catégorie de ceux qui surveillent le programme de manière externe, mais ce n'est pas un profileur statistique (un échantillon de temps en temps pour savoir où le programme en est).
Valgrind peut simuler au cycle près, effets des caches et du prefetch compris.
Seul défaut: sa lenteur

en même temps, en debug on s'en fiche de la lenteur

c'est exactement le fonctionnement d'un profiler pc

tu peux faire mieux, tu stockes juste PC dans ton fichier. Après tu fais du post processing sur le pc pour savoir dans quelle fonction c'était, ce sera plus rapide.

Ou utiliser le mode trace et compter les cycles, tout en connaissant les adresses des fonctions pour savoir où on est

si une fct boucle beaucoup, il y a bcp de ticks d'int5 qui mesureront un PC dans cette fonction.
Si tu connais le PC de début du programme, alors les PC DANS le programme seront juste un offset par rapport au début du prog, et en désassemblant ton prog, tu pourras retrouver quel offset correspond à quelle fonction (en supposant que le désassemblage désassemble à partir de l'@ zéro)

alors faudra embarquer les infos de débogage dans le binaire 89z

aucun profiler ne fait ça directement actuellement.

au moins il te faudra un outil de debriefing sur la calcu, qui mélange les infos de débogage de ton binaire et les données récoltées.

et franchement pour la rapidité, si ton AI5 doit faire un lookup de symbole 100 fois par seconde à 12 MHz...

Si tu veux faire un profiler pour programmes TI, le bon endroit est à l'intérieur de TiEmu, pas on-calc.

Cela dit, c'est vrai que les mesures ne seront pas aussi fiables que sur calculatrice réelle. Mais dès que tu rajoutes des interruptions pour mesurer, tu fausses les temps aussi sur la calculatrice réelle.

Et donc la précision d'un émulateur suffit.
Bref, ça devrait être implémenté dans TiEmu, soit dans le cadre de TiEmu lui-même, soit dans GDB.

(squalyl, ./7)

en même temps, en debug on s'en fiche de la lenteur

Quand l'exécution du programme devient plus de deux ordres de grandeur plus lente, tu le sens passer pour toute exécution qui dure plus que quelques secondes en natif

Effectivement. En général, on ne profile pas un programme rapide.

Certes
Mais ça dépend du but visé: si le job du moment consiste à profiler précisément un programme pour voir l'impact de certaines modifs - ça a été le mien pendant deux mois jusqu'à il y a quelques semaines - quand tu fais du profiling, tu testes aussi des exécutions courtes