Quel logiciel est bon à utiliser pour le débogage parallèle?

24

Je n'exécute aucun code parallèle pour le moment, mais je prévois d'exécuter du code parallèle à l'avenir en utilisant un hybride d'OpenMP et de MPI. Les débogueurs ont été des outils précieux pour moi lors de l'exécution de projets en série.

Quelqu'un peut-il recommander un débogueur parallèle (ou plusieurs débogueurs) à utiliser pour déboguer un logiciel parallèle? Un logiciel libre serait préférable, mais n'hésitez pas à mentionner un logiciel commercial efficace.

software parallel-computing

— Geoff Oxberry
source

Je ne vois pas en quoi les réponses ici différeront considérablement de stackoverflow.com/questions/329259/… . MPI est la partie difficile ici, pas OpenMP. Dans tous les cas, le débogage des conditions de concurrence critique dans les programmes filetés est insoluble à l'heure actuelle.

— Jeff

ThreadSanitizer est une bonne solution pour déboguer les conditions de concurrence dans les programmes threadés, bien que je ne connaisse personne qui ait essayé d'ajouter MPI au mix!

— mabraham

17

Il existe essentiellement deux choix commerciaux majeurs: le DDT d'Allinea (qui est ce que nous utilisons au TACC ) et Totalview (comme mentionné dans l'autre commentaire). Ils ont des caractéristiques comparables, sont tous deux activement développés et sont des concurrents directs.

Eclipse a sa plate - forme d'outils parallèles , qui devrait inclure le support de programmation MPI et OpenMP et un débogueur parallèle.

— Bill Barth
source

Je n'ai jamais entendu parler de quelqu'un utilisant le débogueur parallèle PTP. Je ne sais pas ce que cela signifie ...

— Jeff

J'ai quelques collègues qui ont essayé, mais je n'ai jamais joué avec.

— Bill Barth

16

Je dois répondre au curmudgeon. Ma productivité n'a jamais été améliorée par l'une des suggestions ci-dessus. Ils sont lents et coûteux par rapport à mon option préférée en parallèle: une session gdb par processus. Chaque gdb peut se connecter à un processus MPI et s'asseoir dans un xterm (cela se produit automatiquement dans PETSc en utilisant -start_in_debugger). Je l'utilise depuis 15 ans, heureusement. Objections:

1) Je ne peux pas regarder les données globales

Puisque MPI est un modèle à partage nul, il n'y a pas de données globales, seulement des données locales

2) Cette stratégie ne s'adapte pas à de nombreux processus

Les bogues non plus. Des bugs se produisent sur des processus individuels, peut-être avec l'entrée de 1 ou 2 voisins. Vous pouvez facilement générer gdb uniquement sur les processus participants (dans PETSc que vous utilisez -debugger_nodes 0,5,17par exemple). En outre, les systèmes ci-dessus abandonnent beaucoup lors de l'exécution de chaque processus, ce qui les ralentit. La méthode gdb est, en fait, beaucoup plus évolutive.

gdb est également très portable. Il s'exécute partout, comprend C ++ et Fortran et vous permet d'exécuter du code arbitraire à l'intérieur de l'exécution. J'ai écrit des fonctions spéciales pour afficher facilement les données lors de leur exécution.

— Matt Knepley
source

4

Hé lâche, si vous dévaluez, laissez un commentaire.

— Matt Knepley

5

Je n'étais pas à la baisse, mais je ne suis pas d'accord dans une certaine mesure. J'ai rencontré quelques bogues à l'échelle qui ne s'affichaient pas à petite taille, et l'utilisation d'un débogueur parallèle était un moyen efficace de les trouver. Je fais la plupart de mon débogage avec printf et l'attachement à des processus individuels avec gdb, mais j'ai vu l'avantage d'avoir un débogueur parallèle.

— Bill Barth

3

La seule fois où j'ai rencontré un bogue à grande échelle était un bogue de performance dû à un mauvais algorithme de communication collective choisi. Là encore, ma vue est encore plus extrême que celle de Matt, car la chose la plus proche d'un débogueur que j'utilise jamais est valgrind.

— Jack Poulson

1

@BillBarth Je sais que vous avez raison de dire qu'il existe des bogues sur 1000 proces qui ne se présentent pas sur des problèmes plus petits (Dinesh en avait un célèbre PETSc qui a duré des mois et qui n'est apparu que sur 82 procs). Mon propos était davantage de contrer la sagesse qui prévalait. Je pense que les débogueurs parallèles sont un bon dernier recours, pas un premier recours.

— Matt Knepley

3

Je t'ai rétrogradé. Votre réponse pas ce qui a été demandé.

— aterrel

5

J'utilise seulement deux débogueurs pour les programmes série et parallèle:

Le débogueur Kernighan, c'est-à-dire des déclarations imprimées judicieuses et une réflexion approfondie.
Plusieurs instances de GDB comme décrit sur http://www.open-mpi.org/faq/?category=debugging#serial-debuggers .

Dans le cas où (2) n'est pas suffisamment évolutif, je me réfère à (1b).

— Jeff
source

1

Je n'ai jamais entendu le nom de "débogueur Kernighan", mais j'approuve, car c'est comme ça que je débogue toujours.

— Jack Poulson

4

Il y a Intel Parallel Studio qui inclut un débogueur parallèle. Je ne l'ai jamais travaillé mais je l'ai vu utilisé dans quelques démos. Voici un didacticiel vidéo qui montre certaines des fonctionnalités.

J'ai également vu quelques wrappers autour de gdb qui fonctionnaient assez bien dans certains cas.

— ank
source

3

Totalview . C'est un débogueur commercial. Il est très facile de visualiser la pile sur chaque processeur. Vous pouvez voir les valeurs variables (et les modifier) à travers les processeurs / threads. Vous pouvez tracer des vecteurs ou des matraques pour visualiser les valeurs des variables. Apparemment, les scripts sont également possibles (Tk / Tcl), pour une analyse sophistiquée des points d'observation, bien que je n'ai jamais travaillé avec cela moi-même.

— Yann
source

Sur le plan subjectif, lorsque le centre HPC de mon université a installé cela, je pensais que c'était excessif. Ensuite, j'ai découvert à quel point il était facile de faire un débogage très compliqué. C'est vraiment un excellent programme.

— Yann

Je seconde également TotalView. Je l'ai utilisé dans de nombreux cas et il est extrêmement puissant, bien que très cher ...

— BlaB

1

Pour quelques façons simples de déboguer des codes parallèles, nous avons collecté quelques réponses dans la FAQ deal.II dans la section sur le débogage: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#debugging -dealii-applications

— Wolfgang Bangerth
source

1

Je me demande pourquoi personne n'a mentionné Padb (Parallel Application Debugger) qui est un logiciel libre et open source comme l'OP le préfère, mais pas aussi puissant que ses homologues commerciaux par exemple: TotalView pour HPC

— Hefnawi
source

-1

Voici un résumé de quelques réponses qui m'ont été données précédemment:

OpenMP a des fonctions de chronométrage: omp_get_wtime()et omp_get_wtick()- documents en ligne

Google a un profileur CPU

Il y a Scalasca qui fait le profil et l'analyse OpenMP et MPI

Ensuite, il y a Tau et vtune que je n'ai pas utilisés.

Bonne chance!

— Mikhail
source

Je ne pense pas que la question porte sur le calendrier, mais je me trompe peut-être. Bonnes suggestions cependant ...

— Yann

Cette réponse concerne plus le profilage que le débogage ...

— mbq

J'ai trouvé que les outils de profilage sont de bons substituts aux débogueurs parallèles. Je trouve souvent que les bogues parallèles sont liés à des problèmes de performances, tels que logjam dans MPI. Les outils de performance le révèlent souvent. Le profileur de mémoire de TAU est bon pour comprendre pourquoi des erreurs de segmentation aléatoires peuvent se produire.

— Jeff