¿Por qué es GHC tan grande / grande?

¿Hay una respuesta simple: por qué es tan grande el GHC?

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

No me interesa el evangelismo de "Por qué no debería importarme el tamaño si Haskell es la herramienta adecuada"; Esta es una pregunta técnica.

Es un poco tonto realmente. Cada biblioteca que viene con GHC se proporciona en no menos de 4 sabores :

• estático
• dinámica
• perfilado
• GHCi

La versión GHCi es solo la versión estática vinculada en un solo .oarchivo. Las otras tres versiones también tienen su propio conjunto de archivos de interfaz ( .hiarchivos). Las versiones perfiladas parecen tener aproximadamente el doble del tamaño de las versiones sin perfil (lo cual es un poco sospechoso, debería investigar por qué es así).

Recuerde que GHC en sí es una biblioteca , por lo que obtendrá 4 copias de GHC. No solo eso, sino que el binario GHC en sí está estáticamente vinculado, por lo que son 5 copias de GHC.

Recientemente lo hicimos para que GHCi pudiera usar los .aarchivos estáticos . Eso nos permitirá deshacernos de uno de estos sabores. A largo plazo, deberíamos vincular dinámicamente GHC, pero ese es un cambio mayor porque eso implicaría hacer que la vinculación dinámica sea la predeterminada: a diferencia de C, con GHC debe decidir por adelantado si va a vincular dinámicamente o no. Y necesitamos más cambios (por ejemplo, Cabal y el sistema de paquetes, entre otras cosas) antes de que esto sea realmente práctico.

Probablemente deberíamos comparar manzanas con manzanas y naranjas con naranjas. JRE es un tiempo de ejecución, no un kit para desarrolladores. Podemos comparar: el tamaño de origen del kit de desarrollo, el tamaño del kit de desarrollo compilado y el tamaño compilado del tiempo de ejecución mínimo.

El paquete fuente OpenJDK 7 es de 82 MB (download.java.net/openjdk/jdk7) frente al paquete fuente GHC 7, que es de 23 MB (haskell.org/ghc/download_ghc_7_0_1). GHC no es grande aquí. Tamaño de tiempo de ejecución: openjdk-6-jre-headless en Ubuntu es de 77 MB sin comprimir frente a Haskell helloworld, vinculado estáticamente con su tiempo de ejecución, que es <1 MB. GHC no es grande aquí.

Donde GHC es grande, es el tamaño del kit de desarrollo compilado:

GHC en sí ocupa 270 MB, y con todas las bibliotecas y utilidades que se unen, ocupa más de 500 MB. Y sí, es mucho, incluso con bibliotecas base y una herramienta de compilación / administrador de dependencias. La plataforma de desarrollo de Java es más pequeña.

GHC:

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

contra OpenJDK con dependencias:

$ 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

Pero todavía tiene más de 100 MB, no 26 MB mientras escribe.

Las cosas pesadas en ghc6 y ghc6-prof son:

$ 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

Tenga en cuenta lo grande que es libHSghc-6.12.1_p.a. Por lo tanto, la respuesta parece ser la vinculación estática y las versiones de creación de perfiles para todas las bibliotecas disponibles.

Mi suposición: montones y montones de enlaces estáticos. Cada biblioteca necesita vincular estáticamente sus dependencias, que a su vez necesitan vincular estáticamente las suyas y las soforth. Y todo esto se compila a menudo con y sin perfiles, e incluso sin perfiles, los binarios no se eliminan y, por lo tanto, contienen mucha información del depurador.

Porque agrupa gcc y un montón de bibliotecas, todas vinculadas estáticamente.

Al menos en Windows.

Aquí está el desglose del tamaño del directorio en mi caja:

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

Parece que el directorio más grande (123 MB) son los binarios para compilar el compilador. Los documentos pesan unos asombrosos 65 MB. El tercer lugar es Cabal con 41 MB.

El directorio bin es de 33 MB, y creo que solo un subconjunto de eso es lo que técnicamente se requiere para construir aplicaciones Haskell.

La respuesta breve es que es porque todos los ejecutables están vinculados estáticamente, pueden tener información de depuración y las bibliotecas están incluidas en varias copias. Esto ya lo han dicho otros comentaristas.

La vinculación dinámica es posible y reducirá drásticamente el tamaño. Aquí hay un ejemplo Hello.hs:

main = putStrLn "Hello world"

Construyo con GHC 7.4.2 en Windows.

ghc --make -O2da Hello.exede 1105Ks

Correr stripen él deja 630K

ghc --make -O2 -dynamic da 40K

Pelarlo deja solo 13K.

Sus dependencias son 5 dlls con un tamaño total de 9.2 MB sin tirar y 5.7 MB sin tirar.