Dlaczego GHC jest tak duży / duży?

Czy jest prosta odpowiedź: dlaczego GHC jest tak duży?

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

Nie interesuje się ewangelizacją: „Dlaczego nie powinienem przejmować się rozmiarem, jeśli Haskell jest właściwym narzędziem”; to jest kwestia techniczna.

To naprawdę trochę głupie. Każda biblioteka dostarczana z GHC jest dostarczana w co najmniej 4 wersjach :

• statyczny
• dynamiczny
• profilowane
• GHCi

Wersja GHCi to po prostu wersja statyczna połączona w jednym .opliku. Pozostałe trzy wersje również mają swój własny zestaw plików interfejsu ( .hiplików). Wersje profilowane wydają się być około dwa razy większe niż wersje nieprofilowane (co jest nieco podejrzane, powinienem sprawdzić, dlaczego tak jest).

Pamiętaj, że sam GHC jest biblioteką , więc otrzymujesz 4 kopie GHC. Nie tylko to, ale sam plik binarny GHC jest statycznie połączony, więc jest to 5 kopii GHC.

Niedawno zrobiliśmy to tak, że GHCi może używać .aplików statycznych . To pozwoli nam pozbyć się jednego z tych smaków. W dłuższej perspektywie powinniśmy dynamicznie łączyć GHC, ale to większa zmiana, ponieważ oznaczałoby to uczynienie dynamicznego łączenia jako domyślnego - w przeciwieństwie do C, w przypadku GHC musisz z góry zdecydować, czy chcesz łączyć się dynamicznie, czy nie. I potrzebujemy więcej zmian (np. Między innymi w Cabal i systemie pakietów), zanim stanie się to naprawdę praktyczne.

Prawdopodobnie powinniśmy porównać jabłka do jabłek, a pomarańcze do pomarańczy. JRE to środowisko wykonawcze, a nie zestaw deweloperski. Możemy porównać: rozmiar źródła zestawu deweloperskiego, rozmiar skompilowanego zestawu deweloperskiego i skompilowany rozmiar minimalnego środowiska uruchomieniowego.

Pakiet źródłowy OpenJDK 7 ma 82 MB (download.java.net/openjdk/jdk7) w porównaniu z pakietem źródłowym GHC 7, czyli 23 MB (haskell.org/ghc/download_ghc_7_0_1). GHC nie jest tu duży. Rozmiar środowiska wykonawczego: openjdk-6-jre-headless na Ubuntu to 77 MB nieskompresowanego w porównaniu z Haskell helloworld, statycznie połączonym z jego uruchomieniem, które wynosi <1 MB. GHC nie jest tu duży.

Gdzie GHC jest duży, jest to rozmiar skompilowanego zestawu deweloperskiego:

Sam GHC zajmuje 270 MB, a wraz ze wszystkimi bibliotekami i narzędziami, które są razem, zajmuje ponad 500 MB. I tak, to dużo, nawet z podstawowymi bibliotekami i narzędziem do budowania / menedżerem zależności. Platforma programistyczna Java jest mniejsza.

GHC:

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

przeciwko OpenJDK z zależnościami:

$ 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

Ale nadal jest więcej niż 100 MB, a nie 26 MB, gdy piszesz.

Ciężkie rzeczy w ghc6 i ghc6-prof to:

$ 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

Zwróć uwagę, jak duży jest libHSghc-6.12.1_p.a. Więc odpowiedzią wydają się być statyczne wersje linkowania i profilowania dla każdej biblioteki.

Domyślam się - dużo, wiele statycznych linków. Każda biblioteka musi łączyć statycznie swoje zależności, które z kolei muszą łączyć statycznie swoje i sofort. I to wszystko jest często kompilowane zarówno z profilowaniem, jak i bez niego, a nawet bez profilowania pliki binarne nie są usuwane, więc zawierają wiele informacji debugera.

Ponieważ zawiera gcc i kilka bibliotek, wszystkie połączone statycznie.

Przynajmniej w systemie Windows.

Oto podział rozmiaru katalogu na moim pudełku:

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

Wygląda na to, że największy katalog (123 MB) to pliki binarne do kompilacji samego kompilatora. Dokumenty ważą zdumiewające 65 MB. Trzecie miejsce zajmuje Cabal na 41 MB.

Katalog bin ma 33 MB i myślę, że tylko jego część jest technicznie wymagana do tworzenia aplikacji Haskell.

Krótka odpowiedź jest taka, że ​​wszystkie pliki wykonywalne są statycznie połączone, mogą zawierać informacje o debugowaniu, a biblioteki są zawarte w wielu kopiach. Zostało to już powiedziane przez innych komentatorów.

Dynamiczne łączenie jest możliwe i znacznie zmniejszy rozmiar. Oto przykład Hello.hs:

main = putStrLn "Hello world"

Buduję z GHC 7.4.2 na Windows.

ghc --make -O2daje Hello.exe1105Ks

Bieganie stripna nim pozostawia 630K

ghc --make -O2 -dynamic daje 40K

Po usunięciu pozostawia tylko 13K.

Jego zależności to 5 bibliotek dll o łącznym rozmiarze 9,2 MB po usunięciu i 5,7 MB po usunięciu.