Discussion :

[oxyde356]

Bonjour à tous et à toutes,
Non je ne vais pas poser la question noobienne que beaucoup ne doivent plus supporter c'est à dire quelle est la différence entre mémoire statique et dynamique
Non ma question est : que se passe-t-il au niveau de la mémoire quand je créé une classe Engine qui va être la classe de plus au niveau et qui va gérer énormément d'autres classes (enfin leur instance), enfaite tout mon programme.
Et que l'instance de cette classe est créé dynamiquement ?
Donc un truc du genre Engine* pEngine = new Engine();
Est-ce une catastrophe qui va faire que tout ce qui va en découler sera de la mémoire dynamique (je suppose que oui) et donc sera plus difficile a gérer par l'application ou bien est-ce que ça n'a pas vraiment d'importance ?
Si quelqu'un pouvait me donner de petits détails sur les performances read/write sur la mémoire statique et dynamique aussi, je veux rien de précis mais plutôt un comparatif entre les deux ^^
Merci beaucoup

[ram-0000]

A mon avis, quand le programme s'exécute, ce que tu appelles mémoire statique ou mémoire dynamique (je pense que ce n'est pas les mots qu'il faudrait employer mais je ne sais pas quoi te proposer), tout cela c'est en RAM et donc les temps d'accès et les performances sont les mêmes.

A moins que tu veuilles parler des différences "mémoire ROM" versus "mémoire RAM"

[Florian Goo]

A mon avis, quand le programme s'exécute, ce que tu appelles mémoire statique ou mémoire dynamique (je pense que ce n'est pas les mots qu'il faudrait employer mais je ne sais pas quoi te proposer)

Je dirais pile et tas, respectivement

[Florian Goo]

Est-ce une catastrophe qui va faire que tout ce qui va en découler sera de la mémoire dynamique

En effet, mais ce n'est pas si catastrophique !

et donc sera plus difficile a gérer par l'application ou bien est-ce que ça n'a pas vraiment d'importance ?

Un peu plus lent, oui.

Si quelqu'un pouvait me donner de petits détails sur les performances read/write sur la mémoire statique et dynamique aussi, je veux rien de précis mais plutôt un comparatif entre les deux ^^

Je pense que cet article répondra à beaucoup de tes questions !
http://fr.wikipedia.org/wiki/Allocation_de_mémoire

[oxyde356]

Oui je parlais bien du pile et du tas.
Merci beaucoup pour vos réponses sa m'a bien éclairer, enfaite j'ai fini de faire un petit jeu bomberman, avec menus, transitions, campagne solo avec IA, multi et un code somme toute bien structuré il me semble.
Et je me demandais si j'aurais pas l'air d'une tache en le publiant, si ma classe principale était foireuse ou plutôt non standard enfin bref vous m'avez compris ^^
Enfaite je voulais que mon unique instanciation du moteur soit la seule variable global de mon programme et je n'y arrivais pas en créant mon instance sur la pile. Alors j'ai créé un pointeur pour mon moteur en global et puis j'ai simplement fait un new dans mon main. Enfaite j'ai trouvé une solution plus approprié je pense, en tout cas sa marche m'enfin sa encore heureux lol.
J'ai créée un pointeur global de type Engine(*) et je le fais pointé sur l'instance qui est créée sur la pile dans le main. Comme sa rien n'ai créé sur le tas enfin dans cette partie là.
Qu'est ce que vous pensez de cette solution ?

Dans un autre de mes moteurs (en DirectX cette fois m'enfin sa change rien) au lieu de créer une variable/pointeur global j'ai instancié un objet Engine dans mon main et je le propage à toutes les objets membres.
Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
class Engine
{
   Voiture A;
   Explosion B;
  ...
 
  void Framemove() {A.Framemove(this); B.Framemove(this);};
  ...
};

Que pensez-vous de cette autre solution ?
Pour vous quelle est la meilleur des deux ?

Et enfin est-ce que vous auriez des exemples de structures de jeux vidéos "professionnels". Je sais qu'il n'y a pas une solution meilleur que toute mais j'aimerai bien savoir a quoi ressemble une vrai structure d'un vrai jeu.

Merci à tous

[Klaim]

Hmmm ça me rapelle la fois ou dans un jeu on avait un objet représentant le jeu (ou plutot gérant l'état général du jeu) comme ici, et il était déclaré sur la pile...

Code :

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

1
2
3
4
5
6
 
int main()
{
        Application application;
        return application.run();
}

... et a force d'ajouter des membres dans la classe Application (par exemple des managers des différentes parties du jeu), on a dépassé la mémoire réservée à la pile (sur console, c'est assez facile...et provoque souvent des erreurs pas claires du tout).

Du coup, on a changé.

Code :

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

1
2
3
4
5
6
7
8
 
int main()
{
        Application* application = new Application;
        int result = application->run();
        delete application;
        return result;
}

La taille de l'objet est a prendre en considération dans ce genre de choix.

[oxyde356]

Hmmm ça me rapelle la fois ou dans un jeu on avait un objet représentant le jeu (ou plutot gérant l'état général du jeu) comme ici, et il était déclaré sur le tas...

Code :

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

1
2
3
4
5
6
 
int main()
{
        Application application;
        return application.run();
}

Tu veux dire sur la pile dans ce cas la non ?

Et puis quand le programme se démarre, sa pile ne peut-elle pas prendre toute la ram libre ?
Je ne vois pas trop pourquoi tu as eu un dépassement de mémoire, peux-tu expliciter s'il te plait ?
Merci

[Klaim]

Oups, erreur de traduction de ma part, tu as raison - corrigé

[oxyde356]

D'accord mais pourquoi la pile ne peut pas être aussi grande que le tas ? Parce qu'elle doit être contigu ?
Parce que il y a + de mémoire allouée pour le tas que pour la pile par le système d'exploitation ?
Merci

[Médinoc]

Je dirais les deux.
Bien sur, sous les systèmes d'exploitation modernes, chaque processus peut avoir sa pile sans se soucier du mappage physique, du moment que la mémoire lui apparait contigüe dans ses 2Go inférieurs de mémoire virtuelle (sous Windows, les 2Go supérieurs sont réservés au kernel). Et bien que la pile fasse par défaut 1Mo sous Windows, il est évidemment possible de l'agrandir.

Mais traditionnellement, on met le moins possible dans la pile et le plus possible dans le tas. Ce qui a l'avantage de réduire la vulnérabilité des logiciels aux attaques par dépassement de tampon, qui se font typiquement avec des tampons dans la pile.

[nicroman]

D'accord mais pourquoi la pile ne peut pas être aussi grande que le tas ? Parce qu'elle doit être contigu ?
Parce que il y a + de mémoire allouée pour le tas que pour la pile par le système d'exploitation ?
Merci

C'est surtout que, traditionellement, la pile n'est pas redimensionnable à souhait... et que du coup, par défaut, un OS n'alloue que très peu à une pile d'execution.

Prenons un exemple simple: j'ai en cours d'execution, 79 processes qui utilisent 1130 threads. Si on alloue 1Mo à chaque thread (ou fiber), ca donne déjà 1Go d'utilisé !!!! Donc par défaut la pile allouée aux threads doit être *vraiment* petite. D'ailleurs, elle ne contient, en général, que des variables temporaires d'execution, et la plupart du temps, on n'accède que très peu aux variables des contextes d'appel(s) précédant(s).

Pour ton cas précis, et contrairement à ce qui a été dit, l'allocation d'un "engine" dans la pile ou le tas ne fait absoluement aucune différence de rapidité... Cet objet est en général créé une seule fois au démarrage (et on n'est pas à quelques ns pret à ce moment là) et détruit quand on quitte l'application. Comme il est appellé environ 1 million de fois par seconde (bon j'exagère un peu... mais à peine), je suis prêt à parier qu'il sera en cache L2 de toute manière.

[oxyde356]

Effectivement cette histoire de taille par défaut de la pile ne concerne pas mon programme.
Si la pile doit être contigu (quelqu'un en est sûr ?) je pencherai plutôt pour le tas, histoire que même dans les toutes petites configs disposant de peu de mémoire (qui plus est fragmenté) le programme puisse se lancer, s'il n'y a pas de différence de performances notable.
Après je sais pas, il faudrait faire un sondage Qui est pour la pile, qui est pour le tas et pourquoi ? ^^
Par contre vu que le tas risque à 99% d'être fragmenté c'est des accès mémoires en plus je suppose ? donc moins performant.
Il faut aussi que je vous informe que la plupart des membres de la classe Engine sont des pointeurs que je fais pointé sur de la mémoire allouée sur le tas. Donc au final Engine ne contiendra pas d'objets membres vraiment lourds, m'enfin c'est toujours possible on sait jamais .
Ok je chipote m'enfin j'aimerais vraiment trouver le plus performant
Alors si vous avez des idées sur lequel est le plus performant dans mon cas, n'hésitez pas a alimenter ce topic sa m'instruit beaucoup merci à vous

[ram-0000]

Si la pile doit être contigu (quelqu'un en est sûr ?)

Heu oui, c'est sûr sinon, cela ne marcherai pas lors des retours de fonction

Par contre vu que le tas risque à 99% d'être fragmenté c'est des accès mémoires en plus je suppose ? donc moins performant.

NON, le temps d'allocation est plus long, cela c'est sûr. Le malloc/new doit locker et parcourir le tas à la recherche d'un bloc libre et suffisant, c'est du temps de calcul. Mais une fois le bloc alloué dans le tas, le temps d'accès est strictement le même que sur la pile, c'est de la RAM.

[wiztricks]

Si les données ont la même durée de vie que l'application, on peut aussi les allouer "statiquement".

Code :

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

1
2
3
4
5
6
 
Application application;
int main()
{
        return application.run();
}

Pour faire simple la mémoire utilisée peut être divisée en zones

• statique: le code et les données statiques
• pile: le contexte d'exécution
• tas: ce qui pourra être alloué dynamiquement

La mémoire disponible est généralement considéré comme un espace contigu dont les zones seront dimensionnées lors de l'activation. Lorsqu'on a fini de charger code et données statique, on sait ou pourra commencer la pile. Mais si on ne donne pas de limite à la taille de cette pile, impossible de savoir ou commencera le tas.
=> en général il est possible d'augmenter la taille de la pile "par défaut" et si cela ne suffit pas, il est toujours possible de construire sa propre pile "dans le tas".
La

[Florian Goo]

Si la pile doit être contigu (quelqu'un en est sûr ?)

Ne te pose pas tant de questions ! On dit qu'en C++ il faut gérer la mémoire manuellement, mais bon, faut pas déconner, on est pas en assembleur non-plus… le langage fait beaucoup de choses par lui-même.

[wiztricks]

Si les données ont la même durée de vie que l'application, on peut aussi les allouer "statiquement".

Code :

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

1
2
3
4
5
6
 
Application application;
int main()
{
        return application.run();
}

Pour faire simple la mémoire utilisée peut être divisée en zones

• statique: le code et les données statiques
• pile: le contexte d'exécution
• tas: ce qui pourra être alloué dynamiquement

La mémoire disponible est généralement considéré comme un espace contigu dont les zones seront dimensionnées lors de l'activation. Lorsqu'on a fini de charger code et données statique, on sait ou pourra commencer la pile. Mais si on ne donne pas de limite à la taille de cette pile, impossible de savoir ou commencera le tas.
=> en général il est possible d'augmenter la taille de la pile "par défaut" et si cela ne suffit pas, il est toujours possible de construire sa propre pile "dans le tas".

Historiquement, la pile est "contigue". Cela permet de supporter les appels de fonction "call/return" qui côté machine se traduisent par empiler/dépiler l'adresse de retour. Comme l'allocation "dans la pile" ne nécessite que l'ajustement du pointeur de pile, on y alloue aussi les variables locales.

=> c'est la raison pour laquelle allouer "sur la pile" est plus performant qu'allouer "dans le tas"

Note: on peut aussi chainer les handlers d'exceptions pour pouvoir retomber sur ses pattes, s'il le faut, en "dépilant" sauvagement... Mais dans ce cas, on est bien embêté par tout ce qui a pu être alloué sur le "tas" sauf si on s'attache à appliquer des patterns de type RAII
-W

[nicroman]

Dans tous les cas... là on parle d'un objet UNIQUE alloué UNE SEULE FOIS au démarrage de l'application.

Si l'objet peut être gros, ou il peut être dynamique (overridable quoi) => new
Si l'objet est statique => static
Si l'objet est tout petit petit => pile


Et non, la taille de la pile n'est pas redimensionable, on peut la modifier à la compilation, mais c'est tout (allez... d'accord, on peut jouer avec le minimum de taille alloué pour le unframe d'exceptions).

[wiztricks]

Et non, la taille de la pile n'est pas redimensionable, on peut la modifier à la compilation, mais c'est tout (allez... d'accord, on peut jouer avec le minimum de taille alloué pour le unframe d'exceptions).

Sous linux, elle peut être modifiée via ulimit.
La primitive BSD/Linux sstk (set stack size) permet de modifier dynamiquement la taille de la pile - mais ne fonctionne que sur certains processeurs -.

Le défaut d'API n'interdit pas de faire sa propre cuisine et de constuire sa pile à partir d'une liste de blocks mémoire alloué sur le tas.
-W

[befalimpertinent]

Dans tous les cas... là on parle d'un objet UNIQUE alloué UNE SEULE FOIS au démarrage de l'application.

Dans ce cas ne devrait-il pas en faire un singleton ? (mémoire statique)

[Médinoc]

Un singleton n'est pas forcément en mémoire statique.
D'ailleurs, l'implémentation conseillée du motif utilise un objet sur le Tas, et seulement un pointeur vers lui stocké en mémoire statique.