Programmation haute performance

Cette page donne quelques ressources utilisées dans le cours de programmation haute performance donné par Martin Quinson en seconde année (M1) du département d’informatique de l’ENS Rennes.

L’objectif du module est d’entretenir et améliorer votre niveau en programmation C. Il y a finalement assez peu de concepts apportés dans ce module, et beaucoup de pratique. Cela ne veut pas dire qu’il n’y a pas de concepts intéressants en HPC, mais seulement que ce module fait le choix de mettre l’accent sur la pratique.

Tout le poly du cours est regroupé dans un seul fichier. Il s’agit surtout de mes notes de cours que j’utilise à l’oral. C’est probablement plus utile avec la bande son.

• CM Architecture des ordinateurs et performance matérielle. Il s’agit du chapitre 1 du poly.
• TP1 Premiers pas avec les threads (code fourni)
• TP2 Fractale de Julia, threads et répartition de charge (code fourni)
• CM Performance des programmes et communication MPI point à point. Il s’agit des chapitres 2 et 3 du poly. Document: MPI point-à-point.
• TP3 Diffusion de la chaleur et communication point-à-point.
• TP4 Boids et communications collectives (code fourni).

Les TP 2, 3 et 4 sont à rendre, voir ci-dessous.

Matériel supplémentaire

Les TP suivants ne sont listés ici que pour référence. Nous n’avons pas le temps de les faire dans le temps imparti dans ce module. Vous pouvez les regarder si cela vous amuse, mais ils ne seront pas évalués. Je peux tout de même répondre aux questions à leur sujet.

• TDP philosophes: le problème classique des philosophes adeptes de spagettis (code fourni).
• TP Buddhabot: un joli problème nécessitant beaucoup de calcul pour faire de belles images (code fourni).
  Le sujet est rédigé pour vous guider pour mettre en place de la communication inter-processus avec des forks et des sockets, mais on peut l’adapter pour utiliser des threads à la place. Il faut prendre une structure de programme assez proche de celle du calcul de Pi dans le TP1 ci-dessus.

Rendu des TPs

Les TP 2, 3 et 4 sont à rendre. Pour cela, vous devez utiliser le script proj2pdf pour générer un pdf que nous allons lire et annoter. Nous ne compilerons pas vos programmes.

Vous devez absolument rédiger faire un mini rapport dans un fichier nommé README.md. A minima ce fichier contiendra votre nom, et vous ajouterez toutes les infos que vous jugez nécessaire pour expliquer comment vous vous y êtes pris. Si vous avez utilisé une source d’information supplémentaire, vous devez l’indiquer dans le README. À l’inverse des journalistes, les scientifiques se doivent de toujours identifier leurs sources. C’est la base de l’éthique de votre futur métier.

Lancez le script depuis le répertoire contenant votre source et votre fichier README ainsi: ./proj2pdf /tmp/TP1-monnom.pdf. Le fichier produit contient une concaténation de votre rapport et de votre code source. Vous devez envoyer le fichier produit à leo.cosseron@ens et moi pour que nous puissions l’annoter avant de vous le rendre. L’objectif est surtout de vous montrerce qui est bien et ce qui est améliorable dans le code que vous avez écrit, et la note globale au module sera une sorte de moyenne des notes obtenues à chaque TP.

Le script détectera si vous avez oublié de lancer clang-format sur votre code. Ce fait est éventuellement indiqué par un TODO sur la première page générée. Le script utilise également clang-tidy pour tenter de détecter certaines erreurs dans le code. Il est également attendu que vous corrigiez la plupart des erreurs indiquées par cet outil. Il arrive cependant que clang-tidy produise des faux positifs. Dans ce cas, il suffit d’indiquer dans le rapport pourquoi on pense qu’il s’agit d’un faux positif. Si vous ne comprenez pas pourquoi cette erreur est rapportée, indiquez-le aussi dans votre rapport, ce n’est pas forcément grave.

Enfin, le script récupère votre historique git sur la première page. Programmer propre, ça passe aussi par des commits propres avec des messages informatifs, etc. Encore une fois, mon objectif n’est pas de vous enlever des points si vous n’utilisez pas git ou si votre historique git est … améliorable, mais plutôt de vous faire prendre conscience de vos pratiques de programmation et vous permettre de vous améliorer. L’objectif principal de ces tests automatiques reste de vous permettre l’autoévaluation.

Pour finir, je vous invite à lire ce script avant de l’utiliser. Il n’est pas malveillant et ne fait rien de plus que produire le pdf que vous allez vérifier puis nous envoyer, mais lire les scripts qu’on s’apprête à exécuter sur son ordinateur est une règle d’hygiène numérique de base. Si vous avez des remarques doutes ou améliorations sur ce script, parlons-en.

Autres cours

Ce module fait partie d’un ensemble relativement cohérent d’enseignements à l’ENS Rennes:

• SYS1: Programmation C, réseau et introduction aux systèmes informatiques (L3S1).
• GL: Programmation C++ et génie logiciel (L3S2).
• ProgSys: Programmation système: forks, I/O, synchronisations et threads.
• HPC: Programmation haute performance: pratique de MPI (M1S1).

Merci de m’indiquer toute amélioration possible aux documents diffusés: typo, inexactitude, imprecision, etc, sur framagit (vous devez être authentifié sur framagit pour cela).