Content de savoir que vous avez testé l'outil, votre code est-il open source ? Si vous avez des problèmes et que ce n'est pas trop compilé à faire tourner je peux jeter un oeil.
Si les fonctions d'allocation sont toutes à l'initialisation c'est parfait, c'est ce qu'il faut idéalement, donc éviter d'en avoir (sauf impossibilité ou en tout cas de manière raisonné) tout au long au milieu des calculs. Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size) nuisant aux caches ou vérifier que l'application ne fragmente pas si une partie des allocations sont libérées (requested_memory décroissante alors que la mémoire virtuelle ne suis pas cette tendance dans les graphiques temporels).
Oui je suppose qu'il y a quelques limitations pour la détection des lignes avec -O3 si le compilo est trop agressif et notamment si vous faite du LTO qui je suppose perd la plupart des outils de debug (j'utilise l'outil addr2line pour faire la correspondance). Mais cela ne doit pas non plus trop souvent changer les résultats. Un run en O0/O1 devrait donner des résultats plus précis sans fausser tant que ça les résultats (biais uniquement sur les durées de vie des blocs, mais pas pour les autres métriques : tailles.....). De toute façon MALT a un overhead non nul donc les résultats temporels sont de toute façon entachés d'une erreur, je pense qu'il est bon de recommencer de tourner en O0/O1 sans LTO pour profiler avec MALT.
Concernant votre problème de source d'allocation sur une ligne qui je le suppose fait du calcul. Ne serait-ce pas une ligne utilisant des allocatable array ? J'ai constaté (avec surprise) en développant l'outil que Gfortran peut générer par lui même des allocations dans ce cas. Le compilo Intel (ifort) lui ne le fait qu'au-delà d'un seuil configurable (par défaut infini). Cela est décrit dans les docs des deux compilo, si cela vous intéresse je peux essayer de retrouver les liens.
[^] # Re: J’ai testé MALT
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 5.
Content de savoir que vous avez testé l'outil, votre code est-il open source ? Si vous avez des problèmes et que ce n'est pas trop compilé à faire tourner je peux jeter un oeil.
Si les fonctions d'allocation sont toutes à l'initialisation c'est parfait, c'est ce qu'il faut idéalement, donc éviter d'en avoir (sauf impossibilité ou en tout cas de manière raisonné) tout au long au milieu des calculs. Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size) nuisant aux caches ou vérifier que l'application ne fragmente pas si une partie des allocations sont libérées (requested_memory décroissante alors que la mémoire virtuelle ne suis pas cette tendance dans les graphiques temporels).
Oui je suppose qu'il y a quelques limitations pour la détection des lignes avec -O3 si le compilo est trop agressif et notamment si vous faite du LTO qui je suppose perd la plupart des outils de debug (j'utilise l'outil addr2line pour faire la correspondance). Mais cela ne doit pas non plus trop souvent changer les résultats. Un run en O0/O1 devrait donner des résultats plus précis sans fausser tant que ça les résultats (biais uniquement sur les durées de vie des blocs, mais pas pour les autres métriques : tailles.....). De toute façon MALT a un overhead non nul donc les résultats temporels sont de toute façon entachés d'une erreur, je pense qu'il est bon de recommencer de tourner en O0/O1 sans LTO pour profiler avec MALT.
Concernant votre problème de source d'allocation sur une ligne qui je le suppose fait du calcul. Ne serait-ce pas une ligne utilisant des allocatable array ? J'ai constaté (avec surprise) en développant l'outil que Gfortran peut générer par lui même des allocations dans ce cas. Le compilo Intel (ifort) lui ne le fait qu'au-delà d'un seuil configurable (par défaut infini). Cela est décrit dans les docs des deux compilo, si cela vous intéresse je peux essayer de retrouver les liens.
The force is in doing, not trying.