gestion de la mémoire

Bonjour, j'aurais deux questions concernant les variables statiques ou dynamiques.

1)Si j'ai bien compris, la pile (donc l'ensemble des variables statiques, sauf erreur de ma part) est de taille limitée donc il y a le tas (ensemble des variables dynamiques). L'intérêt du tas (ou un intérêt) est qu'il y est de grande taille si bien que l'on peut y mettre toutes nos variables mais malheureusement le temps d'accès à une variable dans le tas est plus grand que celui d'une variable dans la pile. Jusque là ai-je raison ?

2) Si je fais (Species est une structure contenant deux doubles, un char * et deux double * tab[7])

Code:

---

1 2 3

Species ** t1=malloc(3*sizeof(*t1)); Species * t2=malloc(3*sizeof(*t2));

---

alors les tableaux t1 et t2 sont dynamiques (donc dans le tas) et chaque élément de t1 est un Species donc statique et chaque élément de t2 est un Species * donc dynamique donc dans le tas. Est-ce vrai ?

Citation:

---

Envoyé par salseropom

Bonjour, j'aurais deux questions concernant les variables statiques ou dynamiques.

1)Si j'ai bien compris, la pile

---

Le langage C ne définit pas de 'pile'. Il parle éventuellement de mémoire automatique (sous entendu à allocation/libération automatique). Ca concerne les 'variables locales'. La durée de vie est celle du bloc de définition. Idem pour la portée.

http://emmanuel-delahaye.developpez....es.htm#donnees

Citation:

---

(donc l'ensemble des variables statiques, sauf erreur de ma part)

---

La mémoire statique, c'est autre chose. C'est un bloc de donnée de taille connue avant le démarrage du main(). Cette mémoire est allouée / libérée en dehors de toute intervention du programmeur. La durée de vie est >= à celle de l'application.

Citation:

---

est de taille limitée donc il y a le tas (ensemble des variables dynamiques).

---

Admettons...

Citation:

---

L'intérêt du tas (ou un intérêt) est qu'il y est de grande taille si bien que l'on peut y mettre toutes nos variables mais malheureusement le temps d'accès à une variable dans le tas est plus grand que celui d'une variable dans la pile. Jusque là ai-je raison ?

---

Beuh... Le langage C ne dit rien sur les performances. J'imagine que ça doit dépendre de l'implémentation... Faire des mesures.

Citation:

---

2) Si je fais (Species est une structure contenant deux doubles, un char * et deux double * tab[7])

Code:

---

1 2 3

Species ** t1=malloc(3*sizeof(*t1)); Species * t2=malloc(3*sizeof(*t2));

---

alors les tableaux t1 et t2 sont dynamiques (donc dans le tas)

---

Les tableaux pointés par t1 et t2 sont situés en mémoire dynamique, ce que tu appelles le tas ou heap.

Citation:

---

et chaque élément de t1 est un Species donc statique

---

Non. Les éléments de t1 sont des pointeurs définis dans le 'tas', mais non initialisés.

Citation:

---

et chaque élément de t2 est un Species * donc dynamique donc dans le tas. Est-ce vrai ?

---

Oui.

Une raison pourquoi on pourrait dire que l'accès des éléments du tas est plus lent pourrait être:

Pour accéder un élément du tas, il faut passer par une variable locale qui donne l'adresse de cet élément. Sachant la localité du tas par rapport à la pile (ils sont opposés dans la mémoire du processus), il est logique de considérer qu'il faut:

2 accès pour récupérer la valeur de cet élément et donc 2 fois plus de chance de faire un défaut de cache... Ceci peut donc justifier en fait ton permier point...

Pour ton 2ème point, t1 et t2 sont des variables locales donc stockés dans la pile et les éléments pointés sont dans le tas...

Jc

Salut Emmanuel, merci de ces précisions. J'utilisais parfois du vocabulaire du C++. Mais juste une précision : j'avais écrit :

Code:

---

1 2 3

Species ** t1=malloc(3*sizeof(*t1)); Species * t2=malloc(3*sizeof(*t2));

---

t1[0] est un Species * et t2[0] est un Species. Est-ce vrai ? Et que vaut-il mieux faire : le t1 ou le t2 (je parle en terme de temps de calculs et de facilité d'utilisation et de gestion de la mémoire) ?

Merci encore

Je pense que ça revient au même. A confirmer :p

Citation:

---

t1[0] est un Species * et t2[0] est un Species. Est-ce vrai ?

---

C'est vrai.

Citation:

---

Et que vaut-il mieux faire : le t1 ou le t2 (je parle en terme de temps de calculs et de facilité d'utilisation et de gestion de la mémoire) ?

---

En terme de temps de calculs: il faut faire 2 indirections pour t1 et une seule pour t2, à ton avis qu'est-ce qui est plus rapide?

En terme de utilisation/gestion mémoire: ce n'est pas la même chose, t1 représente une double indirection donc potentiellement un tableau à deux dimensions... t2 représente un tableau à une dimension...

De toute façon, en terme d'utilisation mémoire, t1 utilisera toujours plus de mémoire que ta version t2 qui utilisera plus de mémoire que la version t3:

Code:

---

1 2	Species t3[3];

---

Mais on parle d'une différence de quelques octets sauf si tu commence à gerer des centaines et centaines d'éléments...

Jc

ok, merci pour toutes vos précisions. Je vais donc opter pour mon t2

Citation:

---

Envoyé par salseropom

Et que vaut-il mieux faire : le t1 ou le t2 (je parle en terme de temps de calculs et de facilité d'utilisation et de gestion de la mémoire) ?

---

C'est impossible a dire. Il faut faire des mesures sur des programmes equivalents utilisant les deux methodes. La difference est tres certainement faible.
De maniere generale, il ne faut jamais optimiser le code a ce niveau sans savoir ce que l'on fait. Dans ton cas, choisis la notation qui permet de programmer le plus simplement, donc celle qui minimise le nombre d'indirections (le nombre d'etoiles, si tu preferes).
Si tu es/deviens programmeur professionnel, ou scientifique, une heure de ton temps coute plus cher que quelques Hz de temps d'horloge. L'optimisation est alors une perte de temps et d'argent.

Citation:

---

L'optimisation est alors une perte de temps et d'argent.

---

Ca c'est de la conclusion! lol

Citation:

---

Si tu es/deviens programmeur professionnel, ou scientifique, une heure de ton temps coute plus cher que quelques Hz de temps d'horloge. L'optimisation est alors une perte de temps et d'argent.

---

Je trouve:

Citation:

---

Si tu es/deviens un programmeur professionnel, ou scientifique, si tu programmes sans faire attention aux optimisations de base, tu ne garderas pas ton travail tres longtemps....

---

Enfin, je suis peut-etre un peu naif de croire (ou d'esperer) qu'un patron te mettrait a la porte si tu commencais a programmais comme ceci:

Code:

---

1 2 3 4

for(i=0;i<N;i++) for(j=0;j<j<N;j++) s+= t[j][i];

---

;-)

Citation:

---

Envoyé par fearyourself

Enfin, je suis peut-etre un peu naif de croire (ou d'esperer) qu'un patron te mettrait a la porte si tu commencais a programmais comme ceci:

---

Mettre à la porte, c'est peut-être un peu exagéré :) . Mais quand on me parle d'optimisation, j'ai toujours des frissons. En général, le compilateur le fait bien, et sinon, un changement dans les algorithmes est largement suffisant.
Evidemment, il faut faire des mesures... Mais dans le cas de salseropom, savoir si un T * est plus efficace qu'un T **... Bof (d'autant que je ne comprend toujours pas comment il fait pour les utiliser de facon équivalente, puisque ce sont des objets différents).

Je me souviens d'un type qui a passé deux jours à optimiser une routine d'initialisation (appelée une fois au début du programme) pour gagner quelques secondes sur un run de plusieurs jours... Pfff...

Citation:

---

Je me souviens d'un type qui a passé deux jours à optimiser une routine d'initialisation (appelée une fois au début du programme) pour gagner quelques secondes sur un run de plusieurs jours... Pfff...

---

On est d'accord... Il y a optimisation et optimisation... J'ai une tendance a croire que tout est une question de but...

Si on veut que le code tourne en dessous de X secondes, tous les moyens sont bons... Mais, soyons honnetes, ce n'est generalement pas la premiere chose a faire...

Avis aux programmeurs:

Commencez a faire marcher vos algorithmes, une fois que ca tourne et qu'il y a un reel besoin d'optimiser, commencez a vous poser des questions...

Citation:

---

Envoyé par fearyourself

Commencez a faire marcher vos algorithmes, une fois que ca tourne et qu'il y a un reel besoin d'optimiser, commencez a vous poser des questions...

---

Oui, le mot important est algorithme ici. Un bon exemple est un jeu vidéo. Pour optimiser le rendu, ils ne vont pas s'amuser à écrire *(p+i) au lieu de p[i] (le compilateur le fait tout seul de toute façon). Par contre, ils se démènent pour écrire des algos qui trouvent les pixels à ne pas afficher ou à limiter la recherche des solutions dans l'arbre de choix d'une AI...

Bonjour, ma question avait aussi un but pédagogique. Je ne pense pas réécrire tout mon programme mais si j'avais un nouveau prgm à écrire (ce qui sera le cas) que valait-il mieux que j'utilise : des T ou des T* ? Et donc la réponse dépend du temps de calculs (même si la différence est infime), je voulais aussi savoir si chaque composante de mon tab était un T ou un T* etc... Mais pour mon prochain prgm, j'aimerais éviter les recopies temporaires lors des appels et renvois des fonctions etc...

Citation:

---

que valait-il mieux que j'utilise : des T ou des T*

---

Cela dépend vraiment de ce que tu cherches à faire... C'est difficile à répondre ici...

Citation:

---

je voulais aussi savoir si chaque composante de mon tab était un T ou un T*

---

J'ai déjà répondu à cette question

Citation:

---

Citation:

---

t1[0] est un Species * et t2[0] est un Species. Est-ce vrai ?

---

C'est vrai.

---

Si tu veux éviter des copies passes tes structures par référence et non par valeur mais fais attention aux effets de bord. Toute modification de ta structure dans la fonction aura des répercussions à l'extérieur de la fonction, ce n'est pas toujours ce que l'on veut...

Jc

Citation:

---

Envoyé par salseropom

Mais pour mon prochain prgm, j'aimerais éviter les recopies temporaires lors des appels et renvois des fonctions etc...

---

Ah, tu parles de passage de structures comme argument d'une fonction. Dans ce cas, il est preferable de passer l'adresse de la structure (un T *) si celle-ci a une taille importante (plus que quelques entiers, typiquement). Cela afin d'eviter un cout de copie trop eleve (pour les tableaux, on n'a pas le choix, pour des raisons evidentes de performance).
Pour eviter, comme l'indique fearyourself, de modifier par erreur le contenu de la structure dans la fonction, tu peux la qualifier de const. Ainsi, le compilateur echouera si un membre de la structure se trouve a gauche d'une assignation (lvalue).

ok, merci. La prochaine fois, je ferai donc qqch du genre

Code:

---

1 2	void my_fun(const T* t)

---

Merci de votre patience