Почему GHC такой большой / большой?

Question

Есть простой ответ: почему GHC такой большой?

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

Не заинтересован в евангелизации "Почему мне не нужно заботиться о размере, если Хаскелл - правильный инструмент"; это технический вопрос.

Answer 1

Это немного глупо на самом деле. Каждая библиотека, которая поставляется с GHC, представлена ​​в не менее чем 4 вариантах :

• статические
• динамический
• профнастил
• GHCi

Версия GHCi - это просто статическая версия, связанная вместе в одном файле .o. Все остальные три версии также имеют свой собственный набор файлов интерфейса (.hi файлы). Профилированные версии кажутся примерно в два раза больше непрофильных версий (что немного подозрительно, я должен разобраться, почему это так).

Помните, что GHC сама по себе является библиотекой , поэтому вы получаете 4 копии GHC. Кроме того, двоичный файл GHC статически связан, так что это 5 копий GHC.

Недавно мы сделали так, чтобы GHCi мог использовать статические .a файлы. Это позволит нам избавиться от одного из этих ароматов. В более долгосрочной перспективе мы должны динамически связывать GHC, но это большее изменение, потому что это повлечет за собой динамическое связывание по умолчанию - в отличие от C, с GHC вы должны заранее решить, собираетесь ли вы динамически связывать или нет. И нам нужно больше изменений (например, в Cabal и системе пакетов, среди прочего), прежде чем это станет действительно практичным.

Answer 2

Вероятно, мы должны сравнить яблоки с яблоками и апельсины с апельсинами. JRE - это среда выполнения, а не набор разработчика. Мы можем сравнить: исходный размер комплекта разработки, размер скомпилированного комплекта разработки и скомпилированный размер минимального времени выполнения.

Исходный пакет OpenJDK 7 составляет 82 МБ (download.java.net/openjdk/jdk7) по сравнению с исходным пакетом GHC 7, который составляет 23 МБ (haskell.org/ghc/download_ghc_7_0_1). GHC здесь не большой. Размер среды выполнения: openjdk-6-jre-headless в Ubuntu составляет 77 МБ в несжатом состоянии по сравнению с Helloworld Haskell, статически связанным с его средой выполнения, которая составляет <1 МБ. GHC здесь не большой. </p>

Если GHC большой, это размер скомпилированного комплекта разработки:

Самому GHC требуется 270 МБ, а вместе со всеми библиотеками и утилитами он занимает более 500 МБ. И да, это много, даже с базовыми библиотеками и инструментом построения / менеджером зависимостей. Платформа разработки Java меньше.

GHC:

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

против OpenJDK с зависимостями:

$ 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

Но это все равно больше 100 МБ, а не 26 МБ, как вы пишете.

Тяжелые вещи в ghc6 и ghc6-prof:

$ 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

Обратите внимание, насколько велика libHSghc-6.12.1_p.a. Таким образом, ответом для каждой библиотеки является статическое связывание и профилирование версий.

Answer 3

Мое предположение - много-много статических ссылок. Каждая библиотека должна статически связывать свои зависимости, которые, в свою очередь, должны статически связывать свои и другие. И все это часто компилируется как с профилированием, так и без него, и даже без профилирования двоичные файлы не удаляются и поэтому содержат много информации отладчика.

Answer 4

Поскольку он объединяет gcc и несколько библиотек, все статически связаны.

По крайней мере, в Windows.

Answer 5

Краткий ответ: все исполняемые файлы статически связаны, могут содержать отладочную информацию и библиотеки включены в несколько копий. Об этом уже говорили другие комментаторы.

Динамическое связывание возможно и значительно уменьшит размер. Вот пример Hello.hs:

main = putStrLn "Hello world"

Я строю с помощью GHC 7.4.2 в Windows.

ghc --make -O2 дает Hello.exe из 1105Ks

Бег strip на нем уходит 630К

ghc --make -O2 -dynamic дает 40K

Сняв его, осталось всего 13K.

Это зависимости 5 dll с общим размером 9,2 МБ без зачистки и 5,7 МБ с зарезкой.

Answer 6

Вот разбивка размера каталога на моей коробке:

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

Похоже, самый большой каталог (123 МБ) - это двоичные файлы для компиляции самого компилятора. Документы весят поразительные 65 МБ. Третье место - Кабал на 41 МБ.

Каталог bin имеет размер 33 МБ, и я думаю, что только часть из этого является технически необходимой для создания приложений на Haskell.