Pourquoi le GHC est-il si grand / gros?


147

Y a-t-il une réponse simple: pourquoi le GHC est-il si grand?

  • OCaml: 2 Mo
  • Python: 15 Mo
  • SBCL: 9 Mo
  • OpenJRE - 26 Mo
  • GHC: 113 Mo

Pas intéressé par l'évangélisation de "Pourquoi je ne devrais pas me soucier de la taille si Haskell est le bon outil"; c'est une question technique.


1
D'où obtenez-vous ces 500 Mo? Mon GHC est loin d'être aussi gros.
Jacob

À moins que vous ne comptiez toutes les bibliothèques, je suppose ...
Jacob

Désolé, je sortais d'un téléchargement du gestionnaire de paquets qui comprend quelques deps. Je l'ai mis à jour pour refléter la taille de téléchargement à partir du site Web. J'ai ajouté un récapitulatif d'édition mais il n'apparaît pas (encore?) Ici. Je pense que la question est toujours d'actualité. C'est gros.
Christopher a terminé le

20
Nous devrions probablement comparer les pommes aux pommes et les oranges aux oranges. JRE est un runtime, pas un kit de développement. Bundle source OpenJDK 7, 82 Mo ( download.java.net/openjdk/jdk7 ) vs bundle source GHC 7, 23 Mo ( haskell.org/ghc/download_ghc_7_0_1 ). Maintenant runtime: openjdk-6-jre-headless sur Ubuntu, 77 Mo décompressé vs Haskell helloworld, lié statiquement à son runtime, <1 MB.
sastanin le

Aujourd'hui, j'étais curieux de connaître les tailles maintenant 2014. Il semble que l'argument tient toujours. J'ai trouvé des URL: 1.GHC haskell.org/ghc/download_ghc_7_8_3 ; 2.OpenJCK packages.ubuntu.com/precise/openjdk-7-jdk
AnneTheAgile

Réponses:


187

C'est vraiment un peu idiot. Chaque bibliothèque fournie avec GHC est fournie dans pas moins de 4 saveurs :

  • statique
  • dynamique
  • profilé
  • GHCi

La version GHCi n'est que la version statique liée entre elles dans un seul .ofichier. Les trois autres versions ont toutes leur propre ensemble de fichiers d'interface ( .hifichiers). Les versions profilées semblent être environ deux fois plus grandes que les versions non profilées (ce qui est un peu suspect, je devrais regarder pourquoi).

N'oubliez pas que GHC lui-même est une bibliothèque , vous obtenez donc 4 copies de GHC. Non seulement cela, mais le binaire GHC lui-même est lié statiquement, ce qui fait 5 copies de GHC.

Nous l'avons récemment fait pour que GHCi puisse utiliser les .afichiers statiques . Cela nous permettra de nous débarrasser de l'une de ces saveurs. À plus long terme, nous devrions lier dynamiquement GHC, mais c'est un changement plus important car cela impliquerait de faire de la liaison dynamique la valeur par défaut - contrairement à C, avec GHC, vous devez décider à l'avance si vous allez créer une liaison dynamique ou non. Et nous avons besoin de plus de changements (par exemple à Cabal et au système de paquets, entre autres) avant que cela ne soit vraiment pratique.


16
Et ici, je pensais que c'était toute la logique qu'offre Haskell: évaluation paresseuse, inférence de type, etc.
mcandre

4
Donc, 113 Mo / 4 ~ = 28 Mo, toujours plus grand qu'OpenJRE ... Mais considérez que GHC est comparable à OpenJDK, pas seulement JRE, ça me fait me sentir mieux.
Earth Engine

1
Maintenant que je pense que GHC utilise la liaison dynamique, peut-être que les idées du Dr @Simon Marlow pour la compression des quatre saveurs sont plus pratiques? Cite: 1. # 3658 (liez dynamiquement GHCi (et utilisez le linker système) sur les plates-formes qui le supportent) - GHC ghc.haskell.org/trac/ghc/ticket/3658 ; 2. # 8266 (Liaison dynamique sur Mac) - GHC ghc.haskell.org/trac/ghc/ticket/8266 ; 3. # 8376 (Static Executable + GHC API (+ Dynamic Linking?) Donne Segfault) - GHC
AnneTheAgile

56

Nous devrions probablement comparer les pommes aux pommes et les oranges aux oranges. JRE est un runtime, pas un kit de développement. Nous pouvons comparer: la taille de la source du kit de développement, la taille du kit de développement compilé et la taille compilée du runtime minimal.

Le bundle source OpenJDK 7 est de 82 Mo (download.java.net/openjdk/jdk7) par rapport au bundle source GHC 7, soit 23 Mo (haskell.org/ghc/download_ghc_7_0_1). GHC n'est pas grand ici. Taille d'exécution: openjdk-6-jre-headless sur Ubuntu est de 77 Mo non compressé par rapport à Haskell helloworld, lié statiquement à son exécution, qui est <1 Mo. GHC n'est pas grand ici.

Là où GHC est grand, c'est la taille du kit de développement compilé:

Utilisation du disque GHC

GHC lui-même prend 270 Mo, et avec toutes les bibliothèques et utilitaires qui se réunissent, il prend plus de 500 Mo. Et oui, c'est beaucoup, même avec les bibliothèques de base et un outil de construction / gestionnaire de dépendances. La plate-forme de développement Java est plus petite.

GHC:

$ aptitude show ghc6 | grep Size
Uncompressed Size: 388M

contre OpenJDK avec des dépendances:

$ aptitude show openjdk-6-jdk openjdk-6-jre openjdk-6-jre-headless ant maven2 ivy | grep Size
Uncompressed Size: 34.9M
Uncompressed Size: 905k
Uncompressed Size: 77.3M
Uncompressed Size: 1,585k
Uncompressed Size: 3,736k
Uncompressed Size: 991k

Mais c'est toujours plus de 100 Mo, pas 26 Mo au moment où vous écrivez.

Les éléments lourds dans ghc6 et ghc6-prof sont:

$ dpkg -L ghc6 | grep '\.a$' | xargs ls -1ks | sort -k 1 -n -r | head -3
57048 /usr/lib/ghc-6.12.1/ghc-6.12.1/libHSghc-6.12.1.a
22668 /usr/lib/ghc-6.12.1/Cabal-1.8.0.2/libHSCabal-1.8.0.2.a
21468 /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0.a
$ dpkg -L ghc6-prof | grep '\.a$' | xargs ls -1ks | sort -k 1 -n -r | head -3
112596 /usr/lib/ghc-6.12.1/ghc-6.12.1/libHSghc-6.12.1_p.a
 33536 /usr/lib/ghc-6.12.1/Cabal-1.8.0.2/libHSCabal-1.8.0.2_p.a
 31724 /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0_p.a

Veuillez noter sa taille libHSghc-6.12.1_p.a. La réponse semble donc être des versions de liaison et de profilage statiques pour chaque bibliothèque.


9

Ma conjecture - beaucoup, beaucoup de liens statiques. Chaque bibliothèque doit relier statiquement ses dépendances, qui à leur tour doivent relier statiquement les leurs et leur logiciel. Et tout cela est souvent compilé avec et sans profilage, et même sans profilage, les binaires ne sont pas supprimés et contiennent donc beaucoup d'informations de débogage.


2
Cela ne me dérangerait probablement pas que GHC passe à un programme complet, recompile presque tout le modèle, similaire à jhc. Il pourrait même se compiler plus rapidement s'il empêchait 'ld' de changer.
John L

8

Parce qu'il regroupe gcc et un tas de bibliothèques, toutes liées statiquement.

Au moins sur Windows.


12
non, pas sous Linux. cela ne dépend que de gcc. parce que windows n'a pas de gcc dans sa "distribution", il doit venir avec ghc.
comonad

5

Voici la répartition de la taille du répertoire sur ma boîte:

https://spreadsheets.google.com/ccc?key=0AveoXImmNnZ6dDlQeHY2MmxPcEYzYkpweEtDSS1fUlE&hl=fr

Il semble que le plus grand répertoire (123 Mo) soit les binaires pour compiler le compilateur lui-même. Les documents pèsent à un incroyable 65 Mo. La troisième place est Cabal à 41 MB.

Le répertoire bin fait 33 Mo, et je pense que seul un sous-ensemble de celui-ci est techniquement nécessaire pour créer des applications Haskell.


6
Permettez-moi d'ajouter quelque chose à ceci: si vous ne prenez que le compilateur barebone et supprimez tout ce qui n'est pas absolument nécessaire (comme la construction du compilateur sans profil, dépouillé, etc.), vous pouvez descendre à environ 5 Mo. Mais essayez de comparer la taille des compilateurs avec GCC. (J'ai
modifié

5

La réponse courte est que c'est parce que tous les exécutables sont liés statiquement, qu'ils peuvent contenir des informations de débogage et que les bibliothèques sont incluses dans plusieurs copies. Cela a déjà été dit par d'autres commentateurs.

La liaison dynamique est possible et réduira considérablement la taille. Voici un exemple Hello.hs:

main = putStrLn "Hello world"

Je construis avec GHC 7.4.2 sous Windows.

ghc --make -O2donne Hello.exede 1105Ks

Courir stripdessus laisse 630K

ghc --make -O2 -dynamic donne 40K

Le décapage ne laisse que 13K.

Ses dépendances sont 5 dll avec une taille totale de 9,2 Mo non supprimées et 5,7 Mo supprimées.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.