Discussion :

[Om yassoufa]

Bonsoir,
je veux savoir le nombre des octets nécessaires pour coder les différents types en lisp : entier, réel ,booléen ,char ,string...
Merci

[byjav]

Salut !

Personne ne le sait pas. Lisp gère la memoir lui-même. Le standard ne spécifie pas comment les objets sont représentés dans la mémoire.

Par exemple, un entier est un fixnum ou un bignum. Le dernier peut être arbitrairement grand. Quant'aux fixnums, le standard garantie que c'est un supertype de (signed-byte 16). Alors, c'est au moins 16 bits. Il est inconnu où il sont localisés. Ce qui vraiment intéresse un programmeur, c'est, pour exemple, quel est le fixnum plus grand. C'est la valeur de la constante most-positive-fixnum.

J'ai trouvé une discussion très intéressant, où l'un des auteurs du standard (Kent Pitman) explique pourquoi lisp est comme ça:
https://groups.google.com/forum/#!to...sp/xv_IUl6wiWA

[jack-ft]

je veux savoir le nombre des octets nécessaires pour coder les différents types en lisp : entier, réel ,booléen ,char ,string...

Peux-tu nous dire pourquoi tu veux savoir cela?

[Om yassoufa]

Peux-tu nous dire pourquoi tu veux savoir cela?

Bonjour,
en fait je dois mener des statistiques sur l'occupation mémoire d'un ensemble de programmes fonctionnels
merci

[byjav]

Ben, c'est peu applicable en cas de Common Lisp.

Premièrement, ce n'est pas un langage fonctionnel. (En effet, pourquoi est-ce que vous croyez qu'il l'est ?)

Deuxièmement, Common Lisp, c'est le standard et en plusieures réalisations. Que je sache, le standard ne fait pas mention sur l'occupation de mémoire, alors les réalisations peuvent se comporter comment il leur plaît. Par exemple, SBCL réserve le tas (dont la dimension peut être contrôlée par l'option --dynamics-space-size) au démarrage, et c'est la dimension du tas qu'importe au monde extérieur, pas la dimension des objets spécifiques.

[jack-ft]

en fait je dois mener des statistiques sur l'occupation mémoire d'un ensemble de programmes fonctionnels

Ces programmes sont-ils déjà écrits?
Dans quel environnement lisp tournent-ils?
Sont-ils compilés ou interprétés?
(quoique cela ne doit pas changer l'occupation mémoire des données, seulement l'occupation mémoire du programme)

[Om yassoufa]

Ces programmes sont-ils déjà écrits?
Dans quel environnement lisp tournent-ils?
Sont-ils compilés ou interprétés?
(quoique cela ne doit pas changer l'occupation mémoire des données, seulement l'occupation mémoire du programme)

Bonjour jack,
Ces sont des projets libres ou des packages de lisp telque Matlisp https://sourceforge.net/projects/matlisp/
et justement je cherche à évaluer la variation de l'occupation en mémoire du programme dés la déclaration des variables jusqu'à la fin mais j'arrive pas à le faire pour les programmes en lisp. Pour le c ou le java la taille des différents types est connue et donc c'était facile de faire les stats mais pour le lisp, j'arrive pas à les faire.
Merci

[jack-ft]

Si cela t'intéresse, je peux retrouver la taille précise des différents types d'objets en ram dans l'environnement Le_Lisp 15.25.

En fait, c'est dans le manuel à la page 1-10: http://www.softwarepreservation.org/...en-1993_12.pdf

Mais ça peut dépendre de l'implémentation de lisp utilisée.

Du coup, peux-tu répondre à la question que j'ai posée précédemment:
de quel environnement lisp s'agit-il (Le_Lisp, Clisp, LispWorks, SBCL, Allegro CL, CMU CL, etc.)?

Ces sont des projets libres ou des packages de lisp tels que Matlisp https://sourceforge.net/projects/matlisp/
et justement je cherche à évaluer la variation de l'occupation en mémoire du programme dés la déclaration des variables jusqu'à la fin

Hum... La variation de l'occupation en mémoire?

En ce qui me concerne, il faudrait être plus précis.

Veux-tu parler de l'augmentation de la taille du process? (Comme lorsqu'on fait un "malloc" en C)

En effet, le seul lisp dont je connaisse bien (ou aie bien connu) l'implémentation est Le_Lisp.
Or, dans celui-ci, la taille du process est fixe et déterminée par les constantes qui ont servi à sa constitution et par un argument fourni au lancement.
Ensuite, les équivalents des mallocs sont gérés à l'intérieur de l'espace alloué au départ et ne changent pas la taille du process.
Une des conséquences est que l'on peut produire une erreur fatale si on alloue et stocke plus d'objets que ne peut en contenir cet espace!
On peut cependant considérer la variation de l'espace à l'intérieur des zones allouées au départ.

Veux-tu calculer cette variation à la main ou par programme? (en Le_Lisp, il existe une fonction "gcinfo" qui permet d'obtenir l'occupation des différentes zones)

D'autres lisps ont une gestion dynamique de l'espace alloué et leur process peut effectivement croître si besoin.