Discussion :

[Kaluza]

Bonjour à tous .

Pour un projet qui s'interface avec du Fortran 90/95, j'aurai besoin d'utiliser des tableaux/vecteurs de très (très) grande taille dans le contexte de simulations scientifiques (des milliards d'éléments). Je me demandais ce qu'il était préférable d'utiliser. Je précise que le but n'est pas d'effectuer des opérations matricielles, mais plutôt de stocker énormément d'informations et de faire tourner des algos de tris et ce genre de chose.

Comme j'ai besoin d'un truc très stable et viable à long terme, existe-t-il quelque chose de faisable en C/C++/C++1x ? Sinon y a-t-il des biblio indépendantes ou des parties de boost (je viens juste de me mettre à boost) qui soient dédiées à ce genre de chose ?

Merci beaucoup

P.S. : aucun rapport (mais un peu quand même) : est-il prévu à long terme que des choses comme uBlas soient intégrées aux futurs standards de C++ ?

[Feriaman]

Bonjour,

Je ne sais pas répondre à la question telle qu'elle est posée, car il me manque pas mal d'éléments d'information. Je vais te poser les éléments que j'ai et tu "construira" ta réponse

En général quand tu t’interface avec "le monde extérieur", tu n'as pas le choix du format des données d'entrée, c'est forcément flux de données brutes, autrement dit : du texte ou des tableaux de type simple.
En l'occurrence je pense que ce sera des tableaux de types simple.

La question de la façon dont tu reçoit les données est importante :

• Les reçois-tu en une fois (un appel à ton programme avec toutes les données) ?
• Peux-tu les recevoir en plusieurs fois (un fichier que tu lis, une BDD, ton programme qui appelle le code fortran pour lui demander tel ou tel élément... ) ?

Le volume des données aussi est important :

• s'il rentre en mémoire 2 fois, tu as de la marge de manœuvre : tu peux récupérer les données brutes, puis construire un modèle objet à partir de cela. Jeter tes données brutes (*), puis travailler avec ton modèle.
• s'il rentre en mémoire, mais une seule fois, là c'est plus compliqué, tu es coincé avec tes données brutes, sauf si tu arrives à les lire en plusieurs fois, auquel cas tu peux construire un modèle objet en étant pointu sur la façon dont tu charges les données.
• s'il ne rentre pas du tout dans la mémoire, ça veut dire que tu vas être obligé de le lire morceau par morceau (si ce n'est pas possible non-plus tu es coincé). Tu pourras quand même construire un modèle objet, mais en t'appuyant sur une couche de persistance qui gère ce qu'elle charge et décharge (donc en terme de perfs, tu en prends plein la vue).

Je dirais que l'idéal (dans ma vision très OO des choses) serait de construire un modèle objet. A ce moment-là tu pourra utiliser des conteneurs, des visiteurs, des algos de la stl, boost ...

Si tu es coincé avec les données brutes, tu ne peux pas utiliser d'objets, sauf à construire des objets qui ne porteraient aucune info, mais référenceraient les données brutes (*2). Ceci me semble déjà plus difficile et je ne sais pas s'il existe des bibliothèques conteneurs de ce type, il faudrait sans doute les fabriquer.

Autre possibilité si tu es coincé avec les données brutes: tu reste avec tes données brutes et tu fais du Fortran en C++, mais à ce moment-là tu n'as pas le choix du format : ce sera forcément les tableaux d'objets simples. J'ajoute que si tu es dans cette situation, le gain du passage de FORTRAN à C++ n'est pas aussi important que dans les autres cas.

(*) : réflexion faite, ce n'est pas évident qu'il soit possible de libérer la mémoire associée aux paramètres d'entrée d'un programme. En tout cas je ne sais pas faire, peut-être en utilisant deux programmes dont un tampon ?

(*2) : et encore il faut étudier le poids de ces références, si tes "éléments" sont de petites taille : un ou deux octets, c'est râpé

Courage.

[tomayo]

Effectivement, la premiere chose qu'on devrait savoir c'est ce que contiennent tes vecteurs. A priori, des types scalaires genre int/float/double vu que c'est pour du fortran? Tu va t'orienter vers du std::vector si la taille n'est pas fixe a la compilation ou doit changer au cours de l'exe, sinon prend du std::array (mmm teste avant vu que c'est du C++1x -- sinon tape dans le boost::array qui est idem). Le point cle pour interfacer facilement avec du fortran c'est que ton conteneur soit compatible avec de la conversion en double* (i.e en gros un bloc contigu de memoire). vector et array sont ok pour ca. De plus, si jamais tu t'entends dire que les std::vector sont nuls pour le scientifique, ecoute d'une oreille discrete! Tout depend de la taille et de l'utilisation. Pour toi (grande taille, operations de gestion genre tri, affectation, copie), du std::vector est tres bon. Optionnellement, tu pourras mettre en place "a la main" des optims simples sur des ope comme la copie, l'egalite, les operations arithmetiques pour augmenter les performances. Par contre, gaffe a un truc avec le std::vector: gere bien les allocs avec vector.reserve et vector.capacity pour etre tjr sur que l'alignement des donnees est contigu.
Bon courage

[tomayo]

Au fait, pour ta question sur blas, sans etre dans le comittee C++ , il est assez sur qu'a terme ca sera integre ne serait-ce que parce que boost l'implemente deja et que le scientifique reste un domaine d'application dans lequel le C++ est de plus en plus present.
Neanmoins, a mon sens, le probleme n'est pas vraiment d'integrer blas (tu peux le faire toi meme ou prendre boost::uBlas) mais de le faire de maniere a assurer de la performance. Et la dessus, personne ne sait quelles ameliorations pourront etre apporter sur le core du C++ pour rivaliser avec du fortran. C'est ca le challenge car le C++ est a la bourre sur le fortran de ce cote la. Prix a payer pour avoir un langage de plus haut niveau