Rust: रस्टसी को टेल कॉल करना सिखाएं

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

ग्रेडॉन: ब्रसन: llvm-land में टिप्पणियों को देखते हुए, हम मुश्किल में पड़ सकते हैं। फास्टसीसी आज जो कर रहा है, हम उसकी भरपाई करने में सक्षम हो सकते हैं, लेकिन इसे कल अपना विचार बदलने की अनुमति है।
ग्रेडॉन: मैंने सोचा था कि Fastcc == x86_fastcall, लेकिन मैं गलत था।
ग्रेडॉन: वे अलग-अलग कॉलिंग कन्वेंशन हैं। Fastcc है "जो कुछ भी llvm इस सप्ताह जैसा महसूस करता है"
ग्रेडॉन: हमें x86_fastcall पर स्विच करना होगा और फिर, लंबी अवधि के लिए, अपना स्वयं का कॉलिंग सम्मेलन लिखना होगा।

एलएलवीएम टेल कॉल्स का इलाज करने के तरीके में कुछ जटिलताओं के कारण यह वर्तमान में आधा-कार्यान्वित है। Rustc 'बी' अभिव्यक्तियों को पार्स करता है और उन्हें कॉल + रिट जोड़े के रूप में अनुवादित करता है, जो हमें सरल, बहुत गहरे मामलों पर 'काम' करने के लिए पर्याप्त है। बूटस्ट्रैप के लिए पर्याप्त हो सकता है।

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

स्व-होस्टिंग के लिए यहां दिखाए गए से अधिक कार्यान्वयन की आवश्यकता नहीं है। अगले मील के पत्थर के लिए पंटिंग।

क्या किसी को लगता है कि हम वास्तव में अब ऐसा करने जा रहे हैं?

ऐसा नहीं लगता कि ऐसा होने वाला है।

LLVM और टेल कॉल की स्थिति क्या है? यदि उन्हें कुछ आक्रामक सामान के बिना मज़बूती से काम करने के लिए बनाया जा सकता है जैसे कि कैली को टेल-कॉल घोषित करना, हम चीजों के एक सीमित सेट को परिभाषित कर सकते हैं जिसे टेल-कॉल (कॉलर के अपने तर्क, स्केलर) और त्रुटि के लिए पारित किया जा सकता है। अन्य पारित किया गया है। हालाँकि, इस तरह की टेल कॉल्स व्यवहार में बहुत उपयोगी नहीं हो सकती हैं।

क्या यह संभव है कि हास्केल के जीएचसी एलएलवीएम-बैकएंड को देखना सहायक हो?

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM
http://llvm.org/docs/LangRef.html#callingconv
http://llvm.org/docs/CodeGenerator.html#tailcallopt

वे केवल एक कैली एबीआई के साथ काम करते हैं जो गैर-पूंछ-कॉल मामलों में उप-इष्टतम है। तो एक मायने में, हाँ, उन्हें कैली को घोषित-टू-बी-टेल-कॉल करने की आवश्यकता होती है।

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

किसी भी मामले में, यह थोड़ा गड़बड़ है।

अब हमारे पास सिबलिंग कॉल ऑप्टिमाइज़ेशन है। क्या हम और अधिक करने की कोशिश करने की योजना बना रहे हैं?

#2216 द्वारा संबोधित सीमा को छोड़कर, ऐसा नहीं होने जा रहा है। #2216 के लिए समाधान सामान्य राज्य मशीन कोडिंग का समर्थन करने के लिए पर्याप्त व्यापक होना चाहिए।

यह बातचीत में जारी है, और हमने फिर से be आरक्षित कर लिया है। फिर से खोलना।

मुझे लगता है कि मेलिंग सूची पर ग्रेडन की टिप्पणी:

https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html

इस ताबूत में कील ठोकता है। यहाँ पुनरुत्पादित:

10/04/2013 5:43 AM को, आर्टेला कोडिंग ने लिखा:

हाय क्या रस्ट डू टेल कॉल ऑप्टिमाइजेशन करता है? मैं जो कारण पूछ रहा हूं वह यह है कि
निम्नलिखित टेल कॉल पुनरावर्ती कार्यान्वयन एक स्टैक में परिणाम देता है
अतिप्रवाह। धन्यवाद।

नहीं, और यह बहुत संभव नहीं होगा। हमारे पास इस पर एक पुरानी बग है:

https://github.com/mozilla/rust/issues/217

साथ ही एक विकी पृष्ठ और कई मेलिंग सूची सूत्र:

https://github.com/mozilla/rust/wiki/Bikeshed-tailcall
https://mail.mozilla.org/pipermail/rust-dev/2011-August/000689.html
https://mail.mozilla.org/pipermail/rust-dev/2012-January/001280.html
...

इन सबका सारांश है:

• हम सभी जानते हैं कि टेल कॉल एक सद्गुणी भाषा विशेषता है।
  उनके गुणों के और विस्तार की आवश्यकता नहीं है। हम में से कई
  लिस्प और एमएल पृष्ठभूमि है और उन्हें काफी पसंद आएगा। उनका
  अनुपस्थिति दिल का दर्द और उदासी है, हल्के में नहीं।
• टेल नियतात्मक विनाश के साथ "बुरी तरह से खेलें" कहता है। समेत
  ~ बक्सों की नियतात्मक बूंद। यह कहने के लिए नहीं कि वे नहीं हैं
  रचना योग्य, लेकिन उन्हें लिखने के विकल्प UI-अजीब हैं,
  प्रदर्शन-दंडात्मक, शब्दार्थ-जटिल या उपरोक्त सभी।
• टेल कॉल भी सी टूल्स में मान्यताओं के साथ "बुरी तरह से खेलते हैं", जिसमें शामिल हैं
  प्लेटफॉर्म एबीआई और डायनेमिक लिंकिंग।
• टेल कॉल के लिए एक कॉलिंग कन्वेंशन की आवश्यकता होती है जो एक प्रदर्शन हिट है
  सी कन्वेंशन के सापेक्ष।
• हम पूंछ _recursion_ के अधिकांश मामलों को यथोचित रूप से अच्छी तरह से परिवर्तित पाते हैं
  लूप, और गैर-पुनरावर्ती पूंछ कॉल के अधिकांश मामले राज्य को सांकेतिक शब्दों में बदलना
  मशीनें जो काफी अच्छी तरह से लिपटी हुई लूप में बदल जाती हैं
  एनम इनमें से कोई भी _काफी_ उतना सुंदर नहीं है जितना
  टेल-कॉल-उपयोग करने वाले वेरिएंट, लेकिन वे काम करते हैं और "जितना तेज़" हैं*,
  साथ ही सी और सी ++ प्रोग्रामर के लिए मुहावरेदार (जो हमारे हैं
  प्राथमिक दर्शक)।

मुझे यह सब कहते हुए खेद हो रहा है, और यह भारी मन से है, लेकिन हम
कोशिश की और उनके साथ जुड़े ट्रेडऑफ़ को बनाने का कोई तरीका नहीं मिला
जंग में शामिल करने के लिए एक तर्क के लिए योग।

-ग्रेडॉन

• गति-वार, एक स्विच-इन-ए-लूप राज्य मशीन अप्रत्यक्ष प्रेषण है इसलिए
  टेल कॉल द्वारा एन्कोडेड स्टेट मशीन की तुलना में धीमी गति से चलने की संभावना है
  राज्य से राज्य; दूसरी ओर अगर इस प्रदर्शन को पाने का तरीका
  "वापस" हर जगह टेल कॉल चालू करना है, हम एक अलग व्यापार करेंगे
  एक क्रॉस-ऑल-प्रोग्राम्स सबऑप्टिमल-परफ टैक्स के लिए सबऑप्टिमल-परफ केस। हम
  यह व्यापार स्वीकार्य नहीं लगता।

शायद यह ध्यान देने योग्य है कि हास्केल को आमतौर पर इनलाइनिंग, फ्यूजन आदि के लिए एक स्थिर तर्क परिवर्तन की आवश्यकता होती है। http://stackoverflow.com/a/9660027/667457

जंग यह कहकर स्थिर तर्क परिवर्तन का समर्थन कर सकता है कि किसी अन्य फ़ंक्शन के अंदर परिभाषित फ़ंक्शन टेलकॉल ऑप्टिमाइज़ेशन के लिए योग्य होना चाहिए। या बस चेतावनी दें कि अगर किसी अन्य फ़क्शन के अंदर नेस्टेड फ़ंक्शंस के बीच टेलकॉल्स सिबलिंग ऑप्टिमाइज़ेशन में विफल रहे। वर्तमान स्थिति सुनिश्चित नहीं है।

यह दुख की बात है कि पूंछ रिकर्सन लागू नहीं किया जाएगा। फिर मेरे पास एक प्रश्न है: एक भाषा वाक्यविन्यास क्यों बना रहा है जो एक कार्यात्मक भाषा वाक्यविन्यास की तरह लगता है यदि कार्यात्मक की एक आवश्यक विशेषता की कमी है?

मैं जंग में खबर हूँ और मैं बहुत दुखी हूँ। मैं एक पूंछ पुनरावर्ती कार्य की कोशिश करता हूं और मैं इतनी तेजी से अतिप्रवाह करता हूं। सबसे खराब जब मैं व्यवहार परिवर्तन जारी करने में संकलित करता हूं। वह सिर्फ मेरे समारोह को नहीं बुलाता है। एक मित्र ने मुझसे कहा कि एलएलवीएम अपरिभाषित मूल्य के लिए अनुकूलित है (एलएलवीएम जानता है कि एक पूंछ रिकर्सन अनंत है?!?)।

fn rec(i: i32) {
  rec(i + 1)
}

fn main() {
  println!("{}", rec(0));
}

मैं बोइथियोस से सहमत हूं, कार्यात्मक सुविधाओं वाली एक भाषा जो पूंछ कॉल को लागू नहीं करती है, कुछ याद आती है।

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

लेकिन मुझे लगता है कि आधुनिक भाषा के लिए यह एक बहुत अच्छी विशेषता है।

नोटिस जो

fn rec(i: i32) {
  println!("Hello");
  rec(i + 1)
}

कार्गो के रिलीज मोड में भी ढेर अतिप्रवाह

यदि संभव हो तो हमारे पास गारंटीड टीसीओ को अंततः लागू करने की योजना है। हमने इसके लिए एक कीवर्ड भी आरक्षित किया है, "बनें"। कृपया आरएफसी रेपो की जांच करें।

3 अगस्त 2016 को, 19:46 -0400, एंटोनी PLASKOWSKI [email protected] ने लिखा:

मैं जंग में खबर हूँ और मैं बहुत दुखी हूँ। मैं एक पूंछ पुनरावर्ती कार्य की कोशिश करता हूं और मैं इतनी तेजी से अतिप्रवाह करता हूं। सबसे खराब जब मैं व्यवहार परिवर्तन जारी करने में संकलित करता हूं। वह सिर्फ मेरे समारोह को नहीं बुलाता है। एक मित्र ने मुझसे कहा कि एलएलवीएम अपरिभाषित मूल्य के लिए अनुकूलित है (एलएलवीएम जानता है कि एक पूंछ रिकर्सन अनंत है?!?)।

fn rec(i: i32) { rec(i + 1)} fn main() {println!("{}", rec(0)); }

मैं Boiethios से सहमत हूं, कार्यात्मक सुविधाओं वाली एक भाषा जो टेल कॉल को लागू नहीं करती है, कुछ याद आती है।

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

लेकिन मुझे लगता है कि आधुनिक भाषा के लिए यह एक बहुत अच्छी विशेषता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें (https://github.com/rust-lang/rust/issues/217#issuecomment-237409642), या थ्रेड को म्यूट करें (https://github.com/notifications/unsubscribe -auth/AABsipoedHrbnKDekmzCr-dl8M6g-Gojks5qcShKgaJpZM4AC-q_)।

बस एक प्रश्न: कॉल ग्राफ़ विश्लेषण करना और पूंछ कॉल को लूप में बदलना संभव है, कम से कम एक क्रेट के भीतर, लेकिन यह संकलन समय पर कम्प्यूटेशनल रूप से महंगा है और कोड के लिए काफी मुश्किल है। क्‍या इस संभावना पर कोई चर्चा हुई? कॉलिंग कन्वेंशन के विकल्प की परवाह किए बिना यह अभी भी एक विकल्प होगा।

lbstanza का दृष्टिकोण उन्हें TCO (defn के बजाय defn +) के लिए योग्य बनाने के लिए कार्यों के एनोटेशन की आवश्यकता है। जंग में, यह काफी हद तक अतिरिक्त संकलन समय ओवरहेड को टिमथेलियन के सुझाव के लिए कम कर देगा, बस जब तक आप पूंछ कॉल का शाब्दिक रूप से हर जगह उपयोग नहीं कर रहे हैं।