11.4.4.5 : Profilage
La situation de l'analyse de performances des applications parallèles n'est guère plus reluisante que celle du débogage.
L'écriture et l'analyse de benchmarks parallèles est d'abord compliquée par une dépendance beaucoup plus grande vis-à-vis de l'activité de fond de la machine hôte qu'avec du code séquentiel. Même en dépensant une grande énergie à réduire cette activité, les temps d'exécution fluctuent beaucoup plus en parallèle, et il est donc plus difficile de juger de la pertinence d'une optimisation.
L'analyse des points chauds par un profileur est aussi plus complexe. Certains profileurs anciens, tels que gprof, sont incapables de mesurer un profil de l'exécution d'un code à plusieurs threads. D'autres, comme callgrind, simulent l'exécution parallèle de façon séquentielle selon des hypothèses très discutables, et ne sont donc pas non plus à même de fournir une description réaliste de l'exécution parallèle d'un code sur un jeu de données proche des conditions de production. Seuls les profileurs basés sur une instrumentation matérielle assistée par le système d'exploitation, comme perf, parviennent à fournir une mesure raisonnablement fiable du profil d'exécution d'un programme parallèle.
En calcul distribué, la situation est encore plus désespérée. Les profileurs capables d'analyser précisément l'exécution d'un calcul distribué, qui sont conçus par les mêmes équipes auxquelles ont doit des débogueurs distribués, sont globalement sujets aux mêmes contraintes de faible portabilité et forte dépendance envers MPI. De plus, les volumes de données générés par ces mesures sont aussi gigantesques, ce qui complique leur analyse.
Parfois, on doit donc s'en remettre à la solution de contournement d'utiliser comme outil de profilage primitif le système de monitoring système du centre de calcul, qui décrit l'évolution temporelle de l'utilisation des différentes ressources matérielles et peut aider à dégrossir l'analyse des goulots d'étranglement. Mais ces outils restent à gros grain, tant spatialement (ils n'indiquent pas précisément la source du problème dans le code) que temporellement (les mesures ne sont pas fréquentes), et leur sortie n'est donc exploitable qu'en la complétant par un processus d'instrumentation manuelle du code particulièrement laborieux.