Discussion :

[nonozor]

Bonjour,

J'ai un code qui ressemble à

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
{
  int NbChaussettes = ...
  blablabla
}
{
  int NbPantalons = ...
  blablabla
}
{
  int NbChemises = ...
  blablabla
}
{
  int NbChaussures = ...
  blablabla
}

Il n'a donc jamais plus d'un int déclaré, visible et utilisable en même temps.

Est ce que quelqu'un saurait si la place utilisée dans la mémoire du programme pour ces variables est de 4 int ou de 1 int?
Merci pour vos réponses!

[Mac LAK]

Est ce que quelqu'un saurait si la place utilisée dans la mémoire du programme pour ces variables est de 4 int ou de 1 int?

Cela peut dépendre du compilateur...

Pour vérifier, dans chaque bloc { }, affiche sur la console l'adresse de la variable. Si les quatre entiers ont la même, c'est que ton compilateur n'alloue qu'un seul entier sur la pile. S'ils sont différents, c'est qu'il alloue séparément chaque variable, même si elles sont dans des portées disjointes.

[3DArchi]

Salut,
Le langage te garantie que le constructeur est appelé à la définition de la variable et le destructeur est appelé lorsque celle-ci sort de son scope.
En revanche, la gestion de la pile dépend du compilateur et de la taille de la variable :

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
#include <iostream>
 
template<int N>
void Dump()
{
   {
     int NbChaussettes[N];
     std::cout<<NbChaussettes<<std::endl;
   }
   {
     int NbPantalons[N];
     std::cout<<NbPantalons<<std::endl;
   }
   {
     int NbChemises[N];
     std::cout<<NbChemises<<std::endl;
   }
   {
     int NbChaussures[N];
     std::cout<<NbChaussures<<std::endl;
   }
}
int main()
{
   std::cout<<"1 : "<<std::endl;
   Dump<1>();
   std::cout<<"1024 : "<<std::endl;
   Dump<1024>();
   return 0;
}

Produit avec Visual C++ :

1 :
0012FF5C
0012FF58
0012FF54
0012FF50
1024 :
0012EF60
0012DF60
0012CF60
0012BF60

-> On voit qu'on a une zone différente sur la pile à chaque fois.
Et avec MinGW :

1 :
0x22ff54
0x22ff50
0x22ff4c
0x22ff48
1024 :
0x22ef58
0x22ef58
0x22ef58
0x22ef58

-> On voit qu'on a une zone différente sur la pile pour 1 et la même pour 1024.

[Mac LAK]

@3DArchi : tu as fait le test en Debug, en Release, les deux ? Juste pour savoir... Parce que ça ne m'étonnerait pas que Visual ne "compacte" les grosses variables qu'en mode Release, à cause notamment des valeurs de remplissages en mode Debug...

[3DArchi]

@3DArchi : tu as fait le test en Debug, en Release, les deux ? Juste pour savoir... Parce que ça ne m'étonnerait pas que Visual ne "compacte" les grosses variables qu'en mode Release, à cause notamment des valeurs de remplissages en mode Debug...

Le test est en debug. Effectivement, il y a peut être un compactage en Release. L'idée est surtout de montrer qu'il s'agit d'un choix d'implémentation et qu'il vaut mieux ne pas spéculer sur la façon dont la pile est gérée.

[Mac LAK]

Le test est en debug. Effectivement, il y a peut être un compactage en Release.

OK, merci.

L'idée est surtout de montrer qu'il s'agit d'un choix d'implémentation et qu'il vaut mieux ne pas spéculer sur la façon dont la pile est gérée.

Ah ça, on est bien d'accord !!!
La seule chose garantie avec les variables locales, c'est ... qu'elles sont sur la pile. Mais la façon dont c'est implémenté ne devrait jamais être une hypothèse de travail.

[gl]

La seule chose garantie avec les variables locales, c'est ... qu'elles sont sur la pile.

Même pas, il n'y a pas de notion de pile dans la norme. La seule chose dont on est certain c'est de la portée des variables locales.

[HS]
J'ai travaillé sur des systèmes où les variables locales étaient mise dans la même page de working data que les variables globales, le compilateur et le linker se débrouillaient pour les organiser correctement et pour recycler les zones mémoires des variables locales (pas assez de place dans la pile).

De même, à fin d'optimisation, certaines variables locales ne peuvent n'être présente que dans les registres du processeurs.
[/HS]

[Mac LAK]

De même, à fin d'optimisation, certaines variables locales ne peuvent n'être présente que dans les registres du processeurs.

Je réponds "à l'envers", mais ce point me semble crucial : l'optimisation est un cas à part, vu qu'elle est capable d'aller jusqu'à déplacer du code en dehors de l'endroit où il a été conçu pour être exécuté...
Alors déplacer une variable locale dans un registre exclusivement ne va pas lui faire peur, c'est évident.

Même pas, il n'y a pas de notion de pile dans la norme. La seule chose dont on est certain c'est de la portée des variables locales.

Il me semble bien pourtant que la norme décrit la convention d'appel, en parlant explicitement d'empilage des paramètres...
Bon, ensuite, c'est vrai que ça dépend beaucoup des processeurs et de l'optimisation : sur x86 il n'y a pas trop le choix alors que sur SPARC il y a bien plus de registres, tout comme sous PowerPC.

J'ai travaillé sur des systèmes où les variables locales étaient mise dans la même page de working data que les variables globales, le compilateur et le linker se débrouillaient pour les organiser correctement et pour recycler les zones mémoires des variables locales (pas assez de place dans la pile).

Cas particuliers, ça, ça ressemble à certains hacks crades des compilateurs C pour microcontrôleurs... Toutefois, ces compilateurs respectent rarement la norme C, ou respectent celle d'il y a 20 ans.


Ce qui ne change pas le fond du problème : ne pas présupposer comment sont gérées les variables locales...

[gl]

Ce qui ne change pas le fond du problème : ne pas présupposer comment sont gérées les variables locales...

Certes non, j'aurais même plutôt tendance à dire que ça conforte ce point de vue.

[nonozor]

Certes non, j'aurais même plutôt tendance à dire que ça conforte ce point de vue.

D'accord. Merci pour toutes vos réponses!

Cependant, si les variables sont des tableaux vraiment trop gros (par exemple, relatifs à un maillage avec plusieurs millions de points) et qu'elles ont chacune une place différente dans la mémoire, il vaut mieux réutiliser le même tableau dans chaque bloc plutôt que d'utiliser un tableau différent par bloc.

Je me dit que dans le cas des gros tableaux, la plupart des compilos vont être assez gentils pour optimiser et utiliser la même place mémoire à chaque fois. Etes vous d'accord?

[koala01]

Salut,

D'accord. Merci pour toutes vos réponses!

Cependant, si les variables sont des tableaux vraiment trop gros (par exemple, relatifs à un maillage avec plusieurs millions de points) et qu'elles ont chacune une place différente dans la mémoire, il vaut mieux réutiliser le même tableau dans chaque bloc plutôt que d'utiliser un tableau différent par bloc.

Je me dit que dans le cas des gros tableaux, la plupart des compilos vont être assez gentils pour optimiser et utiliser la même place mémoire à chaque fois. Etes vous d'accord?

Dans le cas de tableaux et de structures complexes de manière général il est souvent intéressant de les créer à un endroit et, de là à les passer en paramètre (sous la forme d'une référence, constante ou non) aux différentes fonctions.

Quand ce n'est pas, carrément envisager de faire en sorte que la données et la fonction qui la gère fasse partie d'une même structure.

Le problème principal n'est en effet pas forcément l'adresse mémoire à laquelle va se trouver la donnée mais la perte d'espace et de temps qui peut résulter des différentes copies et création du tableau ou de la structure complexe

En évitant au maximum les créations et les copies inutiles, tu optimisera ton code de manière très significative et à tous points de vue

[Goten]

D'accord. Merci pour toutes vos réponses!

Cependant, si les variables sont des tableaux vraiment trop gros (par exemple, relatifs à un maillage avec plusieurs millions de points) et qu'elles ont chacune une place différente dans la mémoire, il vaut mieux réutiliser le même tableau dans chaque bloc plutôt que d'utiliser un tableau différent par bloc.

Je me dit que dans le cas des gros tableaux, la plupart des compilos vont être assez gentils pour optimiser et utiliser la même place mémoire à chaque fois. Etes vous d'accord?

Ca dépend de ce que t'appelle un tableau... Un tableau C-like alloué statiquement (ça m'étonnerai ... tu ferais péter la pile avant), alors dynamiquement? un vector?

[Mac LAK]

Si tu déclares dans ta fonction un truc du genre "int bourrin[999999999]", t'as plus de chances de faire exploser la pile que quoi que ce soit d'autre.

Après, si c'est une allocation dynamique, c'est sur le tas et non pas la pile, reste à voir si le compilateur est assez rusé pour allouer sur le tas tout tableau LOCAL trop gros pour la pile... Franchement, j'y crois pas trop pour ma part...

[nonozor]

Merci à tous pour vos réponses!

Le problème principal n'est en effet pas forcément l'adresse mémoire à laquelle va se trouver la donnée mais la perte d'espace et de temps qui peut résulter des différentes copies et création du tableau ou de la structure complexe

Est que le temps pour créer un tableau sur la pile n'est pas négligeable, puisqu'il suffit de laisser un espace qui lui est réservé quand on empile la fonction qui le contient dans la callstack?

Un tableau C-like alloué statiquement (ça m'étonnerai ... tu ferais péter la pile avant)

Si mon maillage fait 4 millions de points, le tableau qui contient des infos associées à chaque points fera environ 4 millions d'octets, soit 4Mo. Ca ne pète pas la pile, si?

[Mac LAK]

Est que le temps pour créer un tableau sur la pile n'est pas négligeable, puisqu'il suffit de laisser un espace qui lui est réservé quand on empile la fonction qui le contient dans la callstack?

Et tu utilises souvent des variables non-initialisées ?
Monsieur aime le risque... J'aime...
Plus sérieusement, ça, c'est des queues de cerise côté optimisation... Avant que tu ne puisse en voir l'effet, va te falloir des calculs plus qu'intensifs, et tu gagneras sûrement cent ou mille fois plus de temps en implémentant un algo ayant une complexité moins élevée...

Si mon maillage fait 4 millions de points, le tableau qui contient des infos associées à chaque points fera environ 4 millions d'octets, soit 4Mo. Ca ne pète pas la pile, si?

Si, la pile est justement de 4 Mo maximum en général sous Windows (et d'environ un méga minimum)...
De plus, ça m'étonnerait qu'un point de ton maillage ne fasse qu'un seul octet, mais plutôt au moins 8 octets (deux coordonnées entières, ça me parait le minimum, non ?)... C'est donc 32 Mo qui seraient alloués.
A ce stade, une allocation dynamique (éventuellement dépendante de l'OS, par exemple LocalAlloc sous Windows est très rapide) est bien préférable, et de très loin.

Tu trouveras quelques compléments d'information sur ce topic.

[koala01]

Imaginons que tu aies une structure toute simple:

Code :

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

1
2
3
4
5
struct point
{
    int x;
    int y;
};

Cette structure utilise une place en mémoire égale à 2*sizeof(int) et qui correspond, sur les implémentations classiques, à la taille de 8 caractères

si tu en viens, dans une fonction, à déclarer un tableau proche de

Code :

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

1
2
3
4
void foo()
{
    point tab[1000000];
}

Tu va donc réserver sur la pile (pour autant qu'elle l'accepte, ce qui n'est pas forcément acquis) l'espace nécessaire à la représentation contigüe de 8 000 000 de caractères.

Mais, ces 8 000 000 de caractères ont des valeurs qui correspondent... aux crasses laissées par l'utilisation antérieure de la mémoire.

Tu ne peux donc pas envisager décemment d'utiliser ton million de points sans, au minimum, veiller à ce qu'ils aient des valeurs cohérentes (et de préférence même des valeurs correspondant au maillage que tu veux représenter)...

Il te faudra donc, au minimum, initialiser les x et y de ton million de point à une valeur "par défaut", au pire, lire les valeurs dans un fichier de données.

Et cela, à chaque fois que tu passera dans la fonction.

La version utilisant de l'allocation dynamique n'est qu'à peine mieux:

Code :

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

1
2
3
4
5
 
void bar()
{
    point * tab=new point[1000000];
}

car elle allouera la mémoire sur le tas (ce qui est déjà une bonne chose) l'espace nécessaire pour contenir ton million de point, mais appellera également un million de fois le constructeur par défaut de point (une fois pour chaque point à placer dans le tableau)...

Et si tu n'as pas défini de constructeur par défaut, le compilateur en rajoutera un qui initialise x et y à 0, mais il sera toujours appelé un million de fois...

Bien que ta situation de départ soit un peu meilleure, tu devra donc, encore, envisager de donner les valeurs adéquates à tes points pour représenter ton maillage

Et ce, lors de chaque appel de la fonction.

(il ne faudra, en outre, pas oublier de libérer correctement la mémoire allouée par new avant de quitter la fonction, sous peine d'avoir une fuite mémoire catastrophique)

Tout cela devrait t'amener à prendre conscience que, si tu dois attendre, à chaque appel de foo ou de bar, qu'elles aient donné les valeurs correctes à ton maillage, ton application sera un véritable escargot, et ce, d'autant plus que foo ou bar seront appelées souvent

La solution passe donc bel et bien par le passage d'arguments:

Tu crée une seule fois ton tableau d'un million de point, de la manière que tu désire (mais de préférence de manière dynamique), et tu le passe en argument à foo, bar ou à toute fonction qui utilise ton maillage.

Soit tu estimes dans la fonction qu'il donner les valeurs à ton maillage, et tu décide alors de lire un fichier ou un flux avant de commencer à travailler, soit tu estimes que le tableau permet de représenter le maillage à analyser, et tu travaille directement sur les points qu'il contient

L'énorme avantage supplémentaire est que tu ne passera, en définitive que l'adresse du premier élément, c'est à dire une variable nécessitant très peu d'espace mémoire pour être représentée

Cela limitera grandement le risque d'arriver dans une situation de stack overflow

[3DArchi]

Si mon maillage fait 4 millions de points, le tableau qui contient des infos associées à chaque points fera environ 4 millions d'octets, soit 4Mo. Ca ne pète pas la pile, si?

Bonjour, avec de telles dimensions, je ne prend pas ce risque. Il y a de forte chance que ta pile explose. Plutôt qu'une gestion dynamique, as-tu pensé à std::vector ?

[koala01]

Bonjour, avec de telles dimensions, je ne prend pas ce risque. Il y a de forte chance que ta pile explose. Plutôt qu'une gestion dynamique, as-tu pensé à std::vector ?

Ca aussi, un std::vector sera surement plus intéressant que l'allocation dynamique manuelle...

Mais, encore une fois, si ton maillage doit être reconstruit à chaque appel de la fonction, tu va perdre un temps bête rien que pour la construction