5.8.8.1 : Pour 1000x34 images
La figure 20 résume les performances obtenues avec 1000 x 34 calcul. Soit 1000 I/O et 34 calculs intermédiaires.
Figure 20 : Performances obtenues avec 1000 x 34 calcul. Soit 1000 I/O et 34 calculs intermédiaires.
Détail des calculs par GPU :
- Sur les A100 :
- Sur les 3G.20GB :
- Sur la V100 :
- Sur la P6000 :
- Sur les T4 :
La première chose que l'on constate sur ces différents tests est que des "accidents" se produisent de temps en temps. Le temps de calcul est subitement multiplier par 30 sans aucune raison.
Avant de se demander ce qu'il se passe, il convient de rappeler quels sont ces temps :
- real : ou temps réel, est le temps total entre le moment où l'on commence l'exécution du programme et le moment où il s'arrête.
- sys : ou temps système, est le temps que le programme passe à faire des appels système. Ce n'est donc pas lui qui est exécuté à ce moment précis, mais comme c'est à sa demande, cela fait partie de son temps d'exécution.
- user : ou temps utilisateur, est le temps d'exécution où le programme n'exécute que son propre binaire (sans faire d'appels système). C'est typiquement le temps de calcul.
Normalement, la somme des temps user et sys doit donner le temps real. Si ce n'est pas le cas, c'est qu'il y a des latences, généralement dues à des I/O.
Si l'on regarde attentivement nos résultats, nous constatons que seule le temps real noteDonc la courbe violette a des râtés. Cela est bien normal, car aucun programme n'est sensé pouvoir s'exécuter sur le GPU en même temps que le notre noteEn tout cas, c'est ce que garanti htcondor quand il est bien paramétré..
C'est donc un problème d'I/O, en l'occurence de temps en écriture pour nous, car nous écrivons 8.3 Go mais nous ne lisons aucun fichier. Le problème des centres de calcul, c'est que les autres jobs qui s'exécutent sur la même machine que notre programme peuvent faire litéralement n'importe quoi noteEn même temps, ils sont programmés pas des physiciens :). Donc, si un programme fait beaucoup de lectures ou d'écitures (de données, de configurations, voire d'environnements anaconda noteQui sont une torture pour n'importe quel système de fichiers distribués.) en même temps que le notre doit écrire ses données, ça le ralenti considérablement noteD'autant plus que notre programme a le mérite d'être bien optimisé..
Dans la suite, nous allons augmenter le nombre de calcul et diminuer la quantité de données à sauvegarder pour tester notre hypothèse :
- 2000 fois plus de calcul et 200 fois moins d'I/O pour la section 5.8.8.2
- 20000 fois plus de calcul et 200 fois moins d'I/O pour la section 5.8.8.3