2012-06-14 15 views
13

जैसा कि मैं कृत्रिम बुद्धि में रूचि रखता हूं, मैंने हाल ही में लिस्प को एक कोशिश देने का फैसला किया। सामान्य लिस्प कंपाइलर sbcl के साथ बहुत basic application संकलित करने के बाद मैंने देखा कि परिणामस्वरूप बाइनरी बहुत बड़ी थी (लगभग 43 एमबी)। मुझे इसके कारण की दिलचस्पी है। क्या यह आम मुद्दा (सामान्य) लिस्प और इस व्यवहार की तकनीकी पृष्ठभूमि क्या है?लिस्प बाइनरी आकार

उत्तर

27

कॉमन लिस्प कार्यान्वयन में कई अलग अलग आर्किटेक्चर के होते हैं:

  • दुभाषिया
  • बाइट कोड इंजन सी संकलक के माध्यम से
  • संकलन (CLISP एक उदाहरण है)
  • (ईसीएल एक उदाहरण है) देशी कोड कंपाइलर (एसबीसीएल, लिस्पॉर्क्स, क्लोजर सीएल)

आम तौर पर इंटरप्रेटर और बाइट कोड ई इंजन स्मृति की सबसे छोटी राशि का उपयोग करें। इस प्रकार सीएलआईएसपी बहुत छोटा है। एसबीसीएल ओटीओएच अपेक्षाकृत बड़े देशी कोड उत्पन्न करता है।

दूसरे, वहाँ कई अलग अलग तरीकों अनुप्रयोगों बनाने के लिए कर रहे हैं:

  1. एक छवि
  2. बचत सी कोड

के संकलन एक अनुकूलित छवि

  • बचत प्लस कुछ और की तरह डीएलएल के लिए संकलन।

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

    विकास के दौरान अक्सर कोड और डेटा लोड करने के लिए समय बचाने के लिए ऐसे अनौपचारिक अनुप्रयोगों या छवियों (बाहरी रनटाइम के साथ) के साथ काम (एस/एड) काम करते हैं। मैंने इसे खुद छवियों के साथ उपयोग किया है जो 100 एमबी से बड़े थे।

    उदाहरण के लिए LispWorks 1 और 2 करता है। इसमें एक डिलीवरी प्रक्रिया है जहां आप चुनिंदा सामान (जैसे दस्तावेज, कंपाइलर, स्रोत संदर्भ, ... जैसी कुछ कार्यक्षमता) को हटा सकते हैं। यह एक पेड़-शेकर का भी उपयोग कर रहा है, जो अप्रयुक्त कार्यक्षमता को हटा सकता है।

    किसी छवि को अनुकूलित करने से इसे कुछ संपीड़ित तरीके से लिखना और स्टार्ट अप पर इसे कम करने का भी अर्थ हो सकता है। एसबीसीएल उदाहरण के लिए इसकी अनुमति देता है।

    संस्करण 3 अतीत में किया गया था, लेकिन वर्तमान में उपयोग में नहीं है (कुछ विशेष उपकरणों और ऐप्स के अलावा)। Thinlisp, स्टेला, CycL, ... ऐसे वितरण उपकरण हैं। अतीत में इस तरह के एक उपकरण के लिए एक वाणिज्यिक विक्रेता भी था (लेकिन यह अब अस्तित्व में नहीं है, आईआईआरसी इसका अंतिम मालिक ओरेकल था)। अद्यतन: वास्तव में mocl, आईओएस और एंड्रॉइड के लिए हाल ही में एक आम लिस्प एप्लिकेशन जनरेटर यह करता है। यह आम लिस्प का एक बड़ा सबसेट लेता है और इसे छोटे, स्टैंड-अलोन मोबाइल ऐप्स में संकलित करता है। उदाहरण के लिए आईओएस पर यह ऐप्पल के प्रदत्त सी संकलक के लिए कॉम्पैक्ट सी कोड उत्पन्न करता है।

  • +0

    धन्यवाद, यही वह है जिसे मैं खोज रहा था! –

    +5

    ईसीएल सी को संकलित करता है और साझा पुस्तकालयों का उपयोग करके छोटे निष्पादन योग्य बनाता है, लेकिन यह कई तरीकों से सीमित है। –

    +3

    ईसीएल में सी कंपाइलर के माध्यम से देशी कोड में बाइटकोड कंपाइलर/दुभाषिया और संकलन दोनों हैं। ईसीएल आमतौर पर एसबीसीएल और सीसीएल की तुलना में धीमी है, लेकिन बहुत छोटी बाइनरी पैदा करता है। मुझे यकीन नहीं है कि @ सैमुएल एडविनवार्ड का अर्थ सीमाओं से है (तथ्य यह है कि यह धीमा है) - यह काफी पूर्ण है और इसकी कई विशेषताएं हैं। क्या आप उस पर थोड़ा सा विस्तार कर सकते हैं? –