La pratique est différente de la théorie, en grande partie du fait que les outils de développement gèrent souvent beaucoup mieux le C que le Fortran ; le Fortran 95 est une solution élégante sur le papier, mais beaucoup de détails posent problème.
Lorsque l'écriture du prototype de Code_Saturne a démarré en 1997, les développeurs de l'époque ont choisi le Fortran 77, qu'ils maîtrisaient déjà. Les compilateurs F90 ou F95 étaient encore récents, et pour avoir essayé en 1997 les compilateurs et runtimes Nag ou HP (sur machines HP-UX à l'époque), c'était très décevant, avec à minima des bugs critiques dans les libariaires d'I/O associées.
Dans ces conditions, difficile de convaincre les "anciens" qui préféraient le Fortran 77 que le Fortran 95 était une bonne option. De plus, il n'y avait à l'époque pas de compilateur Fortran 90 ou 95 libre, ce qui était problématique dans la mesure ou l'on souhaitait garder un code portable et déployable facilement, y compris dans des labos externes, sans imposer l'achat d'un compilateur F90.
Pour les opérations associées au pré et post-traitement de maillages (concaténation, recollements de maillages non conformes, ...) il était indispensable de disposer au moins de structures et de mémoire dynamique, et le C faisait très bien l'affaire. Le C a donc progressivement fait son entrée dans le code via les aspects entrées/sorties, et le code C utilisé dans Code_Saturne utilise des notions de constructeur et destructeur (appelés explicitement), et de méthodes (mais pas d'héritage, pas vraiment nécessaire dans ce contexte).
A noter que le C a du faire ses preuves en étant au début mis en oeuvre dans des parties "non critiques" du code, les anciens développeurs s'en méfiant. En fait, en utilisant quelques règles simples (allocations mémoires encapsuleés et instrumentées, pour détecter facilement les fuites mémoire, utilsation fréquente, d'Electric Fence puis Valgrind, C89 avec prototypes évidamment, ...), nous n'avons jamais eu de problèmes liés à l'utilisation du C. Les pointeurs ne constituent pas une si grosse difficulté que l'on dit, et les bugs de type "segmentation fault" sont le plus souvent dus à un tableau mal dimensionné, ou des valeurs de début ou fin de l'indice d'itération non initialisées, ce qui n'est pas plus facile à éviter en Fortran qu'en C (sauf pour des boucles très simples, celles pour lesquelles on ne risque pas beaucoup de se tromper), et l'utilisation d'Electric Fence et de temps en temps Valgrind permet de détecter et corriger ces bogues très facilement.
En ce qui concerne le parallélisme, le Fortran 95 n'a aucun avantage réel sur le C, du moins pour un code utilisant des maillages non structurés, impliquant des tableaux d'indirection dans de nombreuses boucles, qui ne sont plus assez triviales pour utiliser les syntaxes de type A = B + C pour un tableau entier.
Même si l'on se contentait de parallélisme à mémore partagée, le forall du Fortran 95 serait limité à certaines boucles, et l'on aurait aussi besoin de threads ou de OpenMP. Or on utilise MPI, et l'API MPI est plus cohérente en C qu'en Fortran, dans la mesure où les fonctions utilisent des buffers de type void associés à un numéro de type de données. Comme n'existe pas de "void" en Fortran 95, l'API Fortran 95 de MPI ne peut gérer tous les prototypes issus des combinaisons possibles.
Pour en rajouter un couche, le déboggeur gdb gère mal le Fortran (ce n'est pas la faute à ce dernier, mais c'est encore un avantage pratique pour le C), et l'API trop "haut niveau" des entrées/sorties Fortran fait qu'il est difficile de gérer les aspects big-endian/little-endian pour avoir des fichiers binaires portables (en C, il faut le faire soit-même, mais c'est possible, alors qu'en Fortran, on est à la merci de la disponibilité d'options de compilateur adéquates, et le format des fichiers binaires est souvent semblable entre compilateurs, mais pas normalisé).
Finalement, la couche objet permise par le Fortran 2000, c'est bien joli, mais la norme Fortran 2000 n'est jamais sortie (c'est devenu Fortran 2003), et aucun compilateur actuel à ma connaissance (à part peut-être le compilateur Portland Group) ne gère la norme Fortran 2003 dans son ensemble, donc c'est à exclure pour un code qui doit être très facilement porté sur de nombreuses machines différentes.
Le manque de normalisation des appels C/Fortran avant le Fortran 2003 pose aussi un problème pour l'internationalisation via des mécanismes de type gettext (pas de fonctions à arguments variables comme le printf du C en Fortran, les print et write sont des fonctions intrinsèques, non surchargeables). Ce n'est pas critique pour un code scientifique, mais c'est dommage tout de même.
Pour revenir au parallélisme, la norme Fortran 2008 en cours de rédaction devrait intégrer le co-array Fortran (fort intéressant, de la même famille que Unified Parallel C pour le C ou Titanium pour Java), mais dans la mesure où l'on ne peut déjà pas compter sur un compilateur Fortran 2003, je ne serais pas étonné que les langages parallèles "haute productivité" issus des projets DARPA, comme l'X10 d'IBM, le Chape de Cray, ou le Fortress de Sun (ou une probable synthèse de ces langages) arrivent avant ou peu après le Fortran 2008...
[^] # Re: Concurrence
Posté par Yvan Fournier . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. Évalué à 10.
Lorsque l'écriture du prototype de Code_Saturne a démarré en 1997, les développeurs de l'époque ont choisi le Fortran 77, qu'ils maîtrisaient déjà. Les compilateurs F90 ou F95 étaient encore récents, et pour avoir essayé en 1997 les compilateurs et runtimes Nag ou HP (sur machines HP-UX à l'époque), c'était très décevant, avec à minima des bugs critiques dans les libariaires d'I/O associées.
Dans ces conditions, difficile de convaincre les "anciens" qui préféraient le Fortran 77 que le Fortran 95 était une bonne option. De plus, il n'y avait à l'époque pas de compilateur Fortran 90 ou 95 libre, ce qui était problématique dans la mesure ou l'on souhaitait garder un code portable et déployable facilement, y compris dans des labos externes, sans imposer l'achat d'un compilateur F90.
Pour les opérations associées au pré et post-traitement de maillages (concaténation, recollements de maillages non conformes, ...) il était indispensable de disposer au moins de structures et de mémoire dynamique, et le C faisait très bien l'affaire. Le C a donc progressivement fait son entrée dans le code via les aspects entrées/sorties, et le code C utilisé dans Code_Saturne utilise des notions de constructeur et destructeur (appelés explicitement), et de méthodes (mais pas d'héritage, pas vraiment nécessaire dans ce contexte).
A noter que le C a du faire ses preuves en étant au début mis en oeuvre dans des parties "non critiques" du code, les anciens développeurs s'en méfiant. En fait, en utilisant quelques règles simples (allocations mémoires encapsuleés et instrumentées, pour détecter facilement les fuites mémoire, utilsation fréquente, d'Electric Fence puis Valgrind, C89 avec prototypes évidamment, ...), nous n'avons jamais eu de problèmes liés à l'utilisation du C. Les pointeurs ne constituent pas une si grosse difficulté que l'on dit, et les bugs de type "segmentation fault" sont le plus souvent dus à un tableau mal dimensionné, ou des valeurs de début ou fin de l'indice d'itération non initialisées, ce qui n'est pas plus facile à éviter en Fortran qu'en C (sauf pour des boucles très simples, celles pour lesquelles on ne risque pas beaucoup de se tromper), et l'utilisation d'Electric Fence et de temps en temps Valgrind permet de détecter et corriger ces bogues très facilement.
En ce qui concerne le parallélisme, le Fortran 95 n'a aucun avantage réel sur le C, du moins pour un code utilisant des maillages non structurés, impliquant des tableaux d'indirection dans de nombreuses boucles, qui ne sont plus assez triviales pour utiliser les syntaxes de type A = B + C pour un tableau entier.
Même si l'on se contentait de parallélisme à mémore partagée, le forall du Fortran 95 serait limité à certaines boucles, et l'on aurait aussi besoin de threads ou de OpenMP. Or on utilise MPI, et l'API MPI est plus cohérente en C qu'en Fortran, dans la mesure où les fonctions utilisent des buffers de type void associés à un numéro de type de données. Comme n'existe pas de "void" en Fortran 95, l'API Fortran 95 de MPI ne peut gérer tous les prototypes issus des combinaisons possibles.
Pour en rajouter un couche, le déboggeur gdb gère mal le Fortran (ce n'est pas la faute à ce dernier, mais c'est encore un avantage pratique pour le C), et l'API trop "haut niveau" des entrées/sorties Fortran fait qu'il est difficile de gérer les aspects big-endian/little-endian pour avoir des fichiers binaires portables (en C, il faut le faire soit-même, mais c'est possible, alors qu'en Fortran, on est à la merci de la disponibilité d'options de compilateur adéquates, et le format des fichiers binaires est souvent semblable entre compilateurs, mais pas normalisé).
Finalement, la couche objet permise par le Fortran 2000, c'est bien joli, mais la norme Fortran 2000 n'est jamais sortie (c'est devenu Fortran 2003), et aucun compilateur actuel à ma connaissance (à part peut-être le compilateur Portland Group) ne gère la norme Fortran 2003 dans son ensemble, donc c'est à exclure pour un code qui doit être très facilement porté sur de nombreuses machines différentes.
Le manque de normalisation des appels C/Fortran avant le Fortran 2003 pose aussi un problème pour l'internationalisation via des mécanismes de type gettext (pas de fonctions à arguments variables comme le printf du C en Fortran, les print et write sont des fonctions intrinsèques, non surchargeables). Ce n'est pas critique pour un code scientifique, mais c'est dommage tout de même.
Pour revenir au parallélisme, la norme Fortran 2008 en cours de rédaction devrait intégrer le co-array Fortran (fort intéressant, de la même famille que Unified Parallel C pour le C ou Titanium pour Java), mais dans la mesure où l'on ne peut déjà pas compter sur un compilateur Fortran 2003, je ne serais pas étonné que les langages parallèles "haute productivité" issus des projets DARPA, comme l'X10 d'IBM, le Chape de Cray, ou le Fortress de Sun (ou une probable synthèse de ces langages) arrivent avant ou peu après le Fortran 2008...