Posté par magnolia .
En réponse à la dépêche LLVM 3.4 et Clang 3.4.
Évalué à 7.
Dernière modification le 26 janvier 2014 à 13:06.
Les codes numériques sont aujourd'hui majoritairement écrits en MATLAB/Python/C++/C/Fortran. En langage compilés il reste donc C++/C/Fortran.
Une grande partie de la MKL (Math Kernel Library, développée par Intel) est écrite en C, pour que tout soit optimisé aux petits oignons. Une telle optimisation nécessite une très bonne connaissance du compilateur et du processeur pour lequel vous optimisez. Intel sait le faire, mais il ne doit pas y avoir grand monde qui sait le faire correctement.
De nombreux code sont aujourd'hui écrits en C++ et certains codes sont très bien programmés. Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique. Les journées ayant un nombre limitées d'heures, il est bon de ne pas se surcharger en "connaissances" informatique. En analyse numérique, il est essentiel de bien maitriser :
- La gestion de la mémoire
- L'OpenMP, le MPI
- Des Design Pattern qui ne ruinent pas la performance
C'est déjà beaucoup pour une personne qui doit connaître aussi de la physique et des maths (surtout cela d'ailleurs). Se lancer dans l'apprentissage et la maitrise du C++ est une longue route, et l'optimisation du C++ est parfois "surprenante". Par exemple, si vous écrivez :
for (i = 0; i < size; i++) {
v[i] = pow((double) (i+1), -2);
}
vous verrez que le "vectorizer" va se comporter de manière très différente selon : le type de vecteur utilisé ("vecteur" C, ou std::vector), le compilateur utilisé (gcc ou icc) ainsi que sa version. Il y a 2 ans, icc n'était pas fichu de vectoriser le code lorsque v était un std::vector. J'en avais discuté avec des développeurs Intel qui confirmait ce problème (Voir ici std::vector et vectorisation). Depuis, ce problème a été résolu sur icc, mais une recherche rapide montre que les compilateurs microsoft ont encore du mal avec cela : Problème de vectorisation en C++. J'imagine qu'il y a encore de nombreux problèmes, même avec icc et gcc.
Du fait de l'inexistence de pointeurs (ou plutôt du fait qu'ils ne peuvent pas pointer vers n'importe quoi), le Fortran est bien plus facile à optimiser pour les compilateurs et ce genre de surprise n'existe pas vraiment. C'est un langage facile à utiliser, efficace et propre. Il y a même de très bon bouquins sur les Designs Pattern avec des exemples en Fortran : Design Pattern.
Malheureusement, de nombreux code Fortran sont vraiment programmés avec les pieds d'un point de vue d'un informaticien. Ce n'est pas propre au language, mais aux capacités informatiques des programmeurs qui sont le plus souvent tout d'abord des matheux et des physiciens. Si vous leur donnez entre les mains du C++, vous courez à la catastrophe.
J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
[^] # Re: mélange de langage ?
Posté par magnolia . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 7. Dernière modification le 26 janvier 2014 à 13:06.
Les codes numériques sont aujourd'hui majoritairement écrits en MATLAB/Python/C++/C/Fortran. En langage compilés il reste donc C++/C/Fortran.
Une grande partie de la MKL (Math Kernel Library, développée par Intel) est écrite en C, pour que tout soit optimisé aux petits oignons. Une telle optimisation nécessite une très bonne connaissance du compilateur et du processeur pour lequel vous optimisez. Intel sait le faire, mais il ne doit pas y avoir grand monde qui sait le faire correctement.
De nombreux code sont aujourd'hui écrits en C++ et certains codes sont très bien programmés. Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique. Les journées ayant un nombre limitées d'heures, il est bon de ne pas se surcharger en "connaissances" informatique. En analyse numérique, il est essentiel de bien maitriser :
- La gestion de la mémoire
- L'OpenMP, le MPI
- Des Design Pattern qui ne ruinent pas la performance
C'est déjà beaucoup pour une personne qui doit connaître aussi de la physique et des maths (surtout cela d'ailleurs). Se lancer dans l'apprentissage et la maitrise du C++ est une longue route, et l'optimisation du C++ est parfois "surprenante". Par exemple, si vous écrivez :
vous verrez que le "vectorizer" va se comporter de manière très différente selon : le type de vecteur utilisé ("vecteur" C, ou std::vector), le compilateur utilisé (gcc ou icc) ainsi que sa version. Il y a 2 ans, icc n'était pas fichu de vectoriser le code lorsque v était un std::vector. J'en avais discuté avec des développeurs Intel qui confirmait ce problème (Voir ici std::vector et vectorisation). Depuis, ce problème a été résolu sur icc, mais une recherche rapide montre que les compilateurs microsoft ont encore du mal avec cela : Problème de vectorisation en C++. J'imagine qu'il y a encore de nombreux problèmes, même avec icc et gcc.
Du fait de l'inexistence de pointeurs (ou plutôt du fait qu'ils ne peuvent pas pointer vers n'importe quoi), le Fortran est bien plus facile à optimiser pour les compilateurs et ce genre de surprise n'existe pas vraiment. C'est un langage facile à utiliser, efficace et propre. Il y a même de très bon bouquins sur les Designs Pattern avec des exemples en Fortran : Design Pattern.
Malheureusement, de nombreux code Fortran sont vraiment programmés avec les pieds d'un point de vue d'un informaticien. Ce n'est pas propre au language, mais aux capacités informatiques des programmeurs qui sont le plus souvent tout d'abord des matheux et des physiciens. Si vous leur donnez entre les mains du C++, vous courez à la catastrophe.
J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.