bonjour a tous, Je constate ce matin que le moindre "hello world" en haskell fait 507k sur mon systeme (soit plus de 2x la taille de l'interpreteur lua, par exemple). J'esperais nettement moins (je voulais commencer a utiliser haskell pour de petites taches sur une machine disposant de peu de ressources). J'ai regardé dans le man de ghc dans la partie optimisation et ... j'ai pas compris grand chose. Deux questions me viennent: - ai-je loupé qqchose d'important pour le controle de la taille des binaires? - qu'est ce qui explique cet embonpoint ? cordialement marc
Excerpts from Marc Chantreux's message of Thu Jan 07 09:02:37 +0100 2010:
bonjour a tous,
Je constate ce matin que le moindre "hello world" en haskell fait 507k sur mon systeme (soit plus de 2x la taille de l'interpreteur lua, par exemple). J'esperais nettement moins (je voulais commencer a utiliser haskell pour de petites taches sur une machine disposant de peu de ressources).
J'ai regardé dans le man de ghc dans la partie optimisation et ... j'ai pas compris grand chose. Deux questions me viennent:
- ai-je loupé qqchose d'important pour le controle de la taille des binaires? - qu'est ce qui explique cet embonpoint ?
C'est bien la taille du "runtime system" qui fait ~500k. Chez moi c'est cette bibliothèque: ls -l /usr/lib/ghc-6.10.4/libHSrts.a Cependant le coup d'entré est à peut près constant. Quelle sont les ressources disponibles? Cordialement, -- Nicolas Pouillard http://nicolaspouillard.fr
On 01/07/2010 09:02 AM, Marc Chantreux wrote:
bonjour a tous,
Je constate ce matin que le moindre "hello world" en haskell fait 507k sur mon systeme (soit plus de 2x la taille de l'interpreteur lua, par exemple). J'esperais nettement moins (je voulais commencer a utiliser haskell pour de petites taches sur une machine disposant de peu de ressources).
J'ai regardé dans le man de ghc dans la partie optimisation et ... j'ai pas compris grand chose. Deux questions me viennent:
- ai-je loupé qqchose d'important pour le controle de la taille des binaires? - qu'est ce qui explique cet embonpoint ?
cordialement marc _______________________________________________ Haskell-fr mailing list Haskell-fr@haskell.org http://www.haskell.org/mailman/listinfo/haskell-fr
De mémoire, la construction d'exécutable intègre le runtime de ghc. Il y a des travaux récents pour éviter ça (cf IHG ) mais c'est pas vraiment terminé : http://blog.well-typed.com/2009/04/hello-world-now-only-11k-using-ghc-with-s... -- Best regards, Lionel Barret de Nazaris Gamr7 === Create bigger cities faster with Urban PAD http://gamr7.com/g2009/urban_pad. follow us : rss http://gamr7.com/g2009/default/feed.rss, twitter http://twitter.com/Gamr7, facebook http://www.facebook.com/pages/Urban-PAD/124363971359
Essaie avec JHC. Si JHC arrive à compiler ton source, tu auras un exécutable beaucoup plus petit qu'avec GHC.
bon WE à tous et merci a tous pour vos réponses qui me font conclure que le jour ou j'aurais un niveau potable en haskell, cette limite des 500k sera de la veille histoire. Nicolas: je ne sais meme pas trop. c'etait plus une excuse qu'une vraie nécessité. Pour info: le binaire resultant de mon programe écrit en C fait 24k et j'esperait dans ces ordres de grandeur. On Thu, Jan 07, 2010 at 01:14:52PM +0100, David Virebayre wrote:
Essaie avec JHC. Si JHC arrive à compiler ton source, tu auras un exécutable beaucoup plus petit qu'avec GHC.
Je tenterais JHC quand il sera packagé ;) non plus serieusement le site de hackage a l'air dans les choux: je vais essyer plus tard. encore merci a tous. marc
participants (4)
-
David Virebayre -
Lionel Barrret -
Marc Chantreux -
Nicolas Pouillard