Conseils généraux livre/site sur C++ et calcul scientifique/optimisation

**raoulpetite** · 20/03/2018, 11h20

Bonjour

Y'a-t-il des livres /sites qui font référence pour l'utilisation de C++ dans un cadre scientifique.
Je m'explique : il ne s'agit pas de petits calculs de base, mais je suis entrain de reprendre très largement d'un code assez gros qui est en C++. Le développeur précédent a pour l'essentiel fait de la programmation procédurale (donc du C en gros) en faisant appel à des biblio existantes en C++. Je le reprends pour des raisons scientifiques et j'aimerais au passage le rendre plus POO ... Mais là, je me heurte à plusieurs types de questionnement de néophytes (je connais les bases du C++ mais je manque d'expérience). Ces questionnements sont pour l'essentiel lié à des problèmes d'optimisation car le temps de calcul est conséquent (typiquement plusieurs jours). Des exemples de questions: perd-on du temps avec des getter (dans un cadre scientifique ne vaut-il pas mieux mettre des arguments en public plutôt que de faire de nombreux appels à des getters quitte à casser l'encapsulation), comment faire interférer efficacement des classes avec des gros tableaux externes ou membre (évidemment sans copier les gros tableaux => pointeurs, référence ... utiliser des itérateurs ?). Bref, existe-t-il quelque chose qui puissent orienter rapidement mes choix ? J'avais eu entre les mains des livres sur ces questions pour le FORTRAN par le passé .... Je me dis que cela doit bien exister pour le C++ (pas de soucis si c'est en anglais of course)

Ayez pitié pour quelqu'un pour qui le passage du FORTRAN 90 vers C++ est un peu dur

Merci par avance

**wolinn** · 20/03/2018, 12h28

On ne perd pas de temps avec les accesseurs ("getter") s'ils sont inline, et s'ils retournent une référence lorsque l'attribut est un objet complexe qu'on ne veut surtout pas copier. Il n'y a pas d'intérêt à casser l'encapsulation.
Dans un code de calcul intensif, quelques fonctions inline (pas seulement accesseurs) peuvent faire une grande différence sur les temps de calcul, s'il y a beaucoup d'appels de petites fonctions.
Ne pas oublier de régler correctement les options du compilateurs, en privilégiant la vitesse (par défaut, le compilateur n'est pas obligé de tenir compte des inline).

Je ne connais pas de livre consacré spécifiquement au sujet, mais certaines pratiques ne dépendent pas du langage, et tu les connais peut-être déjà à partir du FORTRAN
Exemples :
- pas d'allocation mémoire sur le tas dans une boucle de calcul intensif si ce n'est pas absolument nécessaire
- accès séquentiel des tableaux pour bien utiliser le cache du processeur
- organiser les tests pour favoriser le succès des prédictions de saut
etc.

**raoulpetite** · 20/03/2018, 12h59

Merci pour cette première réponse. Oui, j'ai quelques compétences en optimisation (mais elles commencent à dater et les rafraîchir me ferait du bien aussi)
Mais j'aurais tant de question en lien entre l'optimisation et le C++. J'ai cité les accesseurs (car à force de lire tout et son contraire sur le net, j'y ai perdu mon latin). Justement, j'avais fini par comprendre que la solution à beaucoup de mes problèmes réside dans des accesseurs vers des références et l'inlining. J'aurais pu parler de l'utilisation des vector de la STL et du moyen le plus efficace d'y accéder (probablement via les itérateurs je suppose). Et est-ce même bon d'utiliser les vector en calcul scientifique ? Bref, un truc qui me donnerait des lignes guide, même grossière m'aiderait pas mal.

**dinobogan** · 20/03/2018, 15h26

L'optimisation d'un programme (en temps, RAM, charge CPU, charge réseau...) ne se fait jamais avant le code. Tu dois d'abord faire un programme qui fonctionne.
Une fois fait, tu vas poser différents chronomètres aux différentes étapes du programme. Tu choisiras la zone qui te semble la plus évidente à améliorer, tu l'améliores puis tu refais tes chronométrages, etc...
Et je citerais le grand Donald Knuth, qui avait oublié d'être bête : "Premature optimization is the root of all evil".

Commence par faire ton refactoring en POO, selon ta vision. Un refactoring ne se fait pas en une seule étape. Tu suivras un cycle itératif ponctué de modifications, retours en arrière, chronométrages, concessions, recherches, décisions difficiles à prendre, choix arbitraires...

**Luc Hermitte** · 20/03/2018, 15h46

Les getters tendent à être un anti-pattern, enfin pas au point des setters, mais il faut savoir rester prudent à leur égard. Si tu as des classes qui ne contiennent que des données, qui n'ont ni invariant ni service, alors fais-en des structures (c'est une convention), et vire les getters et setters.
Maintenant, en HPC, si tu crains qu'ils te ralentissent car tu vas beaucoup y faire appel, il y a a alors de plus fortes chances que ce qui va te ralentir soit le fait que tu manipules un tableau de structures (AoS) et non une structure de tableaux (SoA), mais ça d'un point de vue cache, tu devrais déjà connaître.

Je rajouterai: profite au maximum de bibliothèques optimisées qui vont s'occuper de l'essentiel du boulot pour toi, typiquement pour le calcul matriciel, tu as eigen et blaze qui vont t'offrir une souplesse d'écriture et qui en plus vont de te permettre de plugger la MKL pour les calculs si tu disposes de sa licence -- quoique je soupçonne que l'on puisse en disposer gratuitement et légalement via python-intel.

Pour le reste, C++ et Fortran, c'est très proche. Hormis que les tableaux sont stockés par lignes et non par colonnes; et que les boucles s'écrivent dans le sens inverse à cause de cette inversion d'indices.

Et oui, il n'y a aucun mal à faire du procédural, non OO, en C++. Par contre, c'est dommage de se priver des templates, et encore plus du RAII. Dans tous les cas, ne fais pas de l'OO pour une simple raison d'aveuglement dogmatique. Le C++ est un langage pragmatique qui offre de nombreux outils, il faut savoir utiliser celui qui est le plus adapté au besoin.

Quoi d'autre ?
- passe les gros objets par référence, les petits par copie
- le retour de fonction par valeur n'est pas un problème s'il n'implique pas d'allocation
- les algos templates de la SL n'impliquent pas de dégradation de performance, c'est plutôt le contraire
- choisi un compilateur le plus récent possible avec un dialecte du C++ le plus récent possible: entre la sémantique de déplacement et constexpr apparus en C++11 et raffinés entre temps, des optimisation s'invitent dans notre dos ; sans parler que les compilos s'améliorent à chaque version
- les exceptions coûtent en taille de binaire mais pas forcément en temps d'exécution car elles impliquent que le code en cache ne contient que le chemin nominal et pas les traitements des erreurs -- mais pour bien en profiter, il est bon de marquer "noexcept" les fonctions "feuilles" que l'on sait travailler sans pouvoir lancer d'exception. Marquer une fonction non feuille noexcept alors qu'elle appelle des fonctions non-noexcept peut dégrader les performances
- plein d'autres choses probablement qui sur le coup m'échappent.

agner a écrit un certains nombre de documents sur le sujet de l'optimisation. J'ai croisé un certain nombre de conférence sur cppcon, cpp::dive.. qui traitent d'optimisation en C++, souvent le sujet est "regardez, je vais aussi vite, voire plus, que le C, et pourtant j'utilise des templates, des objets..."

@dinobogan, quand le lis "portage Fortran -> C++", on n'est pas vraiment dans le cadre plus classique de programmes qui manipulent du texte, du disque de façon triviale, etc. Il y a de fortes chances qu'il y ait du calcul intensif, et cela se réfléchit à l'avance. Ceci dit, +1 pour les outils. J'ai joué avec VTune et avec Advisor dernièrement et, c'est pas mal du tout comme outil -- en plus Intel vient d'annoncer une licence gratuite de 90j renouvelable indéfiniment, ils sont forts au service commercial.

**raoulpetite** · 20/03/2018, 16h43

Merci pour ces retours...

@Luc Hermitte : Dans les faits, justement je ne veux pas faire de la POO de manière aveugle, surtout pas et c'est bien pour ça que je me pose des questions avant de compliquer inutilement un code (avec des concepts dont je n'ai qu'une maîtrise modérée) dont le but final est d'être aussi rapide que possible. Et, justement sur le net, j'ai l'impression que beaucoup de réponses sur des forums sont faîtes par des informaticiens pour des informaticiens .... Ce n'est pas mon cas, je veux voir le C++ pour son applicabilité au calcul scientifique et effectivement, il restera beaucoup de procédurale dedans et ça ne pose pas de problèmes. Mais en l'état, le code que je refais mérite de mieux utiliser les possibilités du C++.

@Luc Hermitte: Effectivement quand pas de méthodes à associer, je ne fais pas une classe mais une structure.

@Luc Hermitte: Concernant les bibliothèques optimisées, c'est justement le passage à une telle bibliothèque qui a conduit au passage au C++.

Toujours @Luc Hermitte :pour l'inversion ligne colonne, je ne le savais pas (et ça doit avoir des conséquences non négligeables ...). C'est le genre de "détails" que je ne voudrais pas louper.

@dinobogan : Effectivement, je procède un peu comme tu le suggères: en gros par essai, erreur, mais bon je ne veux/peux pas non plus partir complètement à l'ouest. Ce n'est pas forcément trivial en calcul scientifique de reformuler le problème après coup. Enfin si, mais la perte de temps engendrée peut-être très importante et j'ai déjà bien assez à gérer la "partie science" à proprement parler.

Merci @Luc Hermitte : agner semble une piste intéressante à suivre

**JolyLoic** · 20/03/2018, 17h05

Envoyé par dinobogan

L'optimisation d'un programme (en temps, RAM, charge CPU, charge réseau...) ne se fait jamais avant le code. Tu dois d'abord faire un programme qui fonctionne.
Une fois fait, tu vas poser différents chronomètres aux différentes étapes du programme. Tu choisiras la zone qui te semble la plus évidente à améliorer, tu l'améliores puis tu refais tes chronométrages, etc...
Et je citerais le grand Donald Knuth, qui avait oublié d'être bête : "Premature optimization is the root of all evil".

Et premature pessimization too

Je suis 100% d'accord avec ce que tu dis, quand on parle des micro-optimisations, mais il y a des optimisations de plus haut niveau qui peuvent mériter qu'on s'y penche plus tôt :
- Choisir les bonnes bibliothèques qui correspondent bien au domaine d'application (par exemple, dans le cas du posteur initial, probablement une bibliothèque de matrices et/ou une bibliothèque de vectorisation)
- Choisir des structures de données qui ne soient pas idiotes en terme de grand-O
- Choisir les bons algorithmes
- Réfléchir dès le début si on va distribuer le calcul sur plusieurs nœuds, et si oui comment le découper, quelles structures d'échange de données à prévoir
- Utiliser les bonnes pratiques du langage (Luc en a cité quelques unes) afin de ne pas perdre du temps inutilement

**wolinn** · 21/03/2018, 08h37

raoulpetite:
Tu peux quand même chercher l'ouvrage suivant :
"Introduction to high performances computing for scientists and engineers", Chapman & Hall
C'est essentiellement consacré à la parallélisation, les astuces propres au C++ n'occupent que quatre pages (et ont essentiellement déjà été mentionnées dans cette discussion), mais il y a des références vers d'autres ouvrages dans la bibliographie. Les exemples du livre sont en C++ et FORTRAN.