LLVM, तोता, JVM, PyPy + अजगर

Question

क्या, कुछ भाषाओं के विकास LLVM/तोता से कुछ के साथ कुछ अनुकूलित तकनीकों के लिए उदाहरण के लिए अजगर में समस्या है।

PyPy, LLVM, तोता साझा मंच के विकास के लिए मुख्य प्रौद्योगिकियों हैं।
मैं इस तरह देखें:

• PyPy - ढांचा वी एम का निर्माण के साथ अनुकूलित वीएम में अजगर
  तो यह काफी सामान्य समाधान के लिए बनाने के लिए। >
  
• PyPy दृश्यपटल - ->
• PyPy आंतरिक कोड - बाईटकोड ->
• PyPy अनुकूलन ->
• छोड़ने PyPy कोड और
  
  1. dynamic_language_code: प्रक्रिया के रूप में नीचे सूचीबद्ध हो जाता है :
     ए। कुछ वी एम के लिए PyPy बैकएंड (JVM) की तरह
     ज। som किट बनाने के लिए खुद वीएम
     सी। प्रसंस्करण/चल PyPy आंतरिक कोड
     

I Am सही इस प्रक्रिया के बारे में? पाइथन के लिए अनुकूलित वीएम है? जो अजगर और हर भाषा संसाधन वहाँ बंद करो और यह द्वारा चल रहा हो सकता है के लिए है - विशेष रूप से डिफ़ॉल्ट रूप से वहाँ अनुकूलित PyPy कोड (कदम 5.c) के लिए वी एम में निर्माण किया जाता है?

• तोता - बहुत PyPy की तरह है, लेकिन 5.a और 5.b बिना? गतिशील प्रसंस्करण के लिए कुछ आंतरिक सुधार (तोता जादू कुकीज़)।

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

• LLVM - मैं इस बहुत PyPy के लिए, लेकिन वीएम जनरेटर के बिना समान देखते हैं। LLVM है सामान्य उपयोग:
  यह परिपक्व, (वी एम जनरेटर के बिना लेकिन), लेकिन निम्न स्तर संरचना और महान अनुकूलन/JIT तकनीक पर काम कर रहा

implemeted PyPy के रूप में समान लक्ष्य के साथ अच्छी तरह से डिजाइन वातावरण इस रूप में देखते हैं है , लेकिन तोते और ** पापी * गतिशील भाषाओं के लिए डिज़ाइन किया गया।PyPy में/तोता कुछ जटिल तकनीक लागू करने के लिए और अधिक आसान है - क्योंकि यह तो LLVM अधिक उच्च स्तर है - कृत्रिम संकलक जो बेहतर उच्च स्तर कोड को समझते हैं और बेहतर कोडांतरक कोड उत्पादन कर सकते हैं की तरह (जो मनुष्य उचित समय में नहीं लिख सकते हैं) तो, एलएलवीएम एक?

सवाल:

1. क्या मैं सही हूँ? क्या कोई कारण है कि कुछ गतिशील भाषा को पोर्ट करना बेहतर होगा उदाहरण के लिए तोता?

2. मैं तोता पर विकास अजगर पर गतिविधि दिखाई नहीं है। क्या ऐसा इसलिए है क्योंकि पाइथन सी एक्सटेंशन तोते पर काम नहीं करते हैं? एक ही समस्या PyPy

3. में है क्यों अन्य VMs LLVM/तोता को ले जाने के लिए नहीं करना चाहती। जैसे रूबी -> तोते, सीएलआर/जेवीएम -> एलएलवीएम। उनके लिए अधिक परिष्कृत समाधान में जाने के लिए बेहतर नहीं होगा? एलएलवीएम उच्च विकास प्रक्रिया में है और इसमें बड़ी कंपनियों का निवेश है।

4. मुझे पता है कि समस्या पुन: संकलित हो सकती है, अगर बाइटकोड को बदलने की आवश्यकता है, लेकिन यह अनिवार्य नहीं है - क्योंकि हम पुराने पोर्ट को आजमा सकते हैं नया एक के लिए बाईटकोड, और नए compilers (अब भी कभी भी कम जावा खुद बाईटकोड व्याख्या करने की जरूरत है - तो दृश्यपटल इसकी जांच करें और नया बाईटकोड में अनुवाद कर सकते हैं) नई बाईटकोड उत्पादन?

5. उदाहरण के लिए एलवीएम के अंदर जेवीएम पुस्तकालयों को जोड़ने के साथ क्या समस्याएं हैं (अगर हम किसी भी तरह जावा/जेवीएम/स्केल को llvm पोर्ट करते हैं)?

6. तुम मुझे सही कर सकते हैं कि मैं गलत कहीं

कुछ addings हूँ:

• How does Parrot compare to other virtual machines
• What's the benefit of Parrot VM for end-users
• What are the differences between LLVM and java/jvm

=============

स्पष्टीकरण

मैं लगाने की कैसे यह सब सॉफ्टवेयर मिलकर चाहते हैं - और दूसरे के पोर्टिंग के लिए समस्या क्या है।

Answer 1

कोई भी सामान किसी स्टैक ओवरफ्लो प्रश्नों में संभव उत्तर नहीं दे सकता है लेकिन मैं इसे एक छोटा शॉट देता हूं।

सबसे पहले 3 परियोजनाओं को हल करने में क्या समस्याएं हल होती हैं?

1. पाइप आपको उच्च स्तर की भाषा में एक दुभाषिया को लागू करने की अनुमति देता है और आपको मुफ्त में जेनरेट किया जाता है। इसके बारे में अच्छी बात यह है कि आपके पास लैंगेज और मंच के बीच निर्भरता मेल नहीं है। यही कारण है कि क्यों पाइप-क्लियर तेज है तो आयरनपीथन। अधिक यहाँ जानकारी: http://codespeak.net/pypy/dist/pypy/doc/extradoc.html -> उच्च प्रदर्शन अजगर की CLI/गतिशील के लिए JIT कम्पाइलर पीढ़ी के साथ नेट)

2. LLVM के लिए कार्यान्वयन compilers के लिए एक निम्न स्तर के बुनियादी ढांचे है। सामान्य विचार एक "उच्च स्तरीय असेंबली" होना है। सभी ऑप्टोमाइजेशन उस भाषा पर काम करते हैं। फिर कंपाइलर्स (जेआईटी या एओटी) बनाने में आपकी मदद के लिए चारों ओर बुनियादी ढांचे हैं। Llvm पर एक गतिशील भाषा को कार्यान्वित करना संभव है, लेकिन इसे अधिक काम की जरूरत है, फिर इसे पिल्ला या तोता पर लागू करना। उदाहरण के लिए, आप मुफ्त में जीसी नहीं प्राप्त कर सकते हैं (जीसीएम के साथ आप एक साथ उपयोग कर सकते हैं http://llvm.org/devmtg/2009-10/ -> vmkit वीडियो) एलवीएम पर आधारित गतिशील लैंगुग के लिए एक मंच बेहतर बनाने के प्रयास हैं: http://www.ffconsultancy.com/ocaml/hlvm/

3. मुझे तोते के बारे में इतना कुछ पता नहीं है, लेकिन जैसा कि मैं समझता हूं कि वे गतिशील लैंगुग (पर्ल, PHP, पायथन ....) के लिए विशेष रूप से एक मानक वीएम बनाना चाहते हैं। यहां समस्या जेवीएम/सीएलआर के संकलन के समान ही है, एक निर्भरता मिसमैच है, बस इतना छोटा है। वीएम अभी भी आपके लैंगेज के अर्थशास्त्र को नहीं जानता है। जैसा कि मैं तोते हैं तोते कोड उपयोगकर्ता के लिए अभी भी धीमा है।(http://confreaks.net/videos/118-elcamp2010-parrot)

अपने प्रश्न का उत्तर:

मैं सही हूँ? क्या कोई कारण है कि कुछ गतिशील भाषा को पोर्ट करना बेहतर होगा उदाहरण के लिए तोता?

प्रयास का एक प्रश्न है। अपने आप को हमेशा के लिए बनाना और आपके लिए विशिष्ट अंततः तेज़ हो जाएगा लेकिन यह बहुत अधिक प्रयास है।

मुझे तोता पर विकास पायथन पर गतिविधि नहीं दिखाई दे रही है। क्या ऐसा इसलिए है क्योंकि पाइथन सी एक्सटेंशन तोते पर काम नहीं करते हैं? पीपीपी में भी यही समस्या है।

तोता लक्ष्य निर्धारण (इस बिंदु पर) होने की संभावना PyPy पर एक लाभ नहीं होगा। ऐसा क्यों नहीं करता मैं इसे नहीं जानता।

अन्य वीएम एलएलवीएम/तोते में क्यों नहीं जाना चाहते हैं। जैसे रूबी -> तोते, सीएलआर/जेवीएम -> एलएलवीएम। उनके लिए अधिक परिष्कृत समाधान में जाने के लिए बेहतर नहीं होगा? एलएलवीएम उच्च विकास प्रक्रिया में है और इसमें बड़ी कंपनियों का निवेश है।

ठीक है उस प्रश्न में बहुत सारी चीज़ें हैं।

• जैसा कि मैंने कहा था कि एलएलवीएम को स्थानांतरित करना मुश्किल है और तोते तेज़ नहीं है (अगर मैं गलत हूं तो सही करें)।
• रूबी में रूबिनीस चुड़ैल रूबी और जैट्स में बहुत कुछ करने की कोशिश करता है (http://llvm.org/devmtg/2009-10/ -> एलएलवीएम के साथ रूबी को तेज करना)।
• एलएलवीएम पर सीएलआर/जेवीएम का कार्यान्वयन है, लेकिन दोनों के पास पहले से ही बहुत परिपक्व कार्यान्वयन हैं जिनमें बड़े निवेश हैं।
• एलएलवीएम उच्च स्तर नहीं है। अगर वहाँ बाईटकोड को बदलने की जरूरत

मैं जानता हूँ कि समस्या recompile में हो सकता है, संसाधन हैं - लेकिन यह अनिवार्य नहीं है - के रूप में हम एक नया करने के लिए पोर्ट वर्ष बाईटकोड की कोशिश कर सकते हैं, और नए compilers नई उत्पादन बाइटकोड (कभी भी कम जावा को अभी भी अपने बाइटकोड की व्याख्या करने की आवश्यकता नहीं है - तो फ्रंटेंड इसे देख सकता है और इसे नए बाइटकोड में अनुवाद कर सकता है)?

मुझे नहीं पता कि सवाल क्या है।

LLVM अंदर उदाहरण JVM पुस्तकालयों के लिए जोड़ने (यदि हम बंदरगाह किसी भी तरह जावा/JVM/स्केला LLVM करने के लिए) के साथ समस्याओं क्या हैं?

ऊपर से जुड़े वीएमकिट के वीडियो को देखें जो दिखाता है कि उन्हें कितना दूर मिला और समस्या क्या है (और उन्होंने इसे कैसे हल किया)।

तुम मुझे सही कर सकते हैं अगर मैं गलत हूँ कहीं

सामान के बहुत सारे आप ने लिखा गलत है या मैं सिर्फ anderstand नहीं है तुम क्या मतलब है, लेकिन सामान मैं जुड़ा हुआ की एक बहुत कुछ करना चाहिए सामान स्पष्ट है।

---

कुछ उदाहरण:

Clojure 

creater अपने ही वीएम और सभी पुस्तकालयों को लागू करने के सभी काम नहीं करना चाहता था। तो कहाँ जाना है? चूंकि क्लोजर एक नया लैंगेज है, इसलिए आप इसे ऐसे तरीके से बना सकते हैं जो बहुत ही गतिशील सामग्री को प्रतिबंधित करके जेवीएम जैसे मंच पर अच्छी तरह से काम करता है जैसे कि पाइथन या रूबी जैसी भाषा होती है।

Python 

भाषा (व्यावहारिक रूप से) JVM/CLR पर अच्छी तरह से काम करने के लिए बदला नहीं जा सकता। तो उन पर पाइथन लागू करने से भारी गति नहीं आती है। स्टेटिक कंपाइलर या तो बहुत अच्छी तरह से काम नहीं करेगा क्योंकि कई स्थिर गारंटी नहीं हैं। सी में एक जेआईटी लिखना तेजी से होगा लेकिन बदलना बहुत मुश्किल होगा (साइको परियोजना देखें)। एलएलवीएम जेट का उपयोग करना अनलडन निगल प्रोजेक्ट (फिर http://llvm.org/devmtg/2009-10/ -> अनलाडेन निगल: एलएलवीएम पर पायथन) द्वारा काम किया जा सकता है और इसका पता लगाया जा सकता है। कुछ लोग पाइथन में अजगर रखना चाहते थे, इसलिए उन्होंने पिल्ला शुरू कर दिया और उनका विचार वास्तव में अच्छी तरह से काम करने के लिए सीम (ऊपर देखें)। तोता भी काम कर सकता है लेकिन मैंने देखा नहीं है कि किसी ने कोशिश की है (मुक्त महसूस करें)।

---

सब कुछ पर:

मुझे लगता है कि आप उलझन में रहे हैं और मुझे लगता है कि समझ सकते हैं। अपना समय लें और पढ़ें, सुनो, जो कुछ भी आप प्राप्त कर सकते हैं उसे देखें। खुद को तनाव मत करो। इसके लिए बहुत सारे हिस्से हैं और आखिरकार आप देखते हैं कि एक साथ क्या फिट बैठता है और क्या समझ में आता है और यहां तक ​​कि जब आप बहुत कुछ जानते हैं तब भी कोई भी चर्चा कर सकता है। सवाल यह है कि एक नई भाषा को लागू करने के लिए या पुरानी भाषा को गति देने के लिए कई जवाब हैं और यदि आप 3 लोगों से पूछते हैं तो आपको तीन अलग-अलग उत्तर मिलेंगे।

Answer 2

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

जेवीएम, सीएलआर, पायपी, तोता, एलएलवीएम और बाकी सभी अलग-अलग तरीकों से विभिन्न प्रकार की समस्याओं को लक्षित करते हैं। यह कारणों के समान है कि क्रोम, फ़ायरफ़ॉक्स, सफारी और आईई सभी अपने स्वयं के जावास्क्रिप्ट इंजन का उपयोग क्यों करते हैं।

Unladen Swallow ने सीपीथॉन को एलएलवीएम लागू करने का प्रयास किया, और एलएलवीएम में अपने कुछ समय तय करने के मुद्दों को पाइथन विशिष्ट करने में किया।

पायथन-ऑन-तोता पर्ल 6 और पायथन के बीच अर्थपूर्ण अंतर से पीड़ित है, जो फ्रंट एंड संकलन प्रक्रिया के साथ समस्याएं पैदा कर रहा है, इसलिए इस क्षेत्र में भविष्य के प्रयास तोते वीएम को लक्षित करने के लिए पीपीपी फ्रंट एंड का उपयोग करने की संभावना है।

विभिन्न वीएम डेवलपर्स निश्चित रूप से दूसरों पर क्या कर रहे हैं, इस पर नजर रखते हैं, लेकिन जब भी वे अच्छे विचार उठाते हैं तो वे उन्हें शामिल करने से पहले अपने स्वयं के स्पिन डाल देंगे।

Answer 3

आप क्या लागू करने की कोशिश कर रहे हैं? आपका प्रश्न बहुत भ्रमित शब्द है (मुझे एहसास है कि अंग्रेजी आपकी पहली भाषा नहीं है)।

एलएलवीएम और पीईपीई परिपक्व, उपयोगी परियोजनाएं दोनों हैं, लेकिन वास्तव में इस बिंदु पर ज्यादा ओवरलैप नहीं करते हैं। (एक बिंदु पर, पीपीपी एलएलवीएम बाइटकोड उत्पन्न कर सकता था- जिसे सी कोड के विपरीत एक दुभाषिया के लिए स्थिर रूप से संकलित किया गया था, लेकिन यह अधिक प्रदर्शन लाभ प्रदान नहीं करता था और अब समर्थित नहीं है।)

पीपीपी आपको देता है RPython में एक दुभाषिया लिखें और मूल कोड दुभाषिया या जेआईटी उत्पन्न करने के लिए वर्णन के रूप में उपयोग करें; एलएलवीएम एक कंपाइलर टूलचेन बनाने के लिए एक सी ++ ढांचा है जिसका उपयोग जेआईटी को लागू करने के लिए भी किया जा सकता है। एलएलवीएम के ऑप्टिमाइज़र, कोड जनरेशन और प्लेटफॉर्म सपोर्ट पीपीपीई की तुलना में काफी अधिक उन्नत हैं, लेकिन यह गतिशील भाषा रनटाइम बनाने के लिए भी उपयुक्त नहीं है (क्यों कुछ उदाहरणों के लिए Unladen Swallow retrospective देखें)। विशेष रूप से, यह रनपीटा फीडबैक एकत्र करने/उपयोग करने में प्रभावी नहीं है (जो गतिशील भाषाओं को अच्छी तरह से करने के लिए बिल्कुल जरूरी है) पीपीपी के ट्रेस-आधारित जेआईटी के रूप में। इसके अलावा, एलएलवीएम का कचरा संग्रह समर्थन अभी भी कुछ हद तक प्राचीन है, और इसमें पीआईपी की स्वचालित रूप से जेआईटी उत्पन्न करने की अनूठी क्षमता नहीं है।

संयोग से दो जावा कार्यान्वयन LLVM- J3/VMKit और Shark पर बनाए गए हैं।

आप पिछले सप्ताह स्टैनफोर्ड से PyPy talk देख सकते हैं; यह एक सुंदर सभ्य अवलोकन प्रदान करता है कि पीपीपी कैसे काम करता है। कार्ल फ्रेडरिक बोल्ज़ के presentation भी वीएम कार्यान्वयन की स्थिति का एक अच्छा अवलोकन प्रदान करता है।