lundi 17 novembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de iug :

Journal : L'allocation mémoire et les langages fonctionnels

Posté par iug () le 03 mars 2004
0
Imaginons un langage avec un garbage collector (style ocaml) et un programme de porc du style :

{
variables_globales_d_init qui font 50 Mo ;
variables_pour_la_suite qui font 50 Mo ;
mon code d'init qui utilise les variables d'init ;
mon code pour la suite qui utilise plus les variables d'init ;
}

Je me dis que les variables utilisées pour l'init vont jamais être libérées, à moins que le compilateur ait fait une analyse statique du code pour voir à quel moment les variables cessaient d'être utilisées. Si y'a pas d'analyse statique, alors je me trimbale avec un programme qui me prend 100 Mo au lieu de 50 Mo. Ou alors je peux désalouer la ram à la main en cassant la référence vers mais variables d'init, i.e. je me fais de la gestion mémoire à la mimine, ce qui limite largement l'intérêt du garbage collector :)

> Lire le journal (9 commentaires, moyenne: 1,9).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: L'allocation mémoire et les langages fonctionnels

Posté par Pascal Terjan (Jabber id, page perso, ) le 03/03/2004 à 11:06. (lien). Évalué à 5.

C'est pas specialement lié aux langages fonctionnels.
Si en java tu gardes les references vers des trucs inutiles c'est pareil.

  • [^]Re: L'allocation mémoire et les langages fonctionnels

    Posté par iug () le 03/03/2004 à 11:09. (lien). Évalué à 0.

    J'imagine bien. Tu sais pas si il y a de l'analyse statique dans ocaml. C'est assez pauvre en doc d'implémentation sur caml.inria.fr. Ya surtout des papiers de recherche. Je me serais attendu à un howto-gérer-son-allocation-a-la-mimine.

    • [^]Re: L'allocation mémoire et les langages fonctionnels

      Posté par champi (page perso, ) le 03/03/2004 à 11:15. (lien). Évalué à 1.

      Faudrait poser la question sur la ML. Un volontaire ?

    • [^]Re: L'allocation mémoire et les langages fonctionnels

      Posté par Vivi (page perso, ) le 03/03/2004 à 11:49. (lien). Évalué à 4.

      howto-gérer-son-allocation-a-la-mimine

      ben c'est trés simple : on fait pas (c'est pas sûr).
      Si tu veux pas garder tes variables tout le temps en mémoire, il faut pas les mettre en global, c'est tout.

    • [^]Re: L'allocation mémoire et les langages fonctionnels

      Posté par drac () le 03/03/2004 à 11:59. (lien). Évalué à 3.

      Peut-être parce que il est conseillé de passé les variables en argument des fonctions et que cela reste le plus local possible (ie faire des sous fonctions), utilisé des récursivités terminales si c'est possible etc ...

      Enfin faire en sorte déjà de coder proprement pour pas garder en mémoire des trucs qui ne serviront à rien.

Re: L'allocation mémoire et les langages fonctionnels

Posté par free2.org (page perso, ) le 03/03/2004 à 11:42. (lien). Évalué à 1.

ça ne répond complètement pas à ta question, car le travail n'est pas fait automatiquement par le compilo, mais c'est pas hors sujet:
voici quasiment le meme programme en C (peut-etre que ça marche en ocaml) qui désalloue correctement les variables d_init quand y'en a plus besoin:

{
{variables_globales_d_init qui font 50 Mo ;
static variables_pour_la_suite qui font 50 Mo ;
mon code d'init qui utilise les variables d'init ;
}
mon code pour la suite qui utilise plus les variables d'init ;
}

-------------------------------
voici encore une autre version, car
le plus sûr et le plus simple est bien sûr de le réordonner un peu:
-------------------------------------

{variables_pour_la_suite qui font 50 Mo ;

{variables_globales_d_init qui font 50 Mo ;
mon code d'init qui utilise les variables d'init ;
}
mon code pour la suite qui utilise plus les variables d'init ;
}

/* un autre avantage de cette manière de programmer avec des blocs supplémentaires, c'est que ça oblige ensuite le programmeur à éviter l'utilisation de variables globales qui génèrent des erreurs quand elles sont utilisées en même temps à des endroits très différents d'un programme */

  • [^]Re: L'allocation mémoire et les langages fonctionnels

    Posté par Sixel (page perso, ) le 03/03/2004 à 13:04. (lien). Évalué à 1.

    Le monsieur, il veut un programme de porc (sic).

    --
    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

    • [^]Re: L'allocation mémoire et les langages fonctionnels

      Posté par Fabien F. () le 03/03/2004 à 16:43. (lien). Évalué à 1.

      Le monsieur, il veut un programme de porc (sic).

      Le monsieur devrait trouver, il en existe beaucoup, et beaucoup de gens savent en produire :)

      Le monsieur, en fait, se casse le nez contre le celebre probleme dit "garbage in, garbage out", ou en bon francais avec de la merde on ne produit que de la merde. Il est raisonnablement simple d'ecrire un programme qui ne gache pas la memoire de cette facon si on utilise un langage raisonnablement bien fichu, ce qui est le cas d'ocaml. Mais on ne sait pas encore faire des langages qui permettent a de mauvais programmeurs d'ecrire des bons programmes. Tant mieux d'ailleurs, parce que ce jour la (en supposant qu'il arrive un jour...), on n'aura plus besoin de bons programmeurs !

      Pour le cas particulier de la liveness analisys dans Ocaml, il est probable qu'il puisse demeler les cas les plus simples, je ne sais pas dans quelle mesure celui-la en fait partie (ca doit dependre en grande partie du code d'init des blocs de 50Mo). Mais un programmeur suffisamment mauvais arrivera toujours a ecrire des horreurs trop horribles pour que le compilo puisse les rattrapper.

Re: L'allocation mémoire et les langages fonctionnels

Posté par benja () le 03/03/2004 à 16:00. (lien). Évalué à 1.

le module Weak d'ocaml devrait te permettre de faire ce que tu veux: l'expression n'est pas liberee explicitement, mais on indique au GC qu'il peut la liberer a tout instant.
http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/book-ora090.html(...)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0655s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !