Discussion :

[Invité1]

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

[Obsidian]

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.

[Emmanuel Delahaye]

Je me demandais, quelle est la mémoire maximale qu'un programme que je code en c peut utiliser?

Ca dépend de l'implémentation. Le C donne des minimas garantis pour un objet statique ou alloué :

• 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 ?

[Invité1]

Pourquoi cette question ?

Je suis curieux et j'avais pensé à ça hier!

[bulki]

Ca dépend de l'implémentation. Le C donne des minimas garantis pour un objet statique ou alloué :

• C90 : 32767 bytes
• C99 : 65535 bytes

C'est pas clair. Ca veut dire qu'on ne peut pas allouer plus de 65KB ? :S. Fishy...

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>)

Comprends pas.

Merci

[dapounet]

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.

Il y a getrlimit() sur certains unixoïdes.

C'est pas clair. Ca veut dire qu'on ne peut pas allouer plus de 65KB ? :S. Fishy...



Comprends pas.

Merci

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.

[Emmanuel Delahaye]

C'est pas clair. Ca veut dire qu'on ne peut pas allouer plus de 65KB ?

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.

Comprends pas.

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 ...

P.S. J'ai ajouté une petite précision.

[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.

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 ...

P.S. J'ai ajouté une petite précision.

Je crois qu'on est en train de se mélanger les pinceaux , entre taille d'un size_t et mémoire adressable par un processus.

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)?

[dapounet]

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.

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.

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)?

Ç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.aspx

For x86 and x64 machines, the default stack size is 1 MB.

[Obsidian]

Il y a getrlimit() sur certains unixoïdes

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.

Merci pour cette précision.

[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.aspx

La heap est quand à elle moins limitée.

Hum, je vois sous wikipedia:

Allocation size limits

The largest possible memory block malloc can allocate depends on the host system, particularly the size of physical memory and the operating system implementation. Theoretically, the largest number should be the maximum value that can be held in a size_t type, which is an implementation-dependent unsigned integer representing the size of an area of memory. The maximum value is (size_t) −1, or the constant SIZE_MAX in the C99 standard. The C standards guarantee that a certain minimum (0x7FFF in C90, 0xFFFF in C99) for at least one object can be allocated.

Hum, y'a un truc qui me gêne la dedans. Faut que j'y réfléchisse à tête plus froide.

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é".

[Emmanuel Delahaye]

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.

C'est très exactement la réponse que j'ai donnée...

[bulki]

C'est très exactement la réponse que j'ai donnée...

Oui, tout à fait.
tu trouves pas que ça le donne mieux en anglais ?

[Emmanuel Delahaye]

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é".

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.

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).

[bulki]

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.

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.

[Emmanuel Delahaye]

Ok, merci pour ces précisions, je n'avais jamais entendu parler de cette limite auparavant.

Tu te doutes bien que la mémoire n'est pas une ressource infinie...

[bulki]

Tu te doutes bien que la mémoire n'est pas une ressource infinie...

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.

Trop de spécification tue la spécification (ou embrouille les gens).