C'est bien sympa que gcc soit a la pointe avec openmp, mais si c'est impossible a utiliser car impossible a debugger, ca sert a rien... :/
En même temps, à ma connaissance, le compilo d'Intel ne fait pas mieux, et idem pour la plupart des concurrents Quelque part j'ai envie de dire « C'est bien beau de fournir un env. de debugging pour OpenMP 2.0, mais on n'est plus en 2004. » :-P
De plus, les gens qui bossent sur des applis avec plusieurs centaines ou milliers de threads OpenMP n'utilisent pas de debuggers parce que trop compliqué (à moins de te faire pousser quelques dizaines d'yeux, comment tu fais pour surveiller les cas chiants du type data race ?). Du coup la plupart des gens qui bossent sur des applis massivement multithreadées passent par des trucs du genre omp barrier ou omp taskwait + printf. En règle générale, dans le monde du HPC, il y a peu voire pas de vraie solution de debug pour le parallélisme massif. Et la réponse des gens à ce problème est en gros « utilise un langage qui limite les possibilités de data race, genre DSL, langages fonctionnels, ou quasi-fonctionnels (i.e. multi-paradigmes) ».
Pour ce genre d'applications (HPC), le debugger « idéal » serait sans doute un truc qui permet d'enregistrer une trace sur N cycles ou secondes, puis qui permette de « rejouer » la séquence et d'analyser les valeurs. Le problème est la taille de la trace résultante, et surtout les heisenbugs : même comme ça tu risques d'avoir des soucis pour trouver le bug en question.
Note que j'aime beaucoup le debugger de MSVC++, juste que le manque de fonctionnalités du compilo en fait quelque chose de pas très intéressant pour faire du dév OpenMP un peu poussé (il y a tout un tas d'applis de simulation numériques qui tirent fortement partie des tasks OpenMP pour la traversées de structures de graphe ou tableaux « creux »).
[^] # Re: smart pointer
Posté par lasher . En réponse au journal Retour aux sources. Évalué à 3.
En même temps, à ma connaissance, le compilo d'Intel ne fait pas mieux, et idem pour la plupart des concurrents Quelque part j'ai envie de dire « C'est bien beau de fournir un env. de debugging pour OpenMP 2.0, mais on n'est plus en 2004. » :-P
De plus, les gens qui bossent sur des applis avec plusieurs centaines ou milliers de threads OpenMP n'utilisent pas de debuggers parce que trop compliqué (à moins de te faire pousser quelques dizaines d'yeux, comment tu fais pour surveiller les cas chiants du type data race ?). Du coup la plupart des gens qui bossent sur des applis massivement multithreadées passent par des trucs du genre
omp barrierouomp taskwait+printf. En règle générale, dans le monde du HPC, il y a peu voire pas de vraie solution de debug pour le parallélisme massif. Et la réponse des gens à ce problème est en gros « utilise un langage qui limite les possibilités de data race, genre DSL, langages fonctionnels, ou quasi-fonctionnels (i.e. multi-paradigmes) ».Pour ce genre d'applications (HPC), le debugger « idéal » serait sans doute un truc qui permet d'enregistrer une trace sur N cycles ou secondes, puis qui permette de « rejouer » la séquence et d'analyser les valeurs. Le problème est la taille de la trace résultante, et surtout les heisenbugs : même comme ça tu risques d'avoir des soucis pour trouver le bug en question.
Note que j'aime beaucoup le debugger de MSVC++, juste que le manque de fonctionnalités du compilo en fait quelque chose de pas très intéressant pour faire du dév OpenMP un peu poussé (il y a tout un tas d'applis de simulation numériques qui tirent fortement partie des
tasksOpenMP pour la traversées de structures de graphe ou tableaux « creux »).