Dans le cadre d'un gros projet à venir je me pose plusieurs questions:
Est-ce que les compilateurs et les débuggeurs sont liés ?
Faut-il obligatoirement utiliser gdb avec du code compilé par gcc, l'intel debugger avec l'intel compiler,... ?
Qu'est-ce qui existe comme outil permettant de debugger du code parallélisé (openMP ou MPI) ?
Est-ce qu'il existe des benchmarks/articles montrant l'influence de l'OS sur la performance des programmes ? Il s'agirait d'un programme faisant du calcul scientifique sur une grosse machine du type 32 processeurs (ou plus) avec mémoire partagée.
Existe-t'il des meilleurs endroits sur Internet pour poser ce genre de questions que sur linuxfr (le lien avec Linux n'étant pas direct) ?
# pour du C++
Posté par gaaaaaAab . Évalué à 3.
pour apporter mes 2 centimes, ce n'était pas une de tes questions, mais si tu fais du C++, c'est une quasi obligation d'utiliser le même compilateur pour compiler un programme et toutes les librairies C++ dont il dépend. Creuse du côté du mangling si tu veux approfondir la question.
Concernant le lien compilo/debugger, je n'ai pas une vision exhaustive, mais de ce que j'ai pu tester, le debugger est quand même vachement plus content quand il a à faire à du code généré par le compilo de la même suite. (chez nous, gdb a du mal sur code généré par aCC sur HP ou CC sur Solaris 9).
Qu'est-ce qui existe comme outil permettant de debugger du code parallélisé (openMP ou MPI) ?
heu ... un cerveau en parfait état de marche ? ;)
# Exécutables
Posté par peck (site web personnel) . Évalué à 4.
Est-ce que les compilateurs et les débuggeurs sont liés ?
Oui, ils sont développés par les mêmes personnes.
Non, le format d'exécutable (elf sur les unix) permet de faire en sorte que tout le monde marche ensemble (de même que la libc peut être celle qu'on veut ou que le ld marche avec tous les elf). Attention, il faut bien inclure les infos de débuggage (au format dwarf pour info) pour faciliter celui-ci.
Qu'est-ce qui existe comme outil permettant de debugger du code parallélisé (openMP ou MPI) ?
Je n'en connais pas, attention, le code parallélisé est très difficile a debugger.
Est-ce qu'il existe des benchmarks/articles montrant l'influence de l'OS sur la performance des programmes ?
Il ne devrait pas avoir d'influence ... mais avec du parallèle dans tous les sens les perfs peuvent varier du simple au double. Le problème c'est que les performances d'un scheduler peuvent être très spécifique à un algorithme donné. Je ne suis pas sur qu'un benchmark soit pertinent.
[^] # Re: Exécutables
Posté par castorpilot . Évalué à 1.
Il existe des formats de debug differents, utilisés par les compilos et les debuggers.
Par exemple, avec la directive -g, gcc peut generer divers format de debug (dwarf, xcoff, ...)
# debugger
Posté par Bruno Muller . Évalué à 3.
Je ne connais que TotalView (qui marche plutôt pas mal)...
il est possible de télécharger des versions d'éval ici : http://www.totalviewtech.com/download/
# Fortran et compilateur Sun ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
Je m'explique, on avait dans mon ancienne boite une version Fortran et une version réécrite avec plus de fonctionnalités en C++ d'un code de calculs de mécanique quantique. Un jour on a du faire tourner le code sur le Earth Simulator[1], conclusion, le code Fortran a été le plus simple à porter et le plus rapide.
Fortran reste un langage de très bas niveau et très simple, le résultat est que les compilateurs sont capables de faire de remarquables optimisations pour du code parallélisé. Le compilateur Sun pour faire tourner sur de l'infrastructure Sun est vraiment merveilleux (optimisation du nombre d'opération par coeur en fonction de la taille des différentes mémoires caches etc.).
Par ailleurs, utiliser Fortran ne veut pas dire n'utiliser *que* Fortran, tu peux toujours compiler une lib Fortran aux petits oignons et interfacer ça avec du Python pour les entrées sorties.
[1]: http://en.wikipedia.org/wiki/Earth_Simulator
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.