OpenMP debug newbie questions

Question

Je commence à apprendre OpenMP, exécutant des exemples (avec gcc 4.3) de https://computing.llnl.gov/tutorials/openMP/exercise.html dans un cluster. Tous les exemples fonctionnent bien, mais j'ai quelques questions:

1. Comment savoir dans quels nœuds (ou noyaux de chaque nœud) les différents threads ont-ils été "exécutés"?
2. Cas des nœuds, quel est le temps de transfert moyen en microsecs ou nanosecs pour envoyer l'information et la récupérer?
3. Quels sont les meilleurs outils pour déboguer des programmes OpenMP?
4. Meilleurs conseils pour accélérer les vrais programmes?

Answer 1

1. Généralement votre programme OpenMP ne sait pas, ni ne se soucie, sur lequel il est en cours d'exécution noyaux. Si vous avez un système de gestion des tâches qui peut fournir les informations que vous voulez dans ses fichiers journaux. A défaut, vous pourriez probablement insérer des appels à l'environnement dans vos threads et vérifier la valeur de certaines variables d'environnement. Qu'est-ce que cela s'appelle et comment vous faites cela dépend de la plate-forme, je vais vous laisser le choix.

2. Comment diable devrais-je (ou tout autre SOer) savoir? Pour une estimation éclairée, vous devrez nous en dire beaucoup plus sur votre matériel, o/s, système d'exécution, etc, etc., etc. La meilleure réponse à la question est celle que vous déterminez à partir de vos propres mesures. Je crains que vous puissiez vous tromper en pensant que les informations sont envoyées autour de l'ordinateur - dans les variables de programmation à mémoire partagée restent généralement dans un endroit (ou du moins vous devriez penser à les garder à un endroit, la réalité peut être beaucoup plus mais aussi impossible à discerner) et n'est pas envoyé ou reçu. Les débogueurs parallèles tels que TotalView ou DDT sont probablement les meilleurs outils. Je n'ai pas encore utilisé les capacités parallèles du débogueur d'Intel, mais elles semblent prometteuses. Je laisserai aux programmeurs moins bien financés que moi le soin de recommander des options de logiciels libres, mais ils sont là. I12) Sélectionnez l'algorithme parallèle le plus rapide pour votre problème. Ce n'est pas nécessairement l'algorithme de série le plus rapide rendu parallèle.

   ii) Test et mesure. Vous ne pouvez pas optimiser sans données, vous devez donc profiler le programme et comprendre où se situent les goulots d'étranglement. Ne croyez pas à un conseil selon lequel «X est plus rapide que Y». De telles déclarations sont généralement basées sur des cas très étroits et souvent dépassés et sont devenues, dans l'esprit de leurs promoteurs, des «vérités». Il est presque toujours possible de trouver des contre-exemples. C'est VOTRE code que vous voulez faire plus rapidement, il n'y a pas de substitut à vos enquêtes. Iii) Connaissez votre compilateur à l'envers. Le taux de rendement (mesuré en améliorations de la vitesse du code) sur le temps que vous avez passé à ajuster les options de compilation est beaucoup plus élevé que le taux de rendement de la modification du code «à la main». Iv) Une des «vérités» à laquelle je m'attache est que les compilateurs ne sont pas très bons pour optimiser l'utilisation de la hiérarchie de la mémoire sur les architectures de processeurs actuelles. C'est un domaine où la modification de code peut être utile, mais vous ne le saurez pas tant que vous n'aurez pas profilé votre code.

Answer 2

1. Vous ne pouvez pas savoir, la partition de threads sur différents noyaux est entièrement prises en charge par le système d'exploitation.Vous parlez de nœuds, mais OpenMP est une parallélisation multi-thread (et non multi-process) qui permet la parallélisation pour une machine contenant plusieurs cœurs. Si vous avez besoin d'une parallélisation sur différentes machines, vous devez utiliser un système multiprocessus comme OpenMPI.

2. L'ordre de grandeur des temps de communication sont:
   

   • énorme en cas de communications entre les noyaux à l'intérieur de la même CPU, il peut être considéré comme instantanée
   • ~ 10 Go/s pour les communications entre deux CPU sur une carte mère
   • ~ 100-1000 MB/s pour les communications réseau entre les nœuds, en fonction du matériel

   Toutes les vitesses théoriques doivent être spécifiées dans vos spécifications matérielles. Vous devriez également faire des petits repères pour savoir ce que vous aurez vraiment.

3. Pour OpenMP, gdb faire le travail bien, même avec de nombreux threads.

4. Je travaille dans la simulation extrême de la physique sur supercalculateur, voici nos objectifs quotidiens:
   • utilisation comme moins de communication possible entre les fils/processus, 99% du temps, il est des communications qui tuent des performances dans des emplois parallèles
   • répartir les tâches de façon optimale, la charge de la machine doit être aussi proche que possible de 100% tout le temps
   • tester, régler, re-tester, re-régler .... La parallélisation n'est pas du tout une «solution miracle» générique, elle nécessite généralement un travail pratique pour être efficace.