Pourquoi le GHC est-il si grand / gros?

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.

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.

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é:

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.

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.

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

Au moins sur Windows.

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.

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.