SUPERZAP, SystemTap, etc. sont tous des outils très intéressants. Ayant indirectement bossé sur MAQAO et directement avec (quand la plupart de ses modules étaient éclatés en divers endroits), j'ai eu l'occasion parler avec la plupart des gens qui y ont bossé entre ~2005 et ~2010. Pour prendre l'exemple du module MADRAS (qui s'occuper de « décompiler » les binaires, rajouter des trampolines où il faut, puis recompiler le tout), son auteur avait cherché un peu partout s'il n'existait pas déjà des bibliothèques ou exécutables qui feraient l'affaire. La réponse a été non : soit on avait des trucs de type objdump/gdb/etc. fait pour le debug, soit on avait des trucs type IDA Pro pour le reverse engineering, mais ce que cherchait l'auteur de MADRAS, c'était un moyen de facilement patcher des bouts de binaires sans avoir à se taper l'intégralité de l'assembleur, pour mieux instrumenter les parties chaudes qui devront être plus tard optimisées. Bref, tout plein d'outils faisaient « presque » l'affaire, mais pas vraiment ce qu'il voulait. De plus, l'idée était déjà à l'époque d'unifier dans un même framework tous les outils utilisés pour analyser/mesurer la performance de codes de calcul intensif.
Le « front-end » de MAQAO (Sylvain ne te gène pas pour me contredire si ça a changé et que je dis des bêtises) est censé bouffer de l'assembleur (ou du binaire décompilé) de la partie chaude de l'exécutable, puis à l'aide d'un modèle machine codé en interne (obtenu à grands coups de micro-benchmarking pour savoir quel est l'effet réel d'instructions SIMD/SSE, en fonction du flux, de l'occupation des ports de décodage du front-end pour processeurs Intel1, etc. Cette information est statique (MAQAO recrée le graphe de dépendances de données ainsi que le graphe de flot de contrôle à partir de l'asm). Du coup, on obtient des informations « optimistes » de la meilleure performance possible. Par exemple, même si le code n'est pas vectorisé, si MAQAO déduit que statiquement il y a bien trop de chargements mémoire comparé aux instructions arithmétiques, il le rapportera dans son diagnostic.
Ensuite, si la performance mesurée s'écarte grandement de ce qu'on promet « au mieux », on peut utiliser différentes techniques, comme l'analyse décrémentale (DECAN), qui consiste à patcher le binaire de la boucle chaude, et retirer petit à petit des instructions (en suivant un pattern précis, ou bien « aléatoirement », etc.). L'idée est de repérer quel est le « deliquent load/store » (la lecture ou écriture mémoire qui rend le code lent). On retire une ou plusieurs instructions, on réinstrumente la portion de code, et on itère.
Il y a tout plein d'autres trucs que MAQAO sait faire, mais il faut garder à l'esprit que les codes visés sont généralement assez réguliers en terme de flot de contrôle. Si le code passe sont temps dans des constructions de type if-else, MAQAO ne pourra sans doute rien pour aider le programmeur.
[1] Je ne sais pas comment c'est obtenu maintenant, mais à l'époque, c'était l'affaire de quelques minutes/heures, à faire tourner tout plein de micro-benchmarks avec à peu près toutes les instructions « utiles » en calcul haute performance imaginables, et vérifier que les latences et le débit étaient ceux promis par Intel. On se servait pas mal des manuels de Agner pour vérifier que nous avions les mêmes nombres — et je dirais que 90-95% du temps, c'était le cas.
[^] # Re: Quelques tools !
Posté par lasher . En réponse au journal Disséquer du binaire - retour d'expérience. Évalué à 4.
Histoire de répondre en vrac :
SUPERZAP, SystemTap, etc. sont tous des outils très intéressants. Ayant indirectement bossé sur MAQAO et directement avec (quand la plupart de ses modules étaient éclatés en divers endroits), j'ai eu l'occasion parler avec la plupart des gens qui y ont bossé entre ~2005 et ~2010. Pour prendre l'exemple du module MADRAS (qui s'occuper de « décompiler » les binaires, rajouter des trampolines où il faut, puis recompiler le tout), son auteur avait cherché un peu partout s'il n'existait pas déjà des bibliothèques ou exécutables qui feraient l'affaire. La réponse a été non : soit on avait des trucs de type
objdump/gdb/etc. fait pour le debug, soit on avait des trucs typeIDA Propour le reverse engineering, mais ce que cherchait l'auteur de MADRAS, c'était un moyen de facilement patcher des bouts de binaires sans avoir à se taper l'intégralité de l'assembleur, pour mieux instrumenter les parties chaudes qui devront être plus tard optimisées. Bref, tout plein d'outils faisaient « presque » l'affaire, mais pas vraiment ce qu'il voulait. De plus, l'idée était déjà à l'époque d'unifier dans un même framework tous les outils utilisés pour analyser/mesurer la performance de codes de calcul intensif.Le « front-end » de MAQAO (Sylvain ne te gène pas pour me contredire si ça a changé et que je dis des bêtises) est censé bouffer de l'assembleur (ou du binaire décompilé) de la partie chaude de l'exécutable, puis à l'aide d'un modèle machine codé en interne (obtenu à grands coups de micro-benchmarking pour savoir quel est l'effet réel d'instructions SIMD/SSE, en fonction du flux, de l'occupation des ports de décodage du front-end pour processeurs Intel1, etc. Cette information est statique (MAQAO recrée le graphe de dépendances de données ainsi que le graphe de flot de contrôle à partir de l'asm). Du coup, on obtient des informations « optimistes » de la meilleure performance possible. Par exemple, même si le code n'est pas vectorisé, si MAQAO déduit que statiquement il y a bien trop de chargements mémoire comparé aux instructions arithmétiques, il le rapportera dans son diagnostic.
Ensuite, si la performance mesurée s'écarte grandement de ce qu'on promet « au mieux », on peut utiliser différentes techniques, comme l'analyse décrémentale (DECAN), qui consiste à patcher le binaire de la boucle chaude, et retirer petit à petit des instructions (en suivant un pattern précis, ou bien « aléatoirement », etc.). L'idée est de repérer quel est le « deliquent load/store » (la lecture ou écriture mémoire qui rend le code lent). On retire une ou plusieurs instructions, on réinstrumente la portion de code, et on itère.
Il y a tout plein d'autres trucs que MAQAO sait faire, mais il faut garder à l'esprit que les codes visés sont généralement assez réguliers en terme de flot de contrôle. Si le code passe sont temps dans des constructions de type
if-else, MAQAO ne pourra sans doute rien pour aider le programmeur.[1] Je ne sais pas comment c'est obtenu maintenant, mais à l'époque, c'était l'affaire de quelques minutes/heures, à faire tourner tout plein de micro-benchmarks avec à peu près toutes les instructions « utiles » en calcul haute performance imaginables, et vérifier que les latences et le débit étaient ceux promis par Intel. On se servait pas mal des manuels de Agner pour vérifier que nous avions les mêmes nombres — et je dirais que 90-95% du temps, c'était le cas.