secundaria programa para horarios hacer gratis clases haskell ghc

haskell - programa - ¿Por qué es GHC tan grande/grande?



programa para hacer horarios de clases de secundaria gratis (6)

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

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

No estoy interesado en el evangelismo de "Por qué no me debería importar el tamaño si Haskell es la herramienta correcta"; esta es una pregunta técnica

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 en 41 MB.

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

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 enlazada en un solo archivo .o . Las otras tres versiones tienen su propio conjunto de archivos de interfaz (archivos .hi ) también. Las versiones perfiladas parecen ser aproximadamente el doble del tamaño de las versiones no perfiladas (lo cual es un poco sospechoso, debería ver por qué).

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

Hace poco logramos 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 el GHC, pero ese es un cambio mayor porque implicaría establecer un enlace dinámico al predeterminado: 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, para Cabal y el sistema de paquetes, entre otras cosas) antes de que esto sea realmente práctico.

La respuesta breve 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 copias múltiples. Esto ya lo han dicho otros comentaristas.

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

main = putStrLn "Hello world"

Construyo con GHC 7.4.2 en Windows.

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

Correr strip en él deja 630K

ghc --make -O2 -dynamic da 40K

Desnudando deja solo 13K.

Sus dependencias son 5 dlls con un tamaño total de 9,2 MB sin eliminar y 5,7 MB despojados.

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

Porque agrupa gcc y un grupo de bibliotecas, todas vinculadas estáticamente.

Al menos en Windows.

Probablemente deberíamos comparar las manzanas con las manzanas y las naranjas con las naranjas. JRE es un tiempo de ejecución, no un kit de desarrollo. Podemos comparar: tamaño de 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 de orígenes OpenJDK 7 es de 82 MB (download.java.net/openjdk/jdk7) frente al paquete de orígenes 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 tiene 77 MB sin comprimir frente a Haskell helloworld, enlazado 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í tiene 270 MB, y con todas las bibliotecas y utilidades que se combinan, 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 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 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 qué tan grande es libHSghc-6.12.1_p.a . Entonces, la respuesta parece ser la vinculación estática y las versiones de creación de perfiles para cada biblioteca.