IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

gestion de la mémoire


Sujet :

C

  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 298
    Points : 886
    Points
    886
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?

  2. #2
    Expert éminent sénior
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Points : 20 985
    Points
    20 985
    Par défaut Re: gestion de la mémoire
    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
    (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.
    est de taille limitée donc il y a le tas (ensemble des variables dynamiques).
    Admettons...
    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.

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

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    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.
    et chaque élément de t2 est un Species * donc dynamique donc dans le tas. Est-ce vrai ?
    Oui.
    Pas de Wi-Fi à la maison : CPL

  3. #3
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    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

  4. #4
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 298
    Points : 886
    Points
    886
    Par défaut
    Salut Emmanuel, merci de ces précisions. J'utilisais parfois du vocabulaire du C++. Mais juste une précision : j'avais écrit :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  5. #5
    Candidat au Club
    Inscrit en
    Décembre 2005
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    Je pense que ça revient au même. A confirmer :p

  6. #6
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    t1[0] est un Species * et t2[0] est un Species. Est-ce vrai ?
    C'est 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) ?
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  7. #7
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 298
    Points : 886
    Points
    886
    Par défaut
    ok, merci pour toutes vos précisions. Je vais donc opter pour mon t2

  8. #8
    Membre expérimenté
    Inscrit en
    Décembre 2004
    Messages
    1 478
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 478
    Points : 1 664
    Points
    1 664
    Par défaut
    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.

  9. #9
    Candidat au Club
    Inscrit en
    Décembre 2005
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    L'optimisation est alors une perte de temps et d'argent.
    Ca c'est de la conclusion! lol

  10. #10
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    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:

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    for&#40;i=0;i<N;i++&#41;
        for&#40;j=0;j<j<N;j++&#41;
            s+= t&#91;j&#93;&#91;i&#93;;
    ;-)

  11. #11
    Membre expérimenté
    Inscrit en
    Décembre 2004
    Messages
    1 478
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 478
    Points : 1 664
    Points
    1 664
    Par défaut
    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...

  12. #12
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    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...

  13. #13
    Membre expérimenté
    Inscrit en
    Décembre 2004
    Messages
    1 478
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 478
    Points : 1 664
    Points
    1 664
    Par défaut
    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...

  14. #14
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 298
    Points : 886
    Points
    886
    Par défaut
    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...

  15. #15
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    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...

    je voulais aussi savoir si chaque composante de mon tab était un T ou un T*
    J'ai déjà répondu à cette question


    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

  16. #16
    Membre expérimenté
    Inscrit en
    Décembre 2004
    Messages
    1 478
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 478
    Points : 1 664
    Points
    1 664
    Par défaut
    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).

  17. #17
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 298
    Points : 886
    Points
    886
    Par défaut
    ok, merci. La prochaine fois, je ferai donc qqch du genre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    void my_fun&#40;const T* t&#41;
    Merci de votre patience

Discussions similaires

  1. Réponses: 17
    Dernier message: 02/02/2006, 13h03
  2. gestion de la mémoire
    Par moldavi dans le forum C++
    Réponses: 17
    Dernier message: 05/02/2005, 00h18
  3. Réponses: 11
    Dernier message: 26/12/2004, 23h50
  4. Gestion de la mémoire entre plusieurs DLL
    Par Laurent Gomila dans le forum C++
    Réponses: 7
    Dernier message: 27/07/2004, 16h28
  5. Gestion des variables - mémoire ?
    Par RIVOLLET dans le forum Langage
    Réponses: 4
    Dernier message: 26/10/2002, 13h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo