Discussion :

[Einde]

Salut à tous.

Bon, toujours dans un problème de lecture de fichiers, j'ai fais le programme suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
jour::jour(string directoryName)
{
    string s = "/mnt/nas02/vista/fredarch/visu/" + directoryName + "t_traj.txt";
    cout << s << endl;
    ifstream file(s.c_str(), ios::in);
    trajectoire t;
    string str;
    vector<string> vec;
    int i=0;
 
    if (!file) //Si le fichier n'est pas lu...
    {
        cerr << "setDataTable : can't read " << directoryName << "." << endl;
        throw std::runtime_error("file not opened: "+ directoryName); //Erreur ! + envoi d'erreur.
    }
 
    string line;
    while (getline(file,line) && i< 100) //Tant qu'on lit des lignes dans le fichier.
    {
        istringstream iss(line);
        cout << i << endl;
        while (getline(iss, str, ' '))
        {
            if (str != "")
            {
                vec.push_back(str);
            }
 
        }
        t.setTrajectory("/mnt/nas02/vista/fredarch/visu/" + directoryName + vec.at(19) + ".txt");
        //cout << vec.at(19) << endl;
        t.setCallSign(atoi(vec.at(4).c_str()));
        traj.push_back(t);
        vec.clear();
        i++;
    }
}

Tout ce petit bazar appartient à une classe "jour", qui n'a qu'en attribut un vector de trajectoires. J'ai déclaré dans un autre fichier une classe trajectoire est une classe qui prends en attribut un vector de points, une chaine de caractères et trois floats juste pour faire un code couleur.

Mon code compile nickel et s'exécute bien, à quelques problèmes près. Rien à signaler jusqu’à ce que j'atteigne 1024 éléments. D'ailleurs si je choisis de ne prendre que les 100 premiers éléments par exemple le programme s'effectue sans soucis. A partir de 1024 éléments (une puissance de 2, comme par hasard), mon PC Debian commence à subir quelques ralentissements. A partir les 2048 éléments (1024 * 2, cooooooomme par hasard) le programme plante et finis par être "tué". Bref, j'ai pensé au début que j'avais juste fait une grosse pompe à CPU, mais on dirait plus au final un problème d'allocation.

Comment puis-je résoudre ce problème ?

Merci d'avance pour votre réponse.

[Bousk]

C'est pas vraiment lié au CPU, c'est plus la RAM. Tu es en train de tuer ta RAM.
vector est pas magique, il assure des données contigues, soit un gros malloc. Il définit une taille, et si tu la dépasses, il en prévoit une plus grande, y copie l'intégralité, puis utilisera ce buffer. Jusqu'à ce qu'il déborde, donc en alloue un autre, etc...
Arrivé à 1024 éléments (ce qui peut déjà être gros), tu débordes. Il en prévoit un plus grand, selon la règle d'agrandissement qu'il utilise. Peut-être 2048 éléments. Mais pendant un court instant tu as les 2 buffers alloués, don cautant de RAM utilisé.

Pour correctement utilisé vector, on reserve la taille nécessaire, puis on push_back les données. Ca évite les réallocations à la volée.

- Pourquoi utiliser vector ?
- Pourquoi pas une list ?

[Luc Hermitte]

Parce que pour si peu d'éléments une liste est généralement beaucoup moins efficace qu'un vecteur.
Et si tu passes ton programme dans vallgrind ou dans le mode sanatize de de clang.

S'il y a des trucs dont je me méfierai, c'est de atoi, et de at().

[Einde]

Bon, du coup j'ai essayé d'allouer mon Vecteur avec la fonction reserve. Mais rien à faire ça plante encore. Par contre je vais pas le nier, y'a une amélioration : au lieu de ralentir à 1024 éléments, je ralentis à 1400 et quelques éléments. Mon programme à planté à 2166 éléments, alors que je suis supposé avoir une capacité de 5290 éléments (taille calculée via une fonction qui compte le nombre de ligne dans un fichier, donc qui retourne un int). Une solution ?

[ternel]

réserve fais la même chose: allouer un nouveau bloc mémoire, et copier dedans.
En interne, que ce soit un push_back ou reserve, il y a probablement appel à realloc().

Une piste serait de passer à une liste, qui n'a pas le problème de contiguité, mais possède un surcout par élément (les deux pointeurs).

Dans ton code, tu n'utilises que les éléments 4 et 19, est-ce réel ou est-ce seulement pour simplifier le code?
Car si c'est le vrai fonctionnement, il est inutile de stocker les éléments suivants (voire même de les lire)

[Einde]

réserve fais la même chose: allouer un nouveau bloc mémoire, et copier dedans.
En interne, que ce soit un push_back ou reserve, il y a probablement appel à realloc().

Une piste serait de passer à une liste, qui n'a pas le problème de contiguité, mais possède un surcout par élément (les deux pointeurs).

Dans ton code, tu n'utilises que les éléments 4 et 19, est-ce réel ou est-ce seulement pour simplifier le code?
Car si c'est le vrai fonctionnement, il est inutile de stocker les éléments suivants (voire même de les lire)

C'est par simplification en ce qui concerne le stockage de 4 et 19. J'ai également essayé de passer par une liste : même soucis. Je pense revenir aux vecteurs, parce que la fonction .at() c'est quand même bien pratique.

J'ai vérifié un peu l'état de ma mémoire, et a priori c'est plus un problème de swap que de code. Faut donc que j'augmente la taille de mon swap (je pense que 8go ça ira). En revanche, je cherche un moyen pour faire en sorte à ce que mon programme se coupe automatiquement à genre 95% d'utilisation du swap, juste histoire d'éviter de faire subir à ma pauvre machine un crash douloureux. C'est mieux que je crée moi même l'arrêt du programme via un bon gros exit() quoi.

Une idée de comment je peux faire ça (a coup de conditionnelles si possible) ?

[stendhal666]

J'ai tout de même un peu de mal à croire que la RAM soit saturée dès l'allocation de 2048 std::string. Même en contigu ça ne pèse pas lourd, une string c'est un pointeur et quelques int.
Le fait qu'il y en ait 1024 à recopier n'est pas un facteur très important non plus, puisqu'il n'y a simultanément en mémoire que: 1 CString (à n'importe quel endroit) et 2 structures std::string (un pointeur et quelques int), pas deux chaînes entières.
En plus, si recourir à une liste n'y change rien, le problème ne doit pas être là puisque les listes permettent de morceler l'allocation mémoire complètement.
A moins que tu aies 512 Ko de RAM

Les problèmes qui correspondent au puissance de deux, c'est normal, le comportement de vector en cas de dépassement c'est d'allouer le double de l'allocation précédente (du coup ça fait log n allocations et on n'alloue jamais plus du double de ce qui est nécessaire).

[Einde]

J'ai tout de même un peu de mal à croire que la RAM soit saturée dès l'allocation de 2048 std::string. Même en contigu ça ne pèse pas lourd, une string c'est un pointeur et quelques int.
Le fait qu'il y en ait 1024 à recopier n'est pas un facteur très important non plus, puisqu'il n'y a simultanément en mémoire que: 1 CString (à n'importe quel endroit) et 2 structures std::string (un pointeur et quelques int), pas deux chaînes entières.
En plus, si recourir à une liste n'y change rien, le problème ne doit pas être là puisque les listes permettent de morceler l'allocation mémoire complètement.
A moins que tu aies 512 Ko de RAM

Les problèmes qui correspondent au puissance de deux, c'est normal, le comportement de vector en cas de dépassement c'est d'allouer le double de l'allocation précédente (du coup ça fait log n allocations et on n'alloue jamais plus du double de ce qui est nécessaire).

Sauf que c'est pas des strings. Ma classe trajectoire c'est un vecteur de points (et un point c'est deux doubles), plus quelques strings. Donc au final ça pèse un peu quand même. C'est pour ça que je vais essayer d'augmenter un peu le swap, tout en cherchant un moyen de couper mon programme sans le crasher quand j'atteins 95% du swap, sinon j'pense pas que la bécane tiendra la semaine.

[stendhal666]

C'est pour ça que je vais essayer d'augmenter un peu le swap, tout en cherchant un moyen de couper mon programme sans le crasher quand j'atteins 95% du swap, sinon j'pense pas que la bécane tiendra la semaine.

Tiens-moi au courant si tu trouves comment faire... Pas sûr qu'il y ait une façon portable de vérifier l'utilisation du swap avant de tenter l'allocation. Est-ce qu'il ne vaut pas mieux simplement prévoir, en cas d'exception bad_alloc, de quitter le programme ou encore mieux, de libérer de la mémoire autant que possible en sérialisant des calculs intermédiaires?

[Iradrille]

Hello,

Çà ne serait pas dû à une fonction récursive ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
void foo(int i) {
	if(!i) {
		return; // 1Go alloué à ce moment (si le vecteur n'est pas supprimé par optimisation)
	}
 
	std::vector<char> v(1024*1024); // 1Mo allouée
	foo(i-1);
}
 
int main() {
	foo(1024);
	return 0;
}

Sinon, essaie de prédire combien de RAM tu utilises.
Un Point c'est 2 doubles (8 x 2 octets) + quelques strings (~100 octets minimum, plus si tes strings sont longs)
Une trajectoire c'est un vecteur de Point (combien ? 10, 100, 1 000, 1 000 000 ?) la taille du vecteur est négligeable par rapport à son contenu (taille du vecteur = nombre de points x taille d'un point) + 3 floats (4 x 3 octets, négligeable) + 1 string (~30 octets mini, négligeable aussi).

Mémoire totale approximative : nombre de trajectoires (5290) x nombre de Points par trajectoire x taille d'un Point.
Si tu ne fais pas de réserve sur ton vecteur de Point (dans trajectoire) multiplie sa taille par 2 (voir 3) dans tes comptes, pareil pour le nombre de trajectoires (et surement pareil pour tes strings, mais j'ai un doute).

Il est aussi possible que tu n’ai pas besoin de tout charger d'un coup.
Si tu dois vraiment travailler sur beaucoup de données (plus que ce que peut contenir ta RAM), STXXL peut être une alternative.

[Luc Hermitte]

Vu la petite structure décrite, si ça plante, ce n'est pas la faute aux vecteurs. Le problème est probablement ailleurs -- ou alors ta machine est véritablement ridicule.
Fais tourner ton programme dans un outil type valgrind, ou compile avec clang+les divers modes sanatize.

PS: at(), c'est de la saleté => on s'en sert quand on ne sait pas où l'on va avec les indices.
PPS: extrait un code minimal et complet qui reproduise ton problème. Là, on parle dans le vide.

[Médinoc]

Je ne suis pas d'accord pour at(), quand quelqu'un est visiblement un débutant, le "fail fast" que ça apporte est indispensable. De plus, c'est très probablement inline, donc un compilo intelligent sait s'en débarrasser quand il n'y en a pas besoin.

Par contre, dans le programme actuel qui implique une une table où l'on accède à des colonnes bien précises (et dont l'indice est hard-codé), une structure avec des vrais champs serait clairement préférable au vecteur.

[Luc Hermitte]

Un compilo classique (gcc 4.4 en -O3 & cie) ne sait pas s'en débarrasser. Je n'ai pas testé les dernières versions, mais tant que l'on n'aura pas de vrai support de la DbC en C++, je crains que les vérifications ne seront pas supprimées.

Ca coute cher. Et pour une fois, je dirai qu'un bon plantage, ça forme aussi. Ceci dit, j'aurai préféré une assertion dans op[]. En attendant, une STL en mode checked est préférable -> -D_GLIBCXX_DEBUG avec gcc. Mieux vaut donner de bonnes habitudes.

[Médinoc]

C'est vrai qu'aussi bien sous Visual que GCC, on a maintenant des options de debug pour faire planter [] tôt.
Mais quand même, j'ai du mal à me débarrasser du sentiment que refuser at(), c'est de l'optimisation prématurée.

[Luc Hermitte]

C'est bien plus de l'optimisation prématurée. C'est de la complexification du programme induite par une programmation défensive. Que faire si la std::logic_error est levée ? Tu rattrapes ? Et après ? On enchaine comment ? On retente ? On espère qu'il n'y a pas de "catch(std::exception const&)" pour avoir un core ? Ce choix implique plein de nouvelles questions. Et il est bien au delà de l'optimisation prématurée.

[Médinoc]

Ah, je vois ce que tu veux dire.

[Einde]

Bon bah voilà, j'ai enfin trouvé comment faire !

J'ai juste tout simplement changé la trajectoire t (déclarée ligne 6) par un pointeur sur trajectoire. Ajoutez bien entendu les modifications sous entendues derrière. Du coup, y'a moins de choses qui surchargent la pile, y'en a plus dans le tas, et au final je pompe à peine 20% de ma RAM.

C'était tellement bête que j'y avais même pas pensé.