J'ai une petite question ce matin (ici, c'est le matin;)). . .
Je me demandais, quelle est la mémoire maximale qu'un programme que je code en c peut utiliser?
Merci
Alex
Version imprimable
J'ai une petite question ce matin (ici, c'est le matin;)). . .
Je me demandais, quelle est la mémoire maximale qu'un programme que je code en c peut utiliser?
Merci
Alex
Si tu parles du code lui-même, il n'y a pas vraiment de limite si ce n'est celle imposée par le système d'exploitation lui-même, qui dépendra surtout de la RAM dont tu disposes, et avec le mapping, ce n'est même plus tout-à-fait vrai.
Si tu veux connaître la quantité de mémoire que tu peux allouer à l'exécution de ton programme, là encore, ça dépendra de l'implémentation. Un malloc() sans fin utilisera d'abord toute la RAM (moins une certaine marge de fonctionnement) disponible puis le swap entier ... jusqu'à ce que ton système plante, à moins que des quotas explicites n'aient été posés à l'exécution de ton programme.
Un seul détail à retenir : faire attention à la taille du segment de pile. L'allocation de mémoire est implicite dans ce cas mais pourtant, le compilateur ne peut pas toujours calculer à l'avance la taille exacte maximum nécessaire, en particulier dans le cas de fonctions récursives.
Sauf erreur, il me semble bien qu'il n'existe pas, en C, de fonction universelle et portable pour connaître la taille de l'espace mémoire disponible restant.
Ca dépend de l'implémentation. Le C donne des minimas garantis pour un objet statique ou alloué :Citation:
Envoyé par Alexandreg12
- C90 : 32767 bytes
- C99 : 65535 bytes
Pour une implémentation donnée, il faut lire la doc. Elle ne peut dépasser
- C90 : ((size_t) (-1))
- C99 : SIZE_MAX (défini dans <limits.h>)
La limite réelle est déterminée par la quantité de mémoire disponible sur le système à un moment donné (ça peut changer dans le temps).
Pourquoi cette question ?
Je suis curieux et j'avais pensé à ça hier! ;)Citation:
Envoyé par Emmanuel Delahaye
C'est pas clair. Ca veut dire qu'on ne peut pas allouer plus de 65KB ? :S. Fishy...Citation:
Envoyé par Emmanuel Delahaye
Comprends pas.Citation:
Envoyé par Emmanuel Delahaye
Merci
Il y a getrlimit() sur certains unixoïdes.Citation:
Envoyé par Obsidian
C'est des minimums et des maximums, la vraie limite de ton sytème se situe quelque part entre les deux. (size_t)-1 est le plus grand entier non signé qui tient dans un size_t (le type qui sert à compter les bytes), SIZE_MAX est une constante définie dans limits.h.Citation:
Envoyé par bulki
Sur certaines implémentation, non. Par exemple sur une machine x86 en mode réel (16-bit) avec modèle de mémoire small, le segment de données fait 64 ko.Citation:
Envoyé par bulki
Qu'est-ce que tu ne comprends pas ? Je veux bien répondre à une question, mais encore faut-il qu'il y ait une question ...Citation:
Comprends pas.
P.S. J'ai ajouté une petite précision.
Je crois qu'on est en train de se mélanger les pinceaux :yaisse2:, entre taille d'un size_t et mémoire adressable par un processus.Citation:
Envoyé par Emmanuel Delahaye
Concernant le realmode, on peut avoir accès jusqu'à 64Ko, cad 2^16, car on a que 16 bits. Cependant, on arrive tout de même à adresser 1Mo avec la mémoire étendue.
On est bien d'accord que sur un ia32, l'espace virtuel adressable est de 4GB pour un processus donné (moins l'espace kernel, etc), non (et de 2^48b pour un x86_64)?
20 bits d'adressage de base donc 1 Mio, et avec la mémoire étendue on arrive maximum à 0x10FFEF (0xFFFF0 + 0xFFFF) soit 1 114 096 octets donc à peu près 1 Mio et 64 Kio si je sais encore compter.Citation:
Envoyé par bulki
Ça n'a pas grand-chose à voir avec ce que le programme pourra utiliser à l'exécution, par exemple pour la taille de la pile sous Windows : http://msdn.microsoft.com/en-us/library/8cxs58a6.aspxCitation:
Envoyé par bulki
Citation:
For x86 and x64 machines, the default stack size is 1 MB.
Effectivement ! Le pire, c'est que je connaissais en écriture (jamais eu besoin de fixer ces valeurs, cependant) et que je n'avais pas du tout pensé à ça sur le coup.Citation:
Envoyé par dapounet
Merci pour cette précision.
La heap est quand à elle moins limitée.Citation:
Envoyé par dapounet
Hum, je vois sous wikipedia:
Hum, y'a un truc qui me gêne la dedans. Faut que j'y réfléchisse à tête plus froide.Citation:
Envoyé par http://en.wikipedia.org/wiki/Malloc
I'll be back.
Merci
edit: ce qui me gêne, c'est ce truc de "garantie". Ca dit genre "j'aimerais 1GB de mémoire svp" et le système répond "bah, tiens 32K, vu qu'on est en C89". S'il ne peut pas allouer, il doit renvoyer NULL, pas 32K.
ou peut-être, je comprends mal et on veut dire "moi [le système] te garantis que tu pourras au moins allouer 32K pour un seul objet et peut-être plus si affinité".
C'est très exactement la réponse que j'ai donnée...Citation:
Envoyé par bulki
Oui, tout à fait.Citation:
Envoyé par Emmanuel Delahaye
tu trouves pas que ça le donne mieux en anglais :P ?
Garanti par le langage, ça veut dire que si la mémoire est disponible, tu es certain d'obtenir un bloc de 32 k si tu le demandes. Si c'est un malloc(), évidemment qu'en cas d'impossibilité, malloc() retourne NULL, ça aussi, c'est garanti par le langage.Citation:
Envoyé par bulki
C'est plus chaud pour le blocs statiques, mais en principe, en cas d'impossibilité, soit le linker refuse de générer l'exécutable (too many data), c'est le cas notamment en embarqué et en 16-bit, soit c'est le loader qui va dire 'trop de mémoire demandé, chargement impossible'. Là, ça dépend plus de la QoI (Quality of Implementation).
Ok, merci pour ces précisions, je n'avais jamais entendu parler de cette limite auparavant.Citation:
Envoyé par Emmanuel Delahaye
Tu te doutes bien que la mémoire n'est pas une ressource infinie...Citation:
Envoyé par bulki
Bien sûr, et d'ailleurs c'est bien clair, ca retourne NULL si le système ne peut pas allouer de mémoire ou le pézot de mémoire sinon.Citation:
Envoyé par Emmanuel Delahaye
Trop de spécification tue la spécification :yaisse2: (ou embrouille les gens).