GHC इतना बड़ा / बड़ा क्यों है?

147

क्या एक सरल उत्तर है: जीएचसी इतना बड़ा क्यों है?

OCaml: 2MB
पायथन: 15 एमबी
SBCL: 9MB
OpenJRE - 26MB
जीएचसी: 113 एमबी

इंजीलवाद में दिलचस्पी नहीं है "अगर हास्केल सही उपकरण है तो मुझे आकार की परवाह क्यों नहीं करनी चाहिए"; यह एक तकनीकी प्रश्न है।

haskell ghc

— क्रिस्टोफर ने किया
स्रोत

1

यह 500MB आपको कहां से मिल रहा है? मेरा GHC उस बड़े के करीब नहीं है।

— याकूब

जब तक आप सभी पुस्तकालयों की गिनती नहीं करते, मुझे लगता है ...

— याकूब

क्षमा करें, मैं एक पैकेज प्रबंधक डाउनलोड बंद करने जा रहा था जिसमें कुछ dep शामिल हैं। मैंने इसे वेब साइट से डाउनलोड आकार को प्रतिबिंबित करने के लिए अद्यतन किया। मैंने एक सारांश संपादित किया, लेकिन यह यहां (अभी तक?) नहीं दिखाई दिया। मुझे लगता है कि सवाल अभी भी खड़ा है। यह बड़ा है।

— क्रिस्टोफर ने

20

संभवतः हमें सेब की तुलना सेब और संतरे से करनी चाहिए। JRE एक रनटाइम है, न कि डेवलपर किट। OpenJDK 7 स्रोत बंडल, 82 MB ( download.java.net/openjdk/jdk7 ) बनाम GHC 7 स्रोत बंडल, 23 MB ( haskell.org/ghc/download_ghc_7__1_1 )। अब रनटाइम: उबंटू पर ओपनजडक-6-जेआर-हेडलेस, 77 एमबी असम्पीडित बनाम हास्केल हेलोवर्ल्ड, स्टेटिकली इसके रनटाइम के साथ जुड़ा हुआ है, <1 एमबी।

— sastanin

आज मैं 2014 के आकार पर उत्सुक था। ऐसा लगता है कि तर्क अभी भी पकड़ में है। मुझे URLS मिला: 1.GHC haskell.org/ghc/download_ghc_7_8_3 ; 2.OpenJCK packages.ubuntu.com/precise/openjdk-7-jdk

— AnneTheAgile

187

यह वास्तव में थोड़ा मूर्खतापूर्ण है। GHC के साथ आने वाली प्रत्येक लाइब्रेरी को 4 से कम स्वादों में प्रदान किया जाता है :

स्थिर
गतिशील
प्रोफाइल
GHCi

GHCi संस्करण एक ही .oफ़ाइल में एक साथ जुड़ा हुआ स्थिर संस्करण है । अन्य तीन संस्करणों में इंटरफ़ेस फ़ाइलों ( .hiफ़ाइलों) का भी अपना सेट है। प्रोफाइल किए गए संस्करण अप्रमाणित संस्करणों के आकार के बारे में दो बार लगते हैं (जो थोड़ा संदिग्ध है, मुझे यह देखना चाहिए कि वह क्यों है)।

याद रखें कि जीएचसी अपने आप में एक पुस्तकालय है , इसलिए आपको जीएचसी की 4 प्रतियां मिल रही हैं। इतना ही नहीं, बल्कि जीएचसी बाइनरी ही स्टेटिक रूप से जुड़ी हुई है, इसलिए यह जीएचसी की 5 प्रतियां हैं।

हमने हाल ही में इसे बनाया है ताकि जीएचसीआई स्टैटिक .aफाइलों का उपयोग कर सके । इससे हमें इनमें से किसी एक फ्लेवर से छुटकारा मिलेगा। लंबे समय तक, हमें गतिशील रूप से जीएचसी को लिंक करना चाहिए, लेकिन यह एक बड़ा बदलाव है क्योंकि यह डिफॉल्ट को गतिशील लिंकिंग बना देगा - सी के विपरीत, जीएचसी के साथ आपको यह तय करना होगा कि आप डायनामिक रूप से लिंक करने जा रहे हैं या नहीं। इससे पहले कि यह वास्तव में व्यावहारिक हो, हमें और अधिक बदलाव (उदाहरण के लिए केबल और पैकेज सिस्टम, अन्य चीजों के साथ) की आवश्यकता है।

— साइमन मार्लो
स्रोत

16

और यहाँ मुझे लगा कि यह सब तर्क है जो हास्केल प्रदान करता है: आलसी मूल्यांकन, प्रकार का अनुमान, आदि

— mcandre

4

तो, 113MB / 4 ~ = 28MB, अभी भी OpenJRE से बड़ा है ... लेकिन विचार करें कि GHC OpenJDK के लिए तुलनीय है, न केवल JRE से, यह मुझे बेहतर महसूस कराता है।

— पृथ्वी इंजन

1

अब मुझे लगता है कि जीएचसी डायनेमिक लिंकिंग का उपयोग करता है, शायद डॉ @Simon मार्लो के चार फ्लेवर के संपीड़न के लिए विचार अधिक व्यावहारिक है? उद्धृत: 1. # 3658 (गतिशील रूप से GHCi लिंक करें (और सिस्टम लिंकर का उपयोग करें) जो इसका समर्थन करते हैं) - GHC ghc.haskell.org/trac/ghc/ticket/3658 ; 2. "8266 (मैक पर गतिशील लिंकिंग) - जीएचसी ghc.haskell.org/trac/ghc/ticket/8266 ; 3. # 8376 (स्टेटिक एक्ज़िक्युटेबल + जीएचसी एपीआई (+ डायनेमिक लिंकिंग?) सेगफॉल्ट देता है) - जीएचसी

— एनी.गेल

56

संभवत: हमें सेब की तुलना सेब और संतरे से करनी चाहिए। JRE एक रनटाइम है, न कि डेवलपर किट। हम तुलना कर सकते हैं: विकास किट का स्रोत आकार, संकलित विकास किट का आकार और न्यूनतम क्रम का संकलित आकार।

OpenJDK 7 स्रोत बंडल 82 एमबी (download.java.net/openjdk/jdk7) बनाम GHC 7 स्रोत बंडल है, जो 23 एमबी (haskell.org/ghc/download_ghc_7_0_1) है। जीएचसी यहां बड़ा नहीं है। रनटाइम आकार: उबंटू पर ओपनजडक-6-जेआर-हेडलेस 77 एमबी असम्पीडित बनाम हास्केल हेलोवर्ल्ड, स्टेटिकली इसके रनटाइम के साथ जुड़ा हुआ है, जो <1 एमबी है। जीएचसी यहां बड़ा नहीं है।

जहां जीएचसी बड़ा है, संकलित विकास किट का आकार है:

GHC डिस्क उपयोग

जीएचसी खुद 270 एमबी लेती है, और सभी पुस्तकालयों और उपयोगिताओं के साथ जो 500 एमबी से अधिक होती है। और हाँ, यह बहुत कुछ है, यहां तक कि आधार पुस्तकालयों और एक निर्माण उपकरण / निर्भरता प्रबंधक के साथ भी। जावा विकास मंच छोटा है।

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। ऐसा लगता है कि यह उत्तर स्थैतिक लिंकिंग और प्रोफाइलिंग संस्करणों के लिए है।

— sastanin
स्रोत

9

मेरा अनुमान है - बहुत सारे और बहुत सारे स्थिर लिंकिंग। प्रत्येक पुस्तकालय को अपनी निर्भरता को सांख्यिकीय रूप से जोड़ने की आवश्यकता होती है, जो बदले में सांख्यिकीय रूप से उनके और सोफे को जोड़ने की आवश्यकता होती है। और यह सब अक्सर प्रोफाइलिंग के साथ और बिना, दोनों के साथ संकलित किया जाता है, और यहां तक कि प्रोफाइलिंग के बिना बायनेरीज़ को छीन नहीं लिया जाता है और इसलिए बहुत सी डिबगर जानकारी रखते हैं।

— sclv
स्रोत

2

मैं शायद बुरा नहीं मानूंगा अगर जीएचसी एक पूरे-कार्यक्रम में बदल जाता है, लगभग सब कुछ मॉडल को recompile, jhc के समान। यह तेजी से संकलित कर सकता है यदि यह स्वैपिंग से 'ld' रखेगा।

— जॉन एल

8

क्योंकि यह जीसीसी और पुस्तकालयों के एक समूह को बंडल करता है , जो सभी सांख्यिकीय रूप से जुड़े हुए हैं।

कम से कम विंडोज पर।

— मार्को
स्रोत

12

नहीं, लिनक्स पर नहीं। यह केवल gcc पर निर्भर करता है। क्योंकि विंडोज़ के "वितरण" में कोई gcc नहीं है, इसलिए इसे ghc के साथ आना होगा।

— कोमोनॉड

5

यहां मेरे बॉक्स पर डायरेक्टरी साइज ब्रेकडाउन है

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

ऐसा लगता है कि संकलक को संकलित करने के लिए सबसे बड़ी निर्देशिका (123 एमबी) बायनेरिज़ है। दस्तावेजों का वजन आश्चर्यजनक 65 एमबी है। तीसरे स्थान पर 41 एमबी पर काबल है।

बिन निर्देशिका 33 एमबी है, और मुझे लगता है कि केवल एक उपसमुच्चय है जो तकनीकी रूप से हास्केल अनुप्रयोगों के निर्माण के लिए आवश्यक है।

— याकूब
स्रोत

6

मुझे इसमें कुछ जोड़ना चाहिए: यदि आप केवल नंगे कोने संकलक लेते हैं और पूरी तरह से आवश्यक कुछ भी नहीं लेते हैं, (जैसे कि संकलक को अनफ़िल्टर्ड, छीन लिया आदि का निर्माण करना), तो आप लगभग 5 एमबी तक जा सकते हैं। लेकिन कंपाइलर्स के आकार की तुलना जीसीसी से करने की कोशिश करें। (टिप्पणी संपादित की है, इसलिए मुझे इसे हटाना पड़ा ... क्षमा करें)

— 14

5

संक्षिप्त उत्तर यह है कि ऐसा इसलिए है क्योंकि सभी निष्पादक सांख्यिकीय रूप से जुड़े हुए हैं, उनमें डीबग जानकारी हो सकती है और लाइब्रेरी कई प्रतियों में शामिल हैं। यह अन्य टिप्पणीकारों द्वारा पहले ही कहा जा चुका है।

डायनेमिक लिंकिंग संभव है और आकार को नाटकीय रूप से कम कर देगा। यहाँ एक उदाहरण है Hello.hs:

main = putStrLn "Hello world"

मैं विंडोज पर जीएचसी 7.4.2 के साथ निर्माण करता हूं।

ghc --make -O2Hello.exe1105Ks का देता है

इस पर चलने से strip630K निकलता है

ghc --make -O2 -dynamic 40K देता है

स्ट्रिपिंग यह सिर्फ 13K छोड़ देता है।

यह निर्भरता 5 एमबीएस है, जिसमें 9.2 एमबी के कुल आकार के साथ 5 एमबी हैं और 5.7 एमबी छीन लिए गए हैं।

— nponeccop
स्रोत