1.1.3 : Objectifs



Nous espérons que ce document vous aidera à savoir plus souvent ce que vous faites quand vous étudiez la performance d'un logiciel, ce qui vous permettra d'optimiser votre code davantage et plus efficacement et vous aidera à mieux diagnostiquer quelques erreurs classiques comme par exemple oublier d'activer les optimisations du compilateur lors de la compilation d'un programme ou lancer trop de tâches parallèles par rapport aux capacités de la machine.

De cette façon, vous utiliserez mieux le matériel informatique à votre disposition, éviterez des achats superflus, et dans le cas des personnels chercheurs vous passerez moins de temps à vous bagarrer avec vos programmes et attendre leur exécution et plus de temps à faire de la science.

Nous rêvons que la discussion autour des performances logicielles, qui actuellement ressemble trop souvent à ceci...

  • Chercheur : Il va me falloir un noeud de calcul plus perfectionné, les calculs sont trop lents. Je peux fournir le financement.
  • Ingénieur : Juste par curiosité, j'aimerais bien jeter un oeil à ce qui se passe...
  • (Deux semaines passent, le temps que l'ingénieur parvienne à reproduire l'environnement logiciel du chercheur, qui s'impatiente, et à faire ses analyses tout en répondant à trois autres requêtes du même style en parallèle. Puis l'ingénieur revient.)
  • Chercheur : Alors, ce fameux "coup d'oeil" ? Ca t'en a pris du temps !
  • Ingénieur : Eh bien en fait, le calcul est lent pour plusieurs raisons...
    • Tu débordes les capacités mémoire de la machine en créant trop de tâches, ce qui cause un débordement sur le disque, bien plus lent que la mémoire vive. Tu crées trop de tâches parce que tu utilises à la fois MPI et OpenMP sur une machine unique, donc tu pensais créer une tâche par coeur mais tu en crées 60.
    • Le programme fait des sorties disques dont tu n'as pas besoin, et se retrouve ainsi limité par la bande passante disque plus que par le calcul.
    • Après avoir réglé ça, la performance devient limitée par le calcul parce qu'une des bibliothèques utilisées n'a pas été compilée avec les optimisations de compilateur activées.
    • Une fois la bibliothèque recompilée, le programme redevient limité par sa capacité à lire les données d'entrée et écrire les données de sortie sur le disque... mais il est déjà 300x plus rapide qu'avant, donc ce qui prenait une semaine de calcul prend maintenant une demi-heure.
  • Chercheur : Whoa, c'est impressionnant. Du coup, je vais pouvoir utiliser mes sous pour embaucher un post-doc de plus, parce qu'à cette vitesse-là c'est l'analyse scientifique qui va devenir le facteur limitant !


...puisse un jour ressembler plutôt à cela :

  • Chercheur : J'ai un programme de traitement d'images astronomiques qui prend un peu trop de temps à mon goût. Il est limité par la performance CPU, et en profilant j'ai vu que l'essentiel du temps est passé à calculer des corrélations avec une métrique un peu exotique entre images successives. Comme on n'utilise actuellement qu'un seul coeur CPU, je me dis qu'il y a moyen de gagner en parallélisant, mais je ne peux pas juste lancer un job par coeur CPU parce que la mémoire disponible est insuffisante, et je n'ai pas assez d'expérience en multi-threading pour tester ce type de parallélisation moi-même.
  • Ingénieur : A quoi ressemble un jeu de données d'entrée typique ?
  • Chercheur : On traite typiquement les images par lots de 60. Les images sont enregistrées avec des filtres de 6 couleurs différentes, pour chaque couleur on a 10 images successives, et au stade des corrélations qui limite les performances on traite chaque longueur d'onde de façon indépendante.
  • Ingénieur : Très bien, donc en parallélisant on peut facilement occuper 6 coeurs du cluster par job, à empreinte mémoire équivalente à celle du job original. Ca suffit par rapport à la pression que tu as observée sur la mémoire ?
  • Chercheur : Oui, avec 10 jobs utilisant 6 coeurs on devrait pouvoir utiliser tous les 60 coeurs du cluster sans tomber à court de mémoire.
  • Ingénieur : Très bien, si le code est structuré comme il faut pour le parallélisme je devrais pouvoir te faire ça dans la semaine. Autre chose dont tu veux discuter aujourd'hui ?
  • Chercheur : Oui, il y a un centre de calcul avec lequel je travaille qui vient d'acheter des gros GPUs et j'ai entendu dire que c'était très efficace pour le traitement d'images. Est-ce qu'on peut exploiter ce nouveau matériel tout en restant compatible avec les infrastructures de calcul qui n'ont que des CPUs ?
  • Ingénieur : Alors ça, ça va me prendre un peu plus de temps car on touche à des sujets de R&D actifs, mais justement j'ai moins de demandes de chercheurs ces derniers temps donc je vais peut-être pouvoir tester des technos qui font ça sur ton code dans le mois qui vient...