फाइलसाइज में हास्केल/जीएचसी निष्पादन योग्य इतने बड़े क्यों हैं?

Question

संभव डुप्लिकेट:
Small Haskell program compiled with GHC into huge binary

हाल ही में मैंने देखा है कि कैसे बड़े हास्केल निष्पादनयोग्य हैं। नीचे दी गई सब कुछ जीएचसी 7.4.1 पर लिनक्स पर -O2 के साथ संकलित की गई थी।

1. हैलो वर्ल्ड (main = putStrLn "Hello World!") 800 से अधिक कीबी है। strip पर चलने से 500 कीबी तक फाइलसाइज कम हो जाती है; संकलन में -dynamic भी जोड़ने से मुझे 400 कीबी के चारों ओर एक पट्टी निष्पादन योग्य के साथ छोड़ने में मदद नहीं मिलती है।

2. पारसीक से जुड़े एक बहुत ही प्राचीन उदाहरण को संकलित करना 1.7 एमआईबी फ़ाइल उत्पन्न करता है।

   -- File: test.hs 
   import qualified Text.ParserCombinators.Parsec as P 
   import Data.Either (either) 
   
   -- Parses a string of type "x y" to the tuple (x,y). 
   testParser :: P.Parser (Char, Char) 
   testParser = do 
       a <- P.anyChar 
       P.char ' ' 
       b <- P.anyChar 
       return (a, b) 
   
   -- Parse, print result. 
   str = "1 2" 
   main = print $ either (error . show) id . P.parse testParser "" $ str 
   -- Output: ('1','2') 
   

   Parsec एक बड़ा पुस्तकालय हो सकता है, लेकिन मैं केवल एक छोटे सबसेट का उपयोग कर रहा है, और वास्तव अनुकूलित कोर से ऊपर द्वारा बनाया गया कोड निष्पादन की तुलना में नाटकीय रूप से छोटा होता है:

   $ ghc -O2 -ddump-simpl -fforce-recomp test.hs | wc -c 
   49190 (bytes) 
   

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

ऐसे विशाल आकार के निष्पादन योग्य क्यों हैं? क्या मैं इसके बारे में कुछ कर सकता हूं (गतिशील लिंकिंग को छोड़कर)?

Answer 1

मेरी समझ यह है कि यदि आप पैकेज X, से एक ही फ़ंक्शन का उपयोग करते हैं तो संपूर्ण पैकेज स्थिर रूप से लिंक हो जाता है। मुझे नहीं लगता कि जीएचसी वास्तव में फ़ंक्शन-बाय-फ़ंक्शन को लिंक करता है। (जब तक आप "विभाजित ऑब्जेक्ट्स" हैक का उपयोग नहीं करते हैं, जो "लिंकर को फिक्र करने के लिए जाता है"।)

लेकिन यदि आप गतिशील रूप से लिंक कर रहे हैं, तो इसे ठीक करना चाहिए। तो मुझे यकीन नहीं है कि यहां क्या सुझाव देना है ...

(मुझे पूरा यकीन है कि मैंने एक ब्लॉग पोस्ट देखा था जब गतिशील लिंकिंग पहली बार बाहर आई थी, हैलो वर्ल्ड को 2 केबी बाइनरी में संकलित किया गया था। जाहिर है, मुझे यह ब्लॉग नहीं मिल रहा है अब ... grr।)

क्रॉस-मॉड्यूल अनुकूलन पर भी विचार करें। यदि आप एक पारसी पार्सर लिख रहे हैं, तो संभव है कि जीएचसी सभी पार्सर परिभाषाओं को रेखांकित करे और उन्हें सबसे कुशल कोड तक सरल बनाये। और, निश्चित रूप से पर्याप्त है, हैस्केल की आपकी कुछ पंक्तियों ने 50 केबी कोर का उत्पादन किया है। मशीन कोड को संकलित करते समय 37x बड़ा होना चाहिए? मुझे नहीं पता। आप शायद अगले चरणों में उत्पादित एसटीजी और सीएमएम कोड को देखने का प्रयास कर सकते हैं। (माफ करना, मैं अपने सिर के ऊपर से संकलक झंडे को याद नहीं है ...)

Answer 2

प्रभावी ढंग से निष्पादन योग्य ग्लासगो हास्केल कंपाइलर द्वारा उत्पादित आप पर की

• उपयोग ध्यान केंद्रित करने के लिए है के आकार को कम करने के लिए -dynamic विकल्प के साथ गतिशील लिंकिंग ghc को पास किया गया है ताकि मॉड्यूल कोड को साझा (गतिशील) पुस्तकालयों का उपयोग करके अंतिम निष्पादन योग्य में बंडल नहीं किया जाएगा। सिस्टम में इन जीएचसी पुस्तकालयों के साझा संस्करणों का अस्तित्व आवश्यक है!
• अंतिम निष्पादन योग्य (एफईई) की डीबगिंग सूचनाओं को हटा रहा है।जीएनयू के binutils की पट्टी उपकरण)
• अप्रयुक्त मॉड्यूल के हटाने के आयात द्वारा() गतिशील जोड़ने पर लाभ

सरल हैलो दुनिया उदाहरण अंतिम आकार की है 9 किबा और Parsec परीक्षण के बारे में 28 किबा (दोनों की उम्मीद नहीं है 64 बिट लिनक्स एक्जिक्यूटिव) जो मुझे उच्च स्तर की भाषा कार्यान्वयन के लिए काफी छोटा और स्वीकार्य लगता है।