it-swarm.dev

¿Por qué GHC es tan grande/grande?

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

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

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

144
Christopher Done

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 de GHCi es solo la versión estática enlazada en un solo archivo .o. Las otras tres versiones también tienen su propio conjunto de archivos de interfaz (archivos .hi). Las versiones perfiladas parecen tener aproximadamente el doble de tamaño que las versiones no perfiladas (lo cual es un poco sospechoso, debería analizar el motivo).

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

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

182
Simon Marlow

Probablemente deberíamos comparar manzanas con manzanas y naranjas con naranjas. JRE es un tiempo de ejecución, no un kit de desarrollador. Podemos comparar: el tamaño de la fuente 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 de OpenJDK 7 es de 82 MB (descarga.Java.net/openjdk/jdk7) vs el paquete fuente de GHC 7, que es de 23 MB (haskell.org/ghc/download_ghc_7_0_1). GHC no es grande aquí. El tamaño del tiempo de ejecución: openjdk-6-jre-headless en Ubuntu es de 77 MB sin comprimir frente a Hasellow Helloworld, estáticamente vinculado 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 disk usage

GHC toma 270 MB, y con todas las bibliotecas y utilidades que se juntan, toma 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 sigue siendo más de 100 MB, no 26 MB mientras escribe.

Las cosas de peso pesado 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. Así que la respuesta parece ser la vinculación estática y las versiones de perfiles para cada biblioteca.

55
sastanin

Mi conjetura - un montón y mucho de enlace estático. Cada biblioteca necesita vincular estáticamente sus dependencias, que a su vez deben vincular estáticamente las suyas y las de soforth. Y todo esto se compila a menudo con y sin perfilar, e incluso sin perfilar los archivos binarios no se eliminan y, por lo tanto, contienen mucha información del depurador.

9
sclv

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

Al menos en Windows.

8
Marko

La respuesta corta es que se debe a que todos los ejecutables están vinculados estáticamente, pueden tener información de depuración en ellos y las bibliotecas se incluyen en varias copias. Esto ya ha sido dicho por otros comentaristas.

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

main = putStrLn "Hello world"

Construyo con GHC 7.4.2 en Windows.

ghc --make -O2 da Hello.exe de 1105Ks

Ejecutando strip en ella deja 630K

ghc --make -O2 -dynamic da 40K

Quitandolo deja solo 13K.

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

5
nponeccop

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

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

Parece que el directorio más grande (123 MB) son los binarios para compilar el compilador. Los documentos pesan en un asombroso 65 MB. El tercer puesto 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.

4
Jacob