Discussion :

[kipgon]

re-bonjour tout le monde,

j'ai une nouvelle question

Je fais un petit programme qui calcul des coordonnées dans l'espace et mon programme plante lorsque le maillage devient trop grand

Quand je dis planter je veux dire que mon ordi n'est pas lent, j'ai immédiatement le message d'erreur "envoyer rapport d'erreur etc..."

Comment éviter cela ?

Vous me direz peut être que c'est logique (question de RAM etc...) mais alors si c'est normal comment font les programmes qui peuvent faire des calculs très lourd tel que Matlab ?

[Neckara]

Bonjour,

Sans un code minimal de ton programme, il nous est difficile de voir les problèmes potentiels de ton code.

[kipgon]

Je peux vous le mettre mais je ne suis pas sur que cela soit très utile puisqu'il marche très bien ... pour un maillage de 50x50, de 100x100 ou de 200x200 mais pour du 500x500 j'ai le droit au rapport d'erreur

c'est pour cela que j'imagine que c'est un problème mémoire mais pour un programme comme Matlab, il ne plante pas, il mouline pendant une demi heure et donne la solution

[therwald]

Euh, ben pour voir où la bât blesse, même si ça marche pour les petites charges, il faut qu'on voie le code, sinon...
A part ça, comment résoudre les problèmes de volumétrie...économiser la mémoire, et ne pas tenter de tout garder en mémoire (sectionner le problème et écrire au fur et à mesure, dans des fichiers temporaires ou dans le fichier définitif...)

[Emmanuel Deloget]

Euh, ben pour voir où la bât blesse, même si ça marche pour les petites charges, il faut qu'on voie le code, sinon...
A part ça, comment résoudre les problèmes de volumétrie...économiser la mémoire, et ne pas tenter de tout garder en mémoire (sectionner le problème et écrire au fur et à mesure, dans des fichiers temporaires ou dans le fichier définitif...)

Je pressent une explosion de la pile. 500x500 entités de X octets allouées sur une pile, on va vite dépasser le Mo généralement réservé pour celle-ci. Le simple fait de stocker un uint32_t va probablement poser un problème. Si les objets stockés dans le tableau on une taille plus importante, ça va poser problème très, très rapidement.

Si ça passe avec 200x200, c'est que les objets font moins de 26 bytes.

Quoi qu'il en soit, quand on a besoin d'une grosse quantité de mémoire comme ça, on ne la prends pas sur la pile : on l'alloue

[kipgon]

Suite à vos conseils j'ai un peu réflechi à mon algorithme et tu avais raison therwald, je déclarais tout sous forme de tableau statique alors que je pouvais tout simplement stocker mes calculs intermédiaires dans quelques variables qui seraient remplacées à chaque itération . Du coup c'est ce que j'ai fais et mon calcul tourne dorénavant pour n'importe quelle valeur de maillage

Merci beaucoup donc

Et sinon n'étant pas programmeur je ne connais pas trop la différence entre prendre la mémoire sur la pile et l'allouer mais je vais me renseigner car cela m’intéresse beaucoup

Merci à tous

[therwald]

Et sinon n'étant pas programmeur je ne connais pas trop la différence entre prendre la mémoire sur la pile et l'allouer mais je vais me renseigner car cela m’intéresse beaucoup

Prendre la mémoire sur la pile:
déclaration de variable locale dite "automatique". Ci-dessous une allocation de tableau qui présente ce défaut cité par Emmanuel Deloget

Code :

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

1
2
 
GrosseClasse tableau[250];

Et là, la même en allocation dynamique:

Code :

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

1
2
3
4
 
GrosseClasse[]* tableau=new GrosseClasse[250];
/*...travail sur le tableau en question...*/
delete[] tableau;

Sachant que toute mémoire allouée par new doit avoir son delete (s'agissant d'un tableau il faut choisir la variante delete[].
L'allocation dynamique est sujette à des erreurs désatreuses ('oubli' du delete, ou 'delete' prématuré qui provoque des plantages ou corruptions de mémoire), mais il existe des structures de données standard pour gérer des stockages dynamiques (ils gèrent pour toi=>moins de risque d'erreur).
Ex: std::vector, ou pour de grosses quantités de mémoire std::list qui trouve plus facilement la mémoire dont il a besoin car il ne cherche pas forcément à tout trouver d'un bloc, contrairement à std::vector.
Dans ce cas la référence de la structure de donnée est prise sur la pile:

Code :

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

std::vector tableau;

, mais comme en interne il réserve dynamiquement sa mémoire de stockage, ne gardant sur la pile que les "références" du tableau (je simplifie) et non les données, il ne surcharge pas la pile.

[therwald]

Arf je m'aperçois que j'ai expliqué l'aspect syntaxique sans expliquer les termes pile vs dynamique.

• la pile <-> la pile d'appel qui mémorise les paramètres de fonctions et les variables locales aux fonctions, dite 'pile' car à chaque niveau d'appel de fonction on crée ("empilage") un nouveau niveau de stockage pour mémoriser les paramètres d'appel et les variables locales. Au retour de fonction on libère le stockage local ("dépilage") et on remonte au niveau de stockage correspondant à la fonction appelante pour retrouver ce qu'on appelle son contexte (les variables qu'elle utilise localement et ses paramètres d'appel).
• Le stockage dynamique fait appel à ce qu'on appelle le 'heap', un autre espace de stockage. Comme je disais précédemment, la gestion à ce niveau se fait manuellement (instruction new ou new[] quand on réserve la mémoire, instruction delete ou delete[] quand on la libère.

La différence entre les deux est que la pile est un stockage de taille limitée et fixe allouée au lancement d'un processus (ou d'une thread mais c'est un autre sujet), alors que le 'heap' fait appel à 'la masse' de la mémoire du système, et peut être agrandi tant que le système d'exploitation accepte de fournir.

[kipgon]

C'est super intéressant, je savais qu'il existait une différence entre stockage statique et stockage dynamique mais j'étais loin de me douter qu'il y avait une telle différence en mémoire .

Pour moi la seule différence qu'il y avait c'était, par exemple dans le cas d'une allocation dynamique, le fait de pouvoir ajouter des cases à un tableau après le lancement d'un programme (par exemple un carnet d'adresse).

Donc en gros pour faire de gros calculs scientifiques (telle que des champs de températures) il vaut mieux opter pour une allocation dynamique même si on connait d'avance le nombre de mailles ?

[therwald]

Donc en gros pour faire de gros calculs scientifiques (telle que des champs de températures) il vaut mieux opter pour une allocation dynamique même si on connait d'avance le nombre de mailles ?

Oui. Par contre, par rapport aux conteneurs de données de la STL on peut faire en sorte de réserver à la création la mémoire nécessaire (fonction reserve) ce qui dans le cas de std::vector par exemple est préférable en termes de perf (sinon, il va agrandir son stockage au fil de l'eau, ce qui résulte en n recopies successives du tableau, avec des impacts en termes de temps d'exécution et aussi en terme de pic de conso mémoire(vu que pour recopier à un moment donné il te faut avoir les deux zones mémoires en même temps))
Et quoi qu'il arrive, sur gros jeux de données il vaut mieux réfléchir à la quantité de mémoire qu'on utilise car en surconsommer peut affecter les performances (swap par ex) ou même faire échouer le calcul (pas assez de mémoire sur le système).