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 mémoire étendue


Sujet :

C++

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Août 2007
    Messages
    21
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 21
    Par défaut Gestion mémoire étendue
    Bonjour, je m'étais mis étant jeune à programmer des projets de plus en plus gros et je me rappelle avoir été stoppé par la gestion de la mémoire étendue. Je programmais en C avec du matos préhistorique...J'ai fouillé google à la recherche de l'info suivante qui est peut être très bête:

    - l'opérateur new de C++ alloue t'il de la mémoire sur la mémoire conventionelle exclusivement ou il puise aussi dans la mémoire étendue ?

    Merci pour vos réponses

  2. #2
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Pour les vieilles plate-formes 16 bits, je dirais: "Ça doit dépendre de la Run-Time Library employée".
    Et encore ce n'est même pas sûr, car il me semble que la mémoire étendue n'est pas vraiment accessible avec un pointeur far normal (qui permet seulement d'accéder à n'importe quel segment de la mémoire conventionnelle).

    Sur une plate-forme 32 bits, la question n'a plus de sens, puisqu'il n'y a plus de distinction conventionnelle/étendue.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Août 2007
    Messages
    21
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 21
    Par défaut
    Merci pour cette grande aide apportée, je le sentais mal d'être limité à 640 ko de mémoire comme dans le temps lol...

    Vraiment un grand merci

  4. #4
    Expert confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Février 2007
    Messages
    4 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2007
    Messages : 4 253
    Billets dans le blog
    3
    Par défaut
    Bah... c'est juste la limite qui a changé....

    16 bits = 640Ko is ought to be enough
    32 bits = 3Go (sur les 4go théoriques)
    64 bits = pour l'instant 16To sur les derniers kernels linux (potentiellement 16 millions de To).

  5. #5
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Déjà, le pointeur fait toujours la même taille, le pointeur est donc suffisamment grand pour contenir l'adresse de n'importe quel emplacement auquel tu as accès sur la plate-forme.

    Après, où ça alloue, ça dépend de ton implémentation.
    Normalement tu tournes avec un noyau derrière avec un MMU donc les adresses que ton programme voit n'ont rien à voir avec les adresses physiques.
    Le programme peut normalement demander au noyau de lui mapper une page de mémoire virtuelle vers de la vraie mémoire à l'adresse qu'il veut, et après l'allocateur se charge de fragmenter ça en morceaux qu'on lui demande.

    En fait en programmant normalement tu peux même pas vraiment savoir à quel point deux adresses sont vraiment éloignées, et si elles sont vraiment éloignées du code.

  6. #6
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Mais d'où vient cette histoire de 640k exactement ?
    Avec des pointeurs far, on devrait pouvoir adresser 64k*16 = 1Mo, non?

    Edit: OK, j'ai trouvé une page qui explique: http://en.wikipedia.org/wiki/Convent...640_kB_barrier
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #7
    Expert confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Février 2007
    Messages
    4 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2007
    Messages : 4 253
    Billets dans le blog
    3
    Par défaut
    Pour la même raison qu'on ne peut addresser "que" 3Go (et encore avec bidouille) sur un Windows 32 bits...

  8. #8
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Sur du x86 tu peux très bien avoir 4 Gos entier par processus, avec plus de 4 Gos en physique au total.

  9. #9
    Expert confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Février 2007
    Messages
    4 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2007
    Messages : 4 253
    Billets dans le blog
    3
    Par défaut
    Sur du x86 je sais pas...

    Sur du Windows 32, c'est 2Go limite par processus, 3Go avec un peu de bidouille à l'init, et basta. (http://msdn2.microsoft.com/en-us/lib...73(VS.85).aspx)

    Windows Server 32 EE et DE supportent un peu plus (64Go si je me souviens bien), mais les applications doivent être codées spécifiquement avec l'AWE API(http://www.microsoft.com/whdc/system...AE/pae_os.mspx
    et http://msdn2.microsoft.com/en-us/library/aa366527.aspx)

    Et sur Windows 64 (et avec une application 64 bits), c'est 8To limite par processus (43 bits d'addressing) sans API particulière.

    http://msdn2.microsoft.com/en-us/library/bb147385.aspx

Discussions similaires

  1. Thread POSIX et gestion mémoire
    Par pier* dans le forum POSIX
    Réponses: 1
    Dernier message: 07/07/2006, 21h36
  2. TAO, Value types et gestion mémoire
    Par TiChabin972 dans le forum CORBA
    Réponses: 1
    Dernier message: 25/04/2006, 20h55
  3. [D7] Tableau dynamique et Gestion mémoire
    Par Cl@udius dans le forum Langage
    Réponses: 7
    Dernier message: 13/03/2006, 15h16
  4. [Gestion mémoire] SetLength sur TDoubleDynArray
    Par MD Software dans le forum Langage
    Réponses: 14
    Dernier message: 24/04/2005, 21h11
  5. Gestion mémoire des Meshes (LPD3DXMESH)
    Par [Hideki] dans le forum DirectX
    Réponses: 1
    Dernier message: 08/07/2003, 20h34

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