InsideLoop a écrit 27 commentaires

Bonjour Lois,

Qu'entends-tu pas "la cuisine Intel" ? Il est possible de programmer les Xeon et Xeon Phi de manière efficace avec le Fortran/C/C++, OpenMP 4.0 et MPI. Depuis la version 4 d'OpenMP, les informations pour la vectorisation (alignement par exemple) peuvent toutes être données avec cette norme et les pragma propriétaires Intel ne sont plus utiles.

Pour ceux qui préférent le work-stealing au work sharing pour le multithreading (mais ce n'est surement pas le modèle à préconiser pour les calculs faits sur les machines du TOP 500), il y a TBB qui est Open Source.

L'instruction "implicit none", qui fait partie du Fortran 90, est heureusement supporté depuis bien longtemps par gfortran. Ici, on parle de "implicit none (external)" qui fait partie du Fortran 2015 et qui semble étendre l'interdiction des implicites aux procedures et subroutines. Vous pouvez voir ici pour plus d'explication : Discussion sur la mailing-list gcc.

LISP, Cilk, IA, … Tu bosses au MIT ?
Sinon, tu as déjà utilisé Julia ? Qu'en penses-tu ?

Mais le Fortran a de vrais avantages par rapport au C++ pour ce qui est calcul numérique (pas d’aliasing, comme tu le dit, de vrai tableaux, la notion de parallélisation intégrée au langages, …).

• Pour l'aliasing, il y a soit le keyword restrict du C qui est reconnu par pas mal de compilateur C++. Après, il faut voire ce qu'il en font. Le compilateur Intel fait du bon boulot, clang est passable et gcc catastrophique. Il y a certaines techniques qui permettent d'éviter l'aliasing sans le keyword restrict, par exemple ne jamais passer par reference non constante, et donc toujours renvoyer par valeur.
• Les vrais tableaux, il faut effectivement se faire sa propre bibliothèque ce qui rend le truc non universel.
• Pour la parallélisation, je reste sceptique sur les Coarrays. Seul le compilateur Intel les implémente et les performances sont bien en dessous du MPI selon Steve Lionel, M. Fortran chez Intel. Il faut qu'ils optimisent tout cela, et je ne sais pas si ils vont trouver assez d'utilisateurs. Il y a aussi le problème du CUDA et d'OpenCL qui sont majoritairement en C/C++.

Bref, ça commence à sentir le roussi pour le Fortran. C'est dommage car c'est un excellent langage, mais j'ai l'impression que les temps sont durs pour les langages non généralistes.

Et pourtant, c’est possible

J'avais vu cela, ce qui prouve que c'est possible sous Android. Sous iOS, je crois que c'est impossible. Le C++ sans aucune bibliothèque (surtout pas Boost) reste très portable et compile de facto sur plus de plateformes que le Fortran. Et puis, en un an de C++ je n'ai quasiment reporté aucun bug de compilateur chez Intel (sauf quelques optimisations qui n'étaient pas faites). Avec ifort, j'ai bien renvoyé une dizaine de bugs chez Intel en 3 ans. C'était des bugs qui concernaient le Fortran 2003, mais certains étaient vraiment génants.

En fait, le truc qui me manquerait le plus en revenant au Fortran, ce serait :
- Un bon IDE (Visual Studio avec le plugin Intel et Eclipse + Phortran ne sont pas à la hauteur des outils Jetbrains)
- Google Test
Bref, c'est l'ensemble des outils à côté du langage qui me manqueraient. En même temps, quitter le C++, ce serait
- se débarrasser des rigolos qui font du template metaprogramming
- se débarasser des rigolos qui font des trucs illisibles pour se donner l'air intelligent
- se débarasser des gens qui font std::vector< std::vector< double > > pour faire une matrice (Ahrrrrrrr) et de tous ceux qui ne s'intéressent pas à la mémoire en général
- se débarrasser des problèmes d'aliasing

Je sais bien. Il faut quand même savoir que c'est très récent car même si cela date du Fortran 2003, ce n'est utilisable que depuis environ 2010. Vu le nombre de bugs que j'ai remonté chez Intel et ifort, je ne suis pas sur que beaucoup de personnes l'utilisent. Le code Fortran 2003 de ce bouquin http://www.amazon.fr/Scientific-Software-Design-Object-Oriented-Way/dp/1107415330/ref=sr_1_1?ie=UTF8&qid=1428768323&sr=8-1&keywords=scientific+object+oriented+way ne compilait avec quasiment aucun compilateur il y a 2 ans.

Je continue à penser que le Fortran est un excellent langage pour développer des codes scientifiques. Mais je suis passé au C++ pour mes nouveaux projets car : il y a un type entier non signé sur 8 bits (essentiel pour l'image),cela se vend mieux, il y a de très bonnes IDE (CLion de jetbrains), de bonnes bibliothèques de tests unitaires, compile sur tout ce qu'on veut (pas de compilateur Fortran sur les téléphones par exemple) et le langage est très sur si on ne fait aucun "new/delete", ce qui est possible aujourd'hui.

Les compilateurs ont déjà une vision globale, par exemple l'option -ipo de ifort.

J'ait fait du Fortran orienté objet pendant 3 ans et sur un code de 15 000 lignes j'ai compris ma douleur avec -ipo. J'avais des classes avec des getter qu'il fallait absolument inliner pour la performance, d'où l'utilisation de -ipo. Malheureusement, avec ce code qui restait de taille raisonnable, la passe -ipo prenait parfois 20 minutes :-(. Donc, -ipo est à utiliser avec parcimonie.

Quand je parlais de vision globale, j'imaginais un compilateur capable de transformer automatiquement des arrays of struct en struct of arrays ou des optimisations qui nécessitent un peu de recul. C'est la que les compilateurs n'ont quasiment aucune compétence.

La FFTW est géniale mais va l'utiliser sur 10_000 coeurs ;-)

Je fais du conseil en HPC et des gens qui utilisent 10 000 coeurs, je n'en vois pas tous les jours. On les voit bien sur dans les plaquettes publicitaires, au CEA ou dans certaines universités mais il la plupart des codes scientifiques tournent sur des bonnes workstation (genre bi-Xeon) voire souvent des portables ;-)

Au passage, si vous voulez vraiment savoir ce que les gens utilisent en HPC, vous pouvez lire ceci : http://www.amazon.fr/High-Performance-Parallelism-Pearls-Programming-ebook/dp/B00PLOC4D6/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1428767960&sr=1-1-catcorr&keywords=parallel+pearls . On y voit du Fortran, C++ (qui ressemble surtout à du C, sans std::vector par exemple), OpenMP, MPI.

Le seul succès d'un langage fonctionnel que je connais en HPC, c'est la bibliothèque FFTW. C'est une excellente bibliothèque pour calculer des transformées de Fourier rapide. Ils ont utilisé OCaml non pas pour la bibliothèque mais pour générer du code C qui constitue la bibliothèque.

Allez voir http://benchmarksgame.alioth.debian.org qui est a ma connaissance la meilleure comparaison de performance entre les implémentations des différents langages (cela a bien sur des défauts, mais c'est difficile de faire mieux). Le Haskell et l'Ocaml se prennent un facteur 2 en moyenne face au C/C++/Fortran.

Si certains qui font du High Frequency Trading utilisent des langages fonctionnels, c'est qu'ils font souvent du code "jetable". Le code doit être : rapide, correct et développé rapidement. C'est la partie "correct" et "développé rapidement" qui les poussent vers les langages fonctionnels, pas la rapidité. Bien sur si ils se prenaient un facteur 100 par rapport au C, cela leur poserait problème, mais ils sont prêt à se prendre un facteur 2.

Les langages fonctionnels seront plus rapide que le C/C++/Fortran le jour où les compilateurs auront une vision globale du code meilleure qu'un bon programmeur. Autant, sur une vision locale, les compilateurs sont bien meilleurs que n'importe quel humain, sur une vision globale, ils sont complètement myopes.

Merci lasher pour ton intervention. J'avais lu avec interêt ton article "Ou vont les supercalculateurs ?". Si ce n'est pas indiscret, pour qui travailles-tu ?

Concernant les langages et le calcul parallèle, je comprends bien l'avantage des types non mutables pour éviter les "data race" et donc l'avantage des langages fonctionnels. Cependant, si on a besoin de parallélisme, on est bien souvent amené à utiliser OpenMP, MPI voire CUDA. On se retrouve donc contraint à développer en Fortran ou C/C++ si on veut gérer finement tout cela. Je n'ai jamais vu un bouquin sur le HPC qui utilise autre chose que du C/C++ (ou du Fortran). Dans ces applications il est d'ailleurs hors de question d'utiliser une JVM.

Du coup, les langages fonctionnels pour le HPC, j'en entends souvent parler, mais je ne les vois jamais. Est-ce que c'est une réalité aujourd'hui où une direction que les universitaires (qui n'ont pas autant de contrainte historique que beaucoup d'industriels et qui ont dans leur rang beaucoup plus d'experts en langage fonctionnel) souhaitent prendre ?

Écrire un logiciel comme Maple/Mathematica qui fait à la fois du calcul formel et du numérique est un travail titanesque. Je pense qu'un tel projet nécessiterai plus d'efforts que d'écrire une suite de compilateurs comme gcc ou llvm/clang. C'est pour cela qu'il y a peu de chances qu'un projet libre rivalisant avec Maple/Mathematica fonctionne. C'est dommage, mais j'ai laissé tombé les logiciels libres dans ce domaine.

Le problème est que certains élèves auront fait du Python et d'autres (j'espère peu) auront fait du Scilab. Il passeront la même épreuve écrite et ayant été jury de concours, je sais très bien comment cela va se passer : les épreuves seront écrites pour le Python et au dernier moment on ajoutera une version de la question en Scilab. Les correcteurs connaitront le Python et auront une très vague idée de Scilab (je sais, ils devraient savoir programmer très bien dans les deux, mais en pratique je vous assure que cela ne sera pas le cas). Au final les élèves faisant du Scilab seront désavantagés.

Le problème s'est posé pendant 20 ans avec les épreuves faites pour OCaml/Pascal. Il continuera donc surement avec Python/Scilab.

Comme ma société fait de l'optimisation de code scientifique, je me suis pas mal intéressé au monde de la finance et en pratique la majorité de leurs codes sont soit en C++ soit en C#. Mais c'est vrai que l'on trouve une partie des utilisateurs de languages fonctionnels (Ocaml, F#, Mathematica) dans la finance.

Pour le D, Facebook l'utilise http://www.drdobbs.com/mobile/facebook-adopts-d-language/240162694 . Ils ont même embauché Andrei Alexandrescu, l'inventeur du D. Donc c'est assez sérieux pour eux.

Pour Rust, leur site conseille de ne pas l'utiliser en production. C'est donc trop jeune.

De son côté OCaml a 20 ans. Et même si il a un succès relatif, c'est resté un langage de niche.

Je veux bien considerer F# et OCaml comme "le même" langage. Mais cela reste des langage de niche.

Il est probable que D ou Rust aient déjà plus d'utilisateurs. Si on regarde Facebook par exemple, je crois qu'ils investissent dans le D.

OCaml a pour moi plusieurs défauts comme premier langage :
- Il met en avant la programmation fonctionnelle alors que l'essentiel des langages fonctionne de manière impérative. Du coup, les élèves sortent de prépa en ayant le reflex de la récursivité pour presque tous les problèmes. Pour exploser la pile, il n'y a pas mieux ;-)
- Il n'y a quasiment aucune bibliothèque. Si vous voulez charger une image, résoudre numériquement un système linéaire ou télécharger un fichier sur internet, vous êtes rapidement tout nu. Du coup, l'informatique reste une discipline qui a du mal à se mélanger aux autres disciplines comme la physique. On fait de l'info pour faire de l'info.
Bref, OCaml est un excellent langage pour préparer les élèves à faire de la recherche en informatique. C'est à mon avis un très mauvais langage pour la grande majorité des élèves qui utiliseront plus tard l'informatique comme un outil.

En informatique pour tous, depuis la reforme de 2013, tout se fait en Python, sauf une petite partie du programme qui peut se faire en Python ou en Scilab. Quel intérêt ? Cela rend la conception de sujets plus difficiles et la correction encore plus. C'était déjà la cas avant où OCaml et Pascal étaient autorisés pour l'enseignement et cela posait pas mal de problèmes pour des questions qui étaient simples dans un langage et très difficiles dans un autre. C'est pourquoi je disais que c'était un choix à mon avis irresponsable. Sinon, n'oubliez pas que l'éducation nationale ne forme aucun prof d'informatique (pas d'agreg d'informatique par exemple) et que ce sont les profs de maths qui le plus souvent enseignent l'informatique. C'est la raison pour laquelle l'informatique en prépa est souvent réduite à des choses assez "mathématiques" comme l'algorithmique pure ou les langages reconnaissables.

Enfin, pour ce qui est des logiciels de calcul formel, bien entendu que n'importe quel logiciel libre peut faire ce que l'on demande aux étudiants. Il y a même des domaines très spécifiques comme la théorie des groupes dans lesquels les logiciels libres sont bien plus puissants que Mathematica ou Maple. Seulement, ces logiciels ayant un nombre très avancé de fonctions, sans documentation de qualité, il est souvent impossible de s'y retrouver. Enfin, je crois qu'il est essentiel d'apprendre des logiciels qu'ils utiliseront dans leur vie professionnelle. C'est pourquoi passer du temps sur XCas est ridicule. Malheureusement, il n'y a aucun logiciel de calcul formel libre complet et bien documenté. Sage a eu un certain succès, mais c'est juste une grosse usine à gaz qui essaie de faire tenir ensemble un tas de logiciels qui n'ont jamais été écrits pour fonctionner ensemble. J'ai peu d'espoir sur un logiciel de calcul formel libre à court terme. Il était question à un moment que MuPAD devienne libre. C'était un superbe logiciel, bien documenté, mais il a fini dans les mains de Mathworks ;-(

Je rangerai Octave dans la même catégorie que Scilab : un logiciel bien fait, mais qui ne fait pas le poids en terme d'utilisateurs face à la communauté Python/Numpy. Dans le logiciel scientifique libre, seul R a pris une place conséquente face à Python (quasiment tous les statisticiens l'utilisent). Ce qu'on oublie souvent, c'est que pour un tel logiciel soit bon, il faut un support de bonne qualité et notamment des bons livres. Ici encore, Python et R dominent. Un livre comme celui-ci http://www.amazon.com/Introduction-Statistical-Learning-Applications-Statistics/dp/1461471370/ref=sr_1_1?ie=UTF8&qid=1428407657&sr=8-1&keywords=statistical+learning+R n'existe pas pour Octave. Je sais bien qu'on peut adapter, mais cela facilite tellement la compréhension de parler le même langage.

C'est un peu comme OCaml. C'est bien gentil d'enseigner OCaml a des élèves de prépa, mais soyons réalistes. Qui utilise OCaml ? Je sais bien qu'on l'a utilisé pour vérifier la cabine de pilotage de l'A380 et LLVM peut même se contrôler par l'intermédiaire d'OCaml. Même Microsoft qui l'a rendu compatible avec .NET en le renommant F# ils n'arrivent pas le pousser en dehors des mathématiques financières où il vivote. J'ai vu tellement d'élèves sortir de prépa penser que bonne programmation informatique rimait avec récursivité pour tous les problèmes, que je crois qu'il est temps d'utiliser des outils utilisés par une proportion significative des personnes. Pour cette raison, je crois que Python est un bon choix dans l'enseignement de l'informatique pour tous et je suis ravi qu'il ait été adopté.

En tant qu'agrégé de mathématiques et ancien professeur de mathématiques (et d'informatique) en classes préparatoires, je ne peux que féliciter cette initiative. Le seul problème reste celui de la qualité des logiciels libres. Et là, il faut faire le tri, ce qui est toujours le problème avec les logiciels libres. Les logiciels à retenir sont à mon avis :

• R : pour les statistiques. C'est la référence actuelle pour les stats.
• Python/Numpy/Scipy et son ecosystème avec un environnement qui va bien comme PyCharm : C'est la meilleure alternative actuelle à Matlab. Pitié, pas de Spyder qui ne passerait pas la phase de beta-test de beaucoup d'éditeurs de logiciels (Vous avez déjà essayé de changer l'ordre des fenêtres ?).
• Geogebra pour la géométrie interactive

Le reste est à mon avis à oublier. Malheureusement, il n'existe aucun logiciel de calcul formel "utilisable" en logiciel libre (j'ai des exigences que beaucoup qualifient d'élevées). Sage est une usine à gaz comme personne n'a osé inventer avant et seul Maxima me semble digne d'intérêt. Malheureusement, la documentation des ces logiciels laisse toujours à désirer et on est à des années lumières des solutions propriétaires comme Mathematica. Je préfère rester poli et ne pas parler d'XCas qui est certes un projet sympathique mais qui n'a aucun avenir international.

En numérique, Scilab, bien qu'étant très aboutit, reste très franco-français (voire franco-chinois) et me semble en bien mauvaise posture face à un écosystème python qui est utilisé internationalement.

Il serait bon de selectionner et de mettre les réussites libre en avant et de trier. Je sais qu'en classes préparatoires, la mention de Scilab a été ajoutée au dernier moment, juste pour faire plaisir à certains de l'INRIA. Ou comment saper un programme qui se base essentiellement sur Python et introduire un doute dans la tête des profs de prépas. Cela manque terriblement de responsabilité.

Sans exagérer, les seules structures de donnée que j'utilise sont basées sur des tableaux. Quasiment tout le calcul scientifique se fait avec cela, ce qui explique pourquoi le Fortran est encore très adapté à ces tâches. Il est très rare d'avoir à sortir un algorithme difficile ou une structure de donnée tordue. J'ai même fait un tri bulle une fois sur des tableaux; Comme il y avait 100 000 000 de tableaux de 14 éléments à trier, c'est ce qu'il y a de plus efficace ;-)

Il est évident qu'il y a d'autres domaines où des structures de données complexes sont utiles, les compilateurs par exemple. Seulement, de nombreux programmeurs expérimentés reviennent aux tableaux quand il faut être efficace. Regardez par exemple cette présentation de Chandler Carruth (Responsable du C++ chez Google et développeur de la partie optimisation de LLVM). Je vous résume le talk en une phrase : "Pour la performance, dès que vous le pouvez, utilisez des tableaux". https://www.youtube.com/watch?v=fHNmRkzxHWs

Une recherche binaire sur une liste chainée (qui a un ForwardIterator) !!! Il est fort le Rust. Ca n'a aucun sens.

http://stackoverflow.com/questions/5281053/how-to-apply-binary-search-olog-n-on-a-sorted-linked-list

Sur le site de Rust, je ne vois que des recherches binaires sur des slices (qui sont des tableaux). Je ne vois d'ailleurs pas ce qu'on pourrait faire d'autre. Si vous faites une immense queue et que tout ce que vous voyez c'est votre voisin de devant, vous êtes incapable de savoir ou est le milieu de la queue en une seule opération !

Et il renvoie quoi ? Des entiers (Result< usize, usize >) ! Ce serait pas des index par hasard ? ;-)

Il n'y a pas de bound-check en C++ dans le langage. Tout est fait dans la bibliothèque standard. Si v est un std::vector, et que la STL est en mode debug, pour chaque accès à v[k], il y a du code qui vérifie la valeur de k et qui selon les implémentations de la STL lance une exception ou stope le programme. Tout ce qu'il voit en mode debug sur une boucle très régulière du type

for (int k = 0; v < v.size(); ++k)
c'est qu'il ne sait même pas si il va finir la boucle ! Le compilateur ne peut donc plus rien faire. C'est un des gros désavantage du C++ d'avoir mis trop de choses dans la bibliothèque plutôt que dans le langage. Le seul moyen que je vois pour faire cela correctement est d'avoir les tableaux qui font intégralement parti du langage. C'est le cas en Fortran et en C#. Tu sembles dire que ce n'est pas le cas en Rust.

Si k = -1 (int) et n = 2 (int), alors static_cast< unsigned int >(-1) est égal à 2³² - 1 et static_cast< unsigned int >(2) est égal à 2. La comparaison renvoie donc bien false comme on le souhaite. Le bound checking se fait donc parfaitement avec des entiers signés en une seule opération. Pour se convaincre que le cout est le même, il suffit de regarder l'assembleur de :

bool in_range(int k, int n) {
return static_cast<unsigned int>(k) < static_cast<unsigned int>(n);
};
et de

bool in_range(unsigned int k, unsigned int n) {
return k < n;
};
Ce sont exactement les mêmes (testé avec clang++).

De toute façon, le problème du bound-checking sur chaque élément n'est pas vraiment une histoire de une où deux comparaisons. Sa présence empêche la vectorisation automatique et bien d'autres optimisations. Il est donc impossible d'avoir un bound-checking en C++ sans perte de performance notable. Le seul moyen pour avoir un bound-checking raisonnable est que les tableaux fassent partie du langage comme en Fortran, C# ou Rust. Il faut ensuite mettre tout cela dans le compilateur ce qui ne doit pas être une mince affaire. Je crois par exemple que l'équivalent C# de

for (int k = 0; k < n; ++k) {
    v[k] = ;
}

vérifie une fois avant d'entrer dans la boucle que n <= v.size() et ne fait plus aucun bound-cheking ensuite. On peut alors dire que le bound-cheking a un impact négligeable sur la performance. Mais, je ne crois pas que ces idées soient poussées très loin.

Enfin, pour remettre une couche sur les itérateurs, on fait comment une recherche dichotomique dans un tableau trié avec des itérateurs ? ;-)

C'est effectivement l'utilité de ce genre de bibliothèque.

Pour ce qui est du cout du bound check (en C++) avec des entiers non signés, c'est une opération:

k < n
et avec des entiers non signés, c'est aussi une seule opération

static_cast<unsigned int>(k) < static_cast<unsigned int>(n)
Comme le passage de int à unsigned int est une opération qui n'en n'est pas une pour le processeur, le cout est exactement le même. Il n'y a donc qu'un seul bound à vérifier. Je te promet que l'utilisation des entiers non signés n'a que des inconvénients et aucun avantage par rapport à des entiers signés.

Je pense que là où on ne se comprends pas est que tu parles souvent de collection et je parle de tableau. Qu'on traverse une liste chainée ou un tableau avec des itérateurs, on ne voit aucune différence dans le code source. Cela fait plaisir aux adaptes de la programmation générique, mais cela me gêne si on veut avoir une bonne image de la performance de ce qu'on écrit. Traverser une liste chainée est une catastrophe au niveau du cache alors qu'un tableau est la structure de donnée qui est la plus facile à traiter pour pour ce dernier.
Pour les mêmes raisons, l'utilisation d'OpenMP est basée sur l'indexation avec des entiers et ne marchera jamais avec des itérateurs tout simplement car cette abstraction fait qu'on oublie qu'on travaille avec un tableau.

Dans mon domaine (calcule scientifique), les itérateurs ne sont donc jamais utilisés. C'est aussi la raison pour laquelle le Fortran est encore très populaire dans ce domaine : c'est le langage qui a la meilleure implémentation des tableaux.

Sinon, question performance, j'aime beaucoup les conférences de Chandler Carruth qui s'y connait bien car il a travaillé longtemps sur l'optimiseur de LLVM : https://www.youtube.com/watch?v=fHNmRkzxHWs . Son discours se résume en une phrase : "Utilisez au maximum les tableaux".

Tout d'abord, je tiens à préciser que je parle du C++ et non de Rust que je ne connais pas.

La fait de passer d'un "array of struct" à un "struct of array" change effectivement l'API. Mais ces optimisations sont bien trop importantes pour ne pas être faites dans les programme que j'écris.

Concernant le bound-checking, il n'est jamais activé en mode "Release" car il a trop d'impact sur la performance en C++. Le Rust est une autre histoire car les vecteurs sont intégrés dans le langage et non dans une bibliothèque.

Enj0lras: Je ne vais pas m'attarder sur le ton condescendant de ton message. Revenons plutôt au sujet.

Si je comprends bien ton message, tu ne comprends pas pourquoi j'utilise des entiers pour traverser un tableau alors que le C++ permet bien d'autres manières à savoir :

    for(auto it = v.begin(); it != v.end(); ++it) {
        it->doSomething();
     }

ou encore plus simplement en C++11 :

    for (auto & element : v) {
        element.doSomething ();
    }

La raison est la suivante. J'écris des programmes où la performance est primordiale ce qui passe entre autre par une utilisation optimale du cache des processeurs. Prenons l'exemple d'un simulateur d'écoulement de fluide où chaque cellule (imagine qu'il y a souvent 100 000 000 cellules) à des propriétés de pression, température, densité, composition, etc. On peut facilement avoir une vingtaine de paramètres. On peut utiliser une structure de donnée qui consiste à déclarer :

    struct State {
        double pressure;
        double temperature;
        ...
        double density;
        ...
    }

et utiliser un std::vector< State > v(100 000 000). Avec une telle structure de donnée, on pourra effectivement utiliser les itérateurs. Seulement, il arrive souvent qu'on doive traverser le tableau et ne récupérer que des informations liées à la pression et la densité par exemple. Une ligne de cache fait 64 octets sur un x86-64 alors qu'un double ne fait que 8 octets. Si pressure et density ne sont pas dans la même ligne de cache, le processeur va devoir à chaque fois charger des lignes de cache pour n'utiliser qu'un huitième de l'information disponible. Le perte de performance est donc énorme.

Une autre méthode consiste à déclarer

    struct StateVector {
       int n;
       std::vector<double> pressure;
       std::vector<double> temperature;
       ...
       std::vector<double> density;
       ...
    }

où tous ces vecteurs ont la même longueur n, à savoir le nombre de cellules. Si maintenant, on veut faire une boucle pour n'utiliser que la pression et la density, on fait

    for (int k = 0; k < state_vector.n; ++k) {
       ...(quelque chose avec state_vector.pressure[k] et state_vector.density[k])...
    }

L'avantage est que tout ce qui est chargé dans le cache est utilisé. Si le programme est limité par la bande passante, il peut dans ce cas être 8 fois plus rapide, ce qui est non négligeable. Maintenant, avec une telle structure de donnée, je ne vois pas comment on fait avec des itérateurs. Les index restent donc très utiles pour beaucoup de personnes.

Si tu souhaites te renseigner, cette méthode qui consiste à utiliser des "struct of arrays" au lieu d'"arrays of structs" est une des bases de ce qu'on appelle le Data Oriented Design. Mike Acton qui s'occupe de jeux vidéos est une des personnes qui passe le plus de temps à expliquer cela. Voici une de ses conférences : https://www.youtube.com/watch?v=rX0ItVEVjHc .

Tout cela pour dire, que non, je souffre pas d'un problème d'incompétence sur les itérateurs; j'ai seulement des besoins de performance et des solutions où les itérateurs ne peuvent pas être utilisés. Si tu as des arguments solides pour dire que l'utilisation d'entiers non signés pour indexer les tableaux est une bonne idée, prends ta plume et va écrire à Bjarne Stroustrup et Herb Sutter. Au passage, tu peux aussi écrire à Scott Meyer qui mettait déjà en garde la communauté C++ en 1995 sur les risques des entiers non signés : http://www.aristeia.com/Papers/C++ReportColumns/sep95.pdf . Il n'a malheureusement pas été entendu.