Design: कृपया मनमाना लेबल और गोटो का समर्थन करें।

@oridb Wasm उपभोक्ता के लिए SSA फॉर्म में जल्दी से बदलने में सक्षम होने के लिए कुछ हद तक अनुकूलित है, और संरचना यहां सामान्य कोड पैटर्न के लिए मदद करती है, इसलिए संरचना जरूरी नहीं कि उपभोक्ता के लिए एक बोझ हो। मैं आपके इस दावे से असहमत हूं कि 'कोड जनरेशन के दोनों पक्ष निर्दिष्ट प्रारूप के आसपास काम करते हैं'। Wasm एक दुबले और तेज़ उपभोक्ता के बारे में बहुत कुछ है, और यदि आपके पास इसे पतला और तेज़ बनाने के लिए कुछ प्रस्ताव हैं तो यह रचनात्मक हो सकता है।

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

अधिक सामान्य सीएफजी समर्थन के लिए अन्य अनुरोध किए गए हैं, और कुछ अन्य दृष्टिकोणों का उल्लेख किया गया है, लेकिन शायद ध्यान वर्तमान में कहीं और है।

मुझे नहीं लगता कि एन्कोडिंग में स्पष्ट रूप से 'निरंतर गुजरने वाली शैली' का समर्थन करने की कोई योजना है, लेकिन ब्लॉक और लूप पॉपिंग तर्क (बिल्कुल लैम्ब्डा की तरह) और एकाधिक मानों (एकाधिक लैम्ब्डा तर्क) का समर्थन करने और जोड़ने का उल्लेख किया गया है pick ऑपरेटर परिभाषाओं को संदर्भित करना आसान बनाने के लिए (लैम्ब्डा तर्क)।

सामान्य कोड पैटर्न के लिए संरचना यहाँ मदद करती है

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

ब्लॉक जिन्हें डीएजी में ऑर्डर किया जा सकता है, उन्हें वासम ब्लॉक और शाखाओं में व्यक्त किया जा सकता है, जैसे कि आपका उदाहरण।

हाँ, वे हो सकते हैं। हालांकि, मैं दृढ़ता से यह निर्धारित करने के लिए अतिरिक्त काम नहीं जोड़ना चाहूंगा कि इस तरह से किसका प्रतिनिधित्व किया जा सकता है, बनाम किन लोगों को अतिरिक्त काम की आवश्यकता है। वास्तव में, मैं अतिरिक्त विश्लेषण करना छोड़ दूंगा, और हमेशा स्विच लूप फॉर्म उत्पन्न करूंगा।

दोबारा, मेरा तर्क यह नहीं है कि लूप और ब्लॉक चीजों को असंभव बनाते हैं; यह है कि वे जो कुछ भी कर सकते हैं वह मशीन के लिए goto, goto_if, और मनमानी, असंरचित लेबल के साथ लिखना आसान और आसान है।

शायद बाइनरीन पर एक नज़र डालें जो आपके कंपाइलर बैकएंड के लिए अधिकतर काम कर सकता है।

मेरे पास पहले से ही एक सेवा योग्य बैकएंड है जिससे मैं काफी खुश हूं, और पूरे कंपाइलर को पूरी तरह से अपनी भाषा में बूटस्ट्रैप करने की योजना बना रहा हूं। मैं केवल लूप/ब्लॉक के लागू उपयोग के आसपास काम करने के लिए एक बड़ी अतिरिक्त निर्भरता में नहीं जोड़ना चाहता हूं। अगर मैं बस स्विच लूप का उपयोग करता हूं, तो कोड उत्सर्जित करना बहुत छोटा है। अगर मैं वास्तव में वेब असेंबली में मौजूद सुविधाओं का प्रभावी ढंग से उपयोग करने की कोशिश करता हूं, तो यह दिखावा करने के लिए कि वे मौजूद नहीं हैं, यह एक अच्छा सौदा और अधिक अप्रिय हो जाता है।

अधिक सामान्य सीएफजी समर्थन के लिए अन्य अनुरोध किए गए हैं, और कुछ अन्य दृष्टिकोणों का उल्लेख किया गया है, लेकिन शायद बल वर्तमान में कहीं और है।

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

जहां तक ​​सीपीएस की बात है, मुझे नहीं लगता कि स्पष्ट समर्थन की आवश्यकता है - यह एफपी सर्किलों में लोकप्रिय है क्योंकि इसे सीधे असेंबली में परिवर्तित करना काफी आसान है, और तर्क के मामले में एसएसए को समान लाभ देता है (http:// mlton.org/pipermail/mlton/2003-January/023054.html); दोबारा, मैं इस पर एक विशेषज्ञ नहीं हूं, लेकिन जो मुझे याद है, आमंत्रण निरंतरता एक लेबल, कुछ movs, और एक गोटो में कम हो जाती है।

@oridb 'फ्लैट निर्देश सूचियों से एसएसए में तेज़ और प्रसिद्ध रूपांतरण हैं'

यह जानना दिलचस्प होगा कि वे एसएसए डिकोडर्स के साथ तुलना कैसे करते हैं, यह महत्वपूर्ण प्रश्न है?

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

क्या आप मूल्यों को ढेर रखेंगे, या रजिस्टर आधारित डिज़ाइन का उपयोग करेंगे? यदि मूल्यों को ढेर रखा जाता है तो शायद यह सीआईएल क्लोन बन जाता है, और शायद सीआईएल के प्रदर्शन की तुलना सीआईएल से की जा सकती है, क्या किसी ने वास्तव में इसकी जांच की है?

क्या आप मूल्यों को ढेर रखेंगे, या रजिस्टर आधारित डिज़ाइन का उपयोग करेंगे?

मुझे वास्तव में उस छोर पर कोई मजबूत भावना नहीं है। मुझे लगता है कि एन्कोडिंग की कॉम्पैक्टनेस सबसे बड़ी चिंताओं में से एक होगी; एक रजिस्टर डिज़ाइन वहां अच्छी तरह से किराया नहीं दे सकता है - या यह gzip पर काल्पनिक रूप से संपीड़ित हो सकता है। मैं वास्तव में अपने सिर के ऊपर से नहीं जानता।

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

यह जानना दिलचस्प होगा कि वे एसएसए डिकोडर्स के साथ तुलना कैसे करते हैं, यह महत्वपूर्ण प्रश्न है?

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

आपके सवालों और चिंताओं के लिए धन्यवाद।

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

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

हमने इस बारे में सदस्यों के बीच बहुत सारी आंतरिक चर्चा की है
विषय, चूंकि, एक बाइटकोड के लिए, यह एक चीज है जो सबसे अलग है
अन्य मशीन-स्तरीय लक्ष्य। हालांकि, यह लक्ष्यीकरण से अलग नहीं है
जावास्क्रिप्ट जैसी स्रोत भाषा (जो आजकल कई कंपाइलर करते हैं) और
संरचना प्राप्त करने के लिए ब्लॉकों के केवल मामूली पुनर्गठन की आवश्यकता है। वहां
ऐसा करने के लिए ज्ञात एल्गोरिदम और उपकरण हैं। हम कुछ प्रदान करना चाहेंगे
उन उत्पादकों के लिए बेहतर मार्गदर्शन, जिनकी शुरुआत मनमाने ढंग से CFG से होती है
इसे बेहतर तरीके से संप्रेषित करें। किसी AST . से सीधे WASM को लक्षित करने वाली भाषाओं के लिए
(जो वास्तव में कुछ ऐसा है जो V8 अब asm.js कोड के लिए करता है - सीधे
जावास्क्रिप्ट एएसटी को डब्ल्यूएएसएम बाइटकोड में अनुवाद करना), कोई पुनर्गठन नहीं है
आवश्यक कदम। हम उम्मीद करते हैं कि कई भाषा उपकरणों के मामले में ऐसा ही होगा
पूरे स्पेक्ट्रम में जिनके अंदर परिष्कृत IR नहीं हैं।

गुरु, 8 सितंबर, 2016 को सुबह 9:53 बजे, ओरि बर्नस्टीन नोटिफिकेशन @github.com
लिखा था:

क्या आप मूल्यों को ढेर रखेंगे, या रजिस्टर आधारित डिज़ाइन का उपयोग करेंगे?

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

यह जानना दिलचस्प होगा कि वे एसएसए डिकोडर्स के साथ तुलना कैसे करते हैं, कि
महत्वपूर्ण प्रश्न है?

यदि आप SSA को डिकोडिंग कर रहे हैं, तो इसका अर्थ है कि आप भी a . कर रहे होंगे
अनुकूलन की उचित मात्रा। मैं बेंचमार्क करने के लिए उत्सुक हूं कि कैसे
महत्वपूर्ण डिकोडिंग प्रदर्शन पहले स्थान पर है। लेकिन, हाँ, वह है
निश्चित रूप से एक अच्छा सवाल है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/796#issuecomment -245521009,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALnq1Iz1nn4--NL32R9ev0JPKfEnDyvqks5qn77cgaJpZM4J3ofA
.

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

यह साफ-सुथरा अनुकूलन है जो दुभाषियों का उपयोग करता है जो शाखा की भविष्यवाणी को बेहतर बनाने के लिए इरेड्यूसबल नियंत्रण प्रवाह पर निर्भर करता है ...

@oridb

मैं तर्क देना चाहता हूं कि एक चापलूसी, गोटो आधारित प्रारूप कहीं अधिक उपयोगी होगा:
संकलक डेवलपर्स के लिए एक लक्ष्य

मैं मानता हूं कि कई कंपाइलरों के लिए गोटो बहुत उपयोगी होते हैं। यही कारण है कि Binaryen जैसे उपकरण आपको gotos के साथ मनमाने CFG उत्पन्न करने देते हैं , और वे आपके लिए बहुत जल्दी और कुशलता से WebAssembly में परिवर्तित कर सकते हैं।

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

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

यह WebAssembly को ब्राउज़र के उपभोग के लिए अनुकूलित चीज़ के रूप में सोचने में मदद कर सकता है (जैसा कि @titzer ने बताया)। अधिकांश कंपाइलरों को शायद सीधे WebAssembly उत्पन्न नहीं करना चाहिए, बल्कि बाइनरीन जैसे टूल का उपयोग करना चाहिए ...

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

लेकिन अगर आप वेब ब्राउज़र खपत के लिए अनुकूलन कर रहे थे, तो वेब असेंबली को एसएसए के रूप में परिभाषित क्यों न करें, जो मुझे लगता है कि मैं जो अपेक्षा करता हूं, और एसएसए में 'कन्वर्ट' करने के लिए कम प्रयास दोनों के अनुरूप है?

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

SSA अभ्यावेदन के संबंध में, उनके पास बड़े कोड आकार होते हैं। एसएसए कोड को अनुकूलित करने के लिए बहुत अच्छा है, लेकिन कोड को कॉम्पैक्ट रूप से क्रमबद्ध करने के लिए नहीं।

@oridb 'तेज़, सरल सत्यापन, आसान, एक पास रूपांतरण सर्व शिक्षा अभियान के लिए प्रपत्र को सक्षम करने के ... द्वारा WebAssembly के नियंत्रण प्रवाह निर्माणों सरल उपभोक्ताओं की डिजाइन' @titzer द्वारा टिप्पणी देखें - यह एक पास में _verified_ सर्व शिक्षा अभियान के उत्पन्न कर सकते हैं। यहां तक ​​​​कि अगर wasm ने एन्कोडिंग के लिए SSA का उपयोग किया था, तब भी इसे सत्यापित करने का बोझ होगा, डोमिनेटर संरचना की गणना करना जो कि wasm नियंत्रण प्रवाह प्रतिबंधों के साथ आसान है।

वासम की अधिकांश एन्कोडिंग दक्षता सामान्य कोड पैटर्न के लिए अनुकूलित होने से आती है जिसमें परिभाषाओं का एक ही उपयोग होता है जो स्टैक ऑर्डर में उपयोग किया जाता है। मुझे उम्मीद है कि एक एसएसए एन्कोडिंग भी ऐसा कर सकती है, इसलिए यह समान एन्कोडिंग दक्षता का हो सकता है। डायमंड पैटर्न के लिए if_else जैसे ऑपरेटर भी बहुत मदद करते हैं। लेकिन वास्म संरचना के बिना ऐसा लगता है कि सभी बुनियादी ब्लॉकों को रजिस्टरों से परिभाषाओं को पढ़ने और रजिस्टरों को परिणाम लिखने की आवश्यकता होगी, और यह इतना कुशल नहीं हो सकता है। उदाहरण के लिए, मुझे लगता है कि wasm एक pick ऑपरेटर के साथ और भी बेहतर कर सकता है जो स्टैक के ऊपर और बुनियादी ब्लॉक सीमाओं में स्कोप्ड स्टैक वैल्यू को संदर्भित कर सकता है।

मुझे लगता है कि wasm अधिकांश कोड को SSA शैली में एन्कोड करने में सक्षम होने से बहुत दूर नहीं है। यदि परिभाषाओं को स्कोप ट्री को मूल ब्लॉक आउटपुट के रूप में पारित किया गया था तो यह पूर्ण हो सकता है। हो सकता है कि एसएसए एन्कोडिंग सीएफजी मामले के लिए ऑर्थोगोनल हो। उदाहरण के लिए, सीएफजी प्रतिबंधों के साथ एक एसएसए एन्कोडिंग हो सकती है, सीएफजी प्रतिबंधों के साथ एक रजिस्टर आधारित वीएम हो सकता है।

Wasm का लक्ष्य रनटाइम उपभोक्ता से अनुकूलन बोझ को हटाना है। रनटाइम कंपाइलर में जटिलता जोड़ने के लिए मजबूत प्रतिरोध है, क्योंकि यह हमले की सतह को बढ़ाता है। डिज़ाइन चुनौती का इतना हिस्सा पूछना है कि प्रदर्शन को नुकसान पहुंचाए बिना रनटाइम कंपाइलर को सरल बनाने के लिए क्या किया जा सकता है, और बहुत बहस!

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

void transformed_coroutine(struct autogenerated_context_struct *ctx) {
    int arg1, arg2; // function args
    int var1, var2, var3, …; // all vars used by the function
    switch (ctx->current_label) { // restore state
    case 0:
        // initial state, load function args caller supplied and proceed to start
        arg1 = ctx->arg1;
        arg2 = ctx->arg2;
        break;
    case 1: 
        // restore all vars which are live at label 1, then jump there
        var2 = ctx->var2; 
        var3 = ctx->var3;
        goto resume_1;
    [more cases…]
    }

    [main body goes here...]
    [somewhere deep in nested control flow:]
        // originally a yield/await/etc.
        ctx->var2 = var2;
        ctx->var3 = var3;
        ctx->current_label = 1;
        return;
        resume_1:
        // continue on
}

तो आपके पास ज्यादातर सामान्य नियंत्रण प्रवाह होता है, लेकिन इसके बीच में कुछ गोटो की ओर इशारा किया जाता है। मोटे तौर पर यह है कि एलएलवीएम कोरआउट कैसे काम करता है ।

मुझे नहीं लगता कि ऐसा कुछ फिर से करने का कोई अच्छा तरीका है, अगर 'सामान्य' नियंत्रण प्रवाह काफी जटिल है। (गलत हो सकता है।) या तो आप फ़ंक्शन के बड़े हिस्से को डुप्लिकेट करते हैं, संभावित रूप से प्रत्येक उपज बिंदु के लिए एक अलग प्रतिलिपि की आवश्यकता होती है, या आप पूरी चीज को एक विशाल स्विच में बदल देते हैं, जो कि @kripken के अनुसार सामान्य कोड पर relooper से 4x धीमा है ( जो शायद रिलोपर की आवश्यकता नहीं होने से कुछ हद तक धीमा है)।

वीएम जंप थ्रेडिंग ऑप्टिमाइज़ेशन के साथ एक विशाल स्विच के ओवरहेड को कम कर सकता है, लेकिन निश्चित रूप से वीएम के लिए उन अनुकूलन को निष्पादित करना अधिक महंगा है, अनिवार्य रूप से यह अनुमान लगाना कि कोड केवल स्पष्ट गोटो को स्वीकार करने की तुलना में गोटो को कैसे कम करता है। जैसा कि @kripken कहते हैं, यह भी कम अनुमानित है।

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

वैसे भी, coroutines सिर्फ एक उदाहरण हैं। एक और उदाहरण जो मैं सोच सकता हूं वह वीएम-इन-ए-वीएम लागू कर रहा है। JITs का एक और अधिक आम सुविधा पक्ष बाहर निकलता है, जो गोटो की ज़रूरत नहीं पड़ती है, ऐसी परिस्थितियाँ होती हैं कि पक्ष प्रविष्टियों के लिए कॉल - फिर से, लूप और इस तरह के बीच में गोटो की जरूरत पड़ेगी। एक और अनुकूलित दुभाषिए होंगे: ऐसा नहीं है कि वासम को लक्षित करने वाले दुभाषिए वास्तव में मूल कोड को लक्षित करने वालों से मेल खा सकते हैं, जो कम से कम गणना किए गए गोटो के साथ प्रदर्शन में सुधार कर सकते हैं, और अधिक के लिए असेंबली में डुबकी लगा सकते हैं ... लेकिन गणना किए गए गोटो के लिए प्रेरणा का हिस्सा बेहतर लाभ उठाना है। प्रत्येक मामले को अपना कूद निर्देश देकर शाखा भविष्यवक्ता, ताकि आप प्रत्येक ऑपोड हैंडलर के बाद एक अलग स्विच करके कुछ प्रभावों को दोहराने में सक्षम हो सकें, जहां सभी मामले सिर्फ गोटो होंगे। या कम से कम एक या दो विशिष्ट निर्देशों के लिए जाँच करें जो आमतौर पर वर्तमान के बाद आते हैं। उस पैटर्न के कुछ विशेष मामले हैं जो संरचित नियंत्रण प्रवाह के साथ प्रतिनिधित्व योग्य हो सकते हैं, लेकिन सामान्य मामला नहीं। और इसी तरह…

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

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

एफडब्ल्यूआईडब्ल्यू: वासम का एक विशेष डिजाइन है, जिसे कुछ बहुत ही महत्वपूर्ण शब्दों में समझाया गया है "सिवाय इसके कि घोंसले के शिकार प्रतिबंध लूप के बाहर से लूप के बीच में शाखा बनाना असंभव बनाता है"।

अगर यह सिर्फ एक डीएजी था तो सत्यापन सिर्फ जांच कर सकता था कि शाखाएं आगे थीं, लेकिन लूप के साथ यह लूप के बाहर से लूप के बीच में ब्रांचिंग की अनुमति देगा, इसलिए नेस्टेड ब्लॉक डिज़ाइन।

सीएफजी इस डिजाइन का केवल एक हिस्सा है, दूसरा डेटा प्रवाह है, और मूल्यों का एक ढेर है और मूल्यों के ढेर को खोलने के लिए ब्लॉक भी आयोजित किए जा सकते हैं जो उपभोक्ता को लाइव रेंज को बहुत उपयोगी रूप से संवाद कर सकते हैं जो एसएसए में परिवर्तित होने वाले काम को बचाता है। .

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

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

(func f1 (arg1)
  (let ((c1 10)) ; Some values up the stack.
    (blocks ((b1 (a1 a2 a3)
                   ... (br b3)
               (br b2 (+ a1 a2 a3 arg1 c1)))
             (b2 (a1)
                 ... (br b1 ...))
             (b3 ()
                 ...))
   .. regular structured wasm ..
   (br b2 ...)
   ....
   (br b3)
    ...
   ))

लेकिन क्या वेब ब्राउजर कभी भी आंतरिक रूप से इस कुशल को संभालेंगे?

क्या स्टैक मशीन पृष्ठभूमि वाला कोई व्यक्ति कोड पैटर्न को पहचान लेगा और इसे स्टैक एन्कोडिंग से मिलान करने में सक्षम होगा?

यहाँ इरेड्यूसेबल लूप्स पर कुछ दिलचस्प चर्चा है http://bboissin.appspot.com/static/upload/bboissin-thesis-2010-09-22.pdf

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

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

यह वास्तव में मनमाने ढंग से लेबल और गोटो नहीं होगा, लेकिन कुछ ऐसा है जिसे इनमें तब्दील किया जा सकता है, भविष्य में कुशलता से संकलित होने का कुछ मौका है।

रिकॉर्ड के लिए, मैं इस मुद्दे पर @oridb और @comex के साथ दृढ़ता से हूं ।
मुझे लगता है कि यह एक महत्वपूर्ण मुद्दा है जिसे बहुत देर होने से पहले संबोधित किया जाना चाहिए।

WebAssembly की प्रकृति को देखते हुए, आपके द्वारा अभी की गई कोई भी गलती आने वाले दशकों तक बनी रहने की संभावना है (जावास्क्रिप्ट को देखें!) इसलिए यह मुद्दा इतना गंभीर है; किसी भी कारण से अब गोटो का समर्थन करने से बचें (उदाहरण के लिए अनुकूलन को आसान बनाने के लिए, जो --- काफी स्पष्ट रूप से --- एक सामान्य चीज़ पर एक विशिष्ट कार्यान्वयन का प्रभाव है, और ईमानदारी से, मुझे लगता है कि यह आलसी है), और आप समाप्त हो जाएंगे लंबे समय में समस्याएं।

मैं पहले से ही भविष्य (या वर्तमान, लेकिन भविष्य में) देख सकता हूं WebAssembly कार्यान्वयन विशेष-मामले की कोशिश कर रहे हैं ताकि उन्हें ठीक से संभालने के लिए लेबल लागू करने के लिए सामान्य समय/स्विच पैटर्न को पहचान सकें। यह एक हैक है।

WebAssembly साफ स्लेट है, इसलिए अब गंदे हैक्स (या बल्कि, उनके लिए आवश्यकताएं) से बचने का समय है।

@darkuranium :

WebAssembly जैसा कि वर्तमान में निर्दिष्ट है, पहले से ही ब्राउज़र और टूलचेन में शिपिंग कर रहा है, और डेवलपर्स ने पहले से ही कोड बनाया है जो उस डिज़ाइन में निर्धारित फॉर्म लेता है। इसलिए हम डिजाइन को ब्रेकिंग तरीके से नहीं बदल

हालाँकि, हम डिज़ाइन में पिछड़े-संगत तरीके से जोड़ सकते हैं। मुझे नहीं लगता कि इसमें शामिल लोगों में से कोई भी सोचता है कि goto बेकार है। मुझे संदेह है कि हम सभी नियमित रूप से goto , न कि केवल वाक्य-रचनात्मक खिलौना शिष्टाचार में।

इस समय, प्रेरणा के साथ किसी को एक प्रस्ताव के साथ आने की जरूरत है जो समझ में आता है और इसे लागू करता है। मुझे नहीं लगता कि इस तरह के प्रस्ताव को खारिज किया जा रहा है अगर यह ठोस डेटा प्रदान करता है।

WebAssembly की प्रकृति को देखते हुए, अब आपके द्वारा की जाने वाली कोई भी गलती आने वाले दशकों तक बने रहने की संभावना है (जावास्क्रिप्ट को देखें!) इसलिए यह मुद्दा इतना गंभीर है; किसी भी कारण से अब गोटो का समर्थन करने से बचें (उदाहरण के लिए अनुकूलन को आसान बनाने के लिए, जो --- काफी स्पष्ट रूप से --- एक सामान्य चीज़ पर एक विशिष्ट कार्यान्वयन का प्रभाव है, और ईमानदारी से, मुझे लगता है कि यह आलसी है), और आप समाप्त हो जाएंगे लंबे समय में समस्याएं।

तो मैं आपके झांसे को बुलाऊंगा: मुझे लगता है कि आप जो प्रेरणा दिखाते हैं, और प्रस्ताव और कार्यान्वयन के साथ नहीं आना जैसा कि मैंने ऊपर विस्तार से बताया है, काफी स्पष्ट रूप से आलसी है।

मैं निश्चित रूप से चुटीला हो रहा हूँ। इस बात पर विचार करें कि हमारे पास थ्रेड्स, GC, SIMD, आदि के लिए लोग हमारे दरवाजे पर धमाका कर रहे हैं - सभी इस बात के लिए भावुक और समझदार तर्क दे रहे हैं कि उनकी विशेषता सबसे महत्वपूर्ण क्यों है - यह बहुत अच्छा होगा यदि आप इनमें से किसी एक मुद्दे से निपटने में हमारी मदद कर सकें। मेरे द्वारा उल्लिखित अन्य सुविधाओं के लिए ऐसा करने वाले लोग हैं। अब तक goto लिए कोई नहीं। कृपया अपने आप को इस समूह के योगदान दिशानिर्देशों से परिचित कराएं और मस्ती में शामिल हों।

अन्यथा मुझे लगता है कि goto भविष्य की एक बेहतरीन

नमस्ते। मैं webassembly से IR और वापस webassembly में अनुवाद लिखने के बीच में हूं, और मैंने लोगों के साथ इस विषय पर चर्चा की है।

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

if (x) goto inside_loop;
// banana
while(y) {
    // things
    inside_loop:
    // do things
}

ईबीबी कंपाइलर निम्नलिखित का उत्पादन करेंगे:

entry:
    cjump x, inside_loop
    // banana
    jump loop

loop:
    cjump y, exit
    // things
    jump inside_loop

inside_loop:
    // do things
    jump loop
exit:
    return

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

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

<inside_loop, if(x)>
    // banana
<loop °>
<exit if(y)>
    // things
</inside_loop, if(x)>
    // do things
</loop ↑>
</exit>

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

if
    // do things
else
    // banana
end
loop
  br out
    // things
    // do things
end

अब हम इसे webassembly में ट्रांसलेट कर सकते हैं। क्षमा करें, मैं अभी तक इस बात से परिचित नहीं हूं कि ये लूप कैसे बनते हैं।

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

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

लेकिन उदाहरण के लिए, निम्नलिखित ठीक उसी तरह काम करेगा:

    cjump x, label(1)
    // banana
0: label
    cjump y, label(2)
    // things
1: label
    // do things
    jump label(0)
2: label
    // exit as usual, picking the values from the top of the stack.

संख्याएं निहित होंगी, अर्थात .. जब संकलक एक 'लेबल' देखता है, तो यह जानता है कि यह एक नया विस्तारित ब्लॉक शुरू करता है और इसे एक नया इंडेक्स नंबर देता है, जो 0 से वृद्धि करना शुरू करता है।

एक स्थिर स्टैक का उत्पादन करने के लिए, आप ट्रैक कर सकते हैं कि जब आप लेबल में कूदते हैं तो स्टैक में कितने आइटम हैं। यदि लेबल में कूदने के बाद असंगत स्टैक समाप्त होता है, तो प्रोग्राम अमान्य है।

यदि आप उपरोक्त खराब पाते हैं, तो आप प्रत्येक लेबल में एक स्पष्ट स्टैक लंबाई जोड़ने का प्रयास कर सकते हैं (शायद अंतिम अनुक्रमित लेबल के स्टैक आकार से डेल्टा, यदि पूर्ण मान संपीड़न के लिए खराब है), और प्रत्येक के लिए एक मार्कर कितने मूल्यों के बारे में कूदता है यह छलांग के दौरान ढेर के ऊपर से कॉपी करता है।

मैं शर्त लगा सकता हूं कि आप नियंत्रण प्रवाह का प्रतिनिधित्व कैसे करते हैं, इस तथ्य से आप किसी भी तरह से gzip को बाहर नहीं कर सकते हैं, इसलिए आप उन लोगों के लिए अच्छा प्रवाह चुन सकते हैं जिनके पास यहां सबसे कठिन काम है। (मैं अपने लचीले कंपाइलर टूलचेन के साथ 'gzip को आउटस्मार्टिंग' के लिए चित्रित कर सकता हूं - यदि आप चाहें, तो बस मुझे एक संदेश भेजें और एक डेमो डालें!)

मैं अभी एक चकनाचूर की तरह महसूस कर रहा हूँ। WebAssembly युक्ति के माध्यम से बस फिर से पढ़ें और उठाया कि इरेड्यूसीबल नियंत्रण प्रवाह जानबूझकर एमवीपी से छोड़ दिया गया है, शायद इस कारण से कि शुरुआती दिनों में एमस्क्रिप्टन को समस्या का समाधान करना पड़ा था।

WebAssembly में इरेड्यूसेबल कंट्रोल फ्लो को कैसे हैंडल किया जाए, इसका समाधान "एम्सस्क्रिप्टन: एन एलएलवीएम-टू-जावास्क्रिप्ट कंपाइलर" पेपर में बताया गया है। रिलोपर प्रोग्राम को कुछ इस तरह से पुनर्गठित करता है:

_b_ = bool(x)
_b_ == 0 if
  // banana
end
block loop
  _b_ if
    // do things
    _b_ = 0
  else
    y br_if 2
    // things
    _b_ = 1
  end
  br 0
end end

तर्कसंगत यह था कि संरचित नियंत्रण प्रवाह स्रोत कोड डंप को पढ़ने में मदद करता है, और मुझे लगता है कि यह पॉलीफिल कार्यान्वयन में मदद करने के लिए माना जाता है।

webassembly से संकलित लोग शायद ध्वस्त नियंत्रण प्रवाह को संभालने और अलग करने के लिए अनुकूल होंगे।

इसलिए:

• जैसा कि उल्लेख किया गया है, WebAssembly अब स्थिर है, इसलिए किसी भी कुल पुनर्लेखन के लिए समय बीत चुका है कि नियंत्रण प्रवाह कैसे व्यक्त किया जाता है।
  
  
  
  • एक मायने में, यह दुर्भाग्यपूर्ण है, क्योंकि वास्तव में किसी ने भी परीक्षण नहीं किया है कि क्या अधिक सीधे एसएसए-आधारित एन्कोडिंग वर्तमान डिजाइन के समान कॉम्पैक्टनेस प्राप्त कर सकती है।
  
  
  • हालाँकि, जब गोटो को निर्दिष्ट करने की बात आती है, तो इससे काम बहुत आसान हो जाता है! ब्लॉक-आधारित निर्देश पहले से ही बाइकशेडिंग से परे हैं, और यह कोई बड़ी बात नहीं है कि उत्पादन संकलक लक्ष्यीकरण को उनके उपयोग से कम करने योग्य नियंत्रण प्रवाह को व्यक्त
  
  
• कम करने की क्षमता विशेष रूप से उपयोगी नहीं है।
  
  
  
  • अधिकांश कंपाइलर बैकएंड उनके बीच मूल ब्लॉक और शाखाओं के ग्राफ के आधार पर एक एसएसए प्रतिनिधित्व का उपयोग करते हैं। नेस्टेड लूप संरचना, वह चीज जो कम करने की गारंटी देती है, शुरुआत में काफी दूर फेंक दी जाती है।
  
  
  • मैंने JavaScriptCore, V8, और SpiderMonkey में वर्तमान WebAssembly कार्यान्वयन की जाँच की, और वे सभी इस पैटर्न का पालन करते प्रतीत होते हैं। (वी 8 अधिक जटिल है - बुनियादी ब्लॉकों के बजाय किसी प्रकार का "नोड्स का समुद्र" प्रतिनिधित्व - लेकिन घोंसले की संरचना को भी फेंक देता है।)
  
  
  • अपवाद : लूप विश्लेषण उपयोगी हो सकता है, और उन सभी तीन कार्यान्वयन आईआर को जानकारी से गुजरते हैं जिसके बारे में बुनियादी ब्लॉक लूप की शुरुआत हैं। (एलएलवीएम से तुलना करें, जो एओटी संकलन के लिए डिज़ाइन किए गए 'हैवीवेट' बैकएंड के रूप में, इसे फेंक देता है और बैकएंड में इसकी पुनर्गणना करता है। यह अधिक मजबूत है, क्योंकि यह उन चीजों को ढूंढ सकता है जो स्रोत कोड में लूप की तरह नहीं दिखते हैं लेकिन करते हैं अनुकूलन के एक समूह के बाद, लेकिन धीमा।)
  
  
  • लूप विश्लेषण "प्राकृतिक लूप" पर काम करता है, जो लूप के बीच में शाखाओं को मना करता है जो लूप हेडर से नहीं जाते हैं।
  
  
  • WebAssembly को यह गारंटी देना जारी रखना चाहिए कि loop ब्लॉक प्राकृतिक लूप हैं।
  
  
  • लेकिन लूप विश्लेषण के लिए यह आवश्यक नहीं है कि पूरा कार्य कम किया जा सके, न ही लूप के अंदर भी: यह सिर्फ शाखाओं को बाहर से अंदर तक मना करता है। आधार प्रतिनिधित्व अभी भी एक मनमाना नियंत्रण प्रवाह ग्राफ है।
  
  
  • इरेड्यूसिबल कंट्रोल फ्लो WebAssembly को जावास्क्रिप्ट (पॉलीफिलिंग) में संकलित करना कठिन बना देता है, क्योंकि कंपाइलर को रिलूपर एल्गोरिथम को ही चलाना होगा।
  
  
  • लेकिन WebAssembly पहले से ही कई निर्णय लेता है जो किसी भी कंपाइल-टू-जेएस दृष्टिकोण के लिए महत्वपूर्ण रनटाइम ओवरहेड जोड़ते हैं (असंरेखित मेमोरी एक्सेस सपोर्ट और आउट-ऑफ-बाउंड्स एक्सेस पर ट्रैपिंग सहित), यह सुझाव देते हुए कि इसे बहुत महत्वपूर्ण नहीं माना जाता है।
  
  
  • इसकी तुलना में, कंपाइलर को थोड़ा और जटिल बनाना कोई बड़ी बात नहीं है।
  
  
  • इसलिए, मुझे नहीं लगता कि इरेड्यूसेबल नियंत्रण प्रवाह के लिए किसी प्रकार का समर्थन नहीं जोड़ने का कोई अच्छा कारण है।
  
  
• एसएसए प्रतिनिधित्व (जो, डिजाइन द्वारा, एक पास में संभव होना चाहिए) बनाने के लिए आवश्यक मुख्य जानकारी प्रमुख वृक्ष है ।
  
  
  
  • वर्तमान में एक बैकएंड संरचित नियंत्रण प्रवाह के आधार पर प्रभुत्व का अनुमान लगा सकता है। अगर मैं कल्पना को सही ढंग से समझता हूं, तो निम्नलिखित निर्देश एक बुनियादी ब्लॉक को समाप्त करते हैं:
  
  
  • block :
    
    
    
    
    
    • ब्लॉक शुरू करने वाले BB में पिछले BB का प्रभुत्व होता है।*
    
    
    
    • संबंधित end का अनुसरण करने वाले BB में ब्लॉक शुरू करने वाले BB का प्रभुत्व होता है, लेकिन end से पहले BB द्वारा नहीं (क्योंकि br आउट होने पर इसे छोड़ दिया जाएगा) )
    
    
    
  
  
  • loop :
    
    
    
    
    
    • ब्लॉक शुरू करने वाली बीबी में पिछली बीबी का प्रभुत्व होता है।
    
    
    
    • के बाद बी बी end से पहले बी बी का प्रभुत्व है end (जब से तुम के बाद शिक्षा के लिए नहीं मिल सकता है end को क्रियान्वित करने के अलावा end )।
    
    
    
  
  
  • if :
    
    
    
    
    
    • यदि पक्ष, और पक्ष है, और के बाद बी बी end सब से पहले बी बी का प्रभुत्व है if ।
    
    
    
  
  
  • br , return , unreachable :
    
    
    
    
    
    • ( br , return , या unreachable तुरंत बाद BB पहुंच योग्य नहीं है।)
    
    
    
  
  
  • br_if , br_table :
    
    
    
    
    
    • br_if / br_table से पहले BB इसके बाद वाले पर हावी हो जाता है।
    
    
    
  
  
  • गौरतलब है कि यह केवल एक अनुमान है। यह झूठी सकारात्मकता उत्पन्न नहीं कर सकता है (कह रहा है कि ए बी पर हावी है जब यह वास्तव में नहीं होता है) क्योंकि यह केवल ऐसा कहता है जब निर्माण द्वारा ए के बिना बी तक पहुंचने का कोई रास्ता नहीं है। लेकिन यह झूठी नकारात्मक उत्पन्न कर सकता है (कह रहा है कि ए वास्तव में बी पर हावी नहीं होता है), और मुझे नहीं लगता कि एक सिंगल-पास एल्गोरिदम उनको पहचान सकता है (गलत हो सकता है)।
  
  
  • उदाहरण गलत नकारात्मक:
    
    ```
    
    ब्लॉक $बाहरी
    
    कुंडली
    
    बीआर $बाहरी ;; चूंकि यह बिना शर्त टूटता है, यह गुप्त रूप से अंत बीबी पर हावी है
    
    समाप्त
    
    समाप्त
  
  
  • लेकिन यह ठीक है, AFAIK।
    
    
    
    
    
    • झूठी सकारात्मकता खराब होगी, क्योंकि उदाहरण के लिए यदि मूल ब्लॉक ए को मूल ब्लॉक बी पर हावी होने के लिए कहा जाता है, तो बी के लिए मशीन कोड ए में एक रजिस्टर सेट का उपयोग कर सकता है (यदि बीच में कुछ भी उस रजिस्टर को ओवरराइट नहीं करता है)। यदि ए वास्तव में बी पर हावी नहीं होता है, तो रजिस्टर में कचरा मूल्य हो सकता है।
    
    
    
    • झूठी नकारात्मक अनिवार्य रूप से भूत शाखाएं हैं जो कभी नहीं होती हैं। संकलक मानता है कि वे शाखाएँ हो सकती हैं, लेकिन ऐसा नहीं है कि उन्हें होना चाहिए, इसलिए उत्पन्न कोड आवश्यकता से अधिक रूढ़िवादी है।
    
    
    
  
  
  • वैसे भी, इस बारे में सोचें कि प्रमुख पेड़ के संदर्भ में goto निर्देश कैसे काम करना चाहिए। मान लीजिए कि A, B पर हावी है, जो C पर हावी है।
  
  
  • हम ए से सी तक नहीं कूद सकते क्योंकि वह बी को छोड़ देगा (प्रभुत्व की धारणा का उल्लंघन)। दूसरे शब्दों में, हम गैर-तत्काल वंशजों तक नहीं पहुंच सकते। (और बाइनरी प्रोड्यूसर के अंत में, अगर उन्होंने सच्चे डोमिनेटर ट्री की गणना की, तो ऐसी कोई छलांग नहीं होगी।)
  
  
  • हम सुरक्षित रूप से ए से बी तक कूद सकते थे, लेकिन तत्काल वंशज के पास जाना इतना उपयोगी नहीं है। यह मूल रूप से एक अगर या स्विच स्टेटमेंट के बराबर है, जो हम पहले से ही कर सकते हैं ( if निर्देश का उपयोग करके यदि केवल एक बाइनरी टेस्ट है, या br_table यदि एकाधिक हैं)।
  
  
  • इसके अलावा सुरक्षित, और अधिक दिलचस्प, एक भाई या पूर्वजों के भाई के लिए कूद रहा है। यदि हम अपने भाई-बहन के पास जाते हैं, तो हमने इस गारंटी को बरकरार रखा है कि हमारे माता-पिता हमारे भाई-बहन पर हावी हैं, क्योंकि हमने यहां पहुंचने के लिए अपने माता-पिता को पहले ही मार डाला होगा (क्योंकि यह हम पर भी हावी है)। इसी तरह पूर्वजों के लिए।
  
  
  • सामान्य तौर पर, एक दुर्भावनापूर्ण बाइनरी इस तरह से प्रभुत्व में झूठी नकारात्मक उत्पन्न कर सकती है, लेकिन जैसा कि मैंने कहा, वे (ए) पहले से ही संभव हैं और (बी) स्वीकार्य हैं।
  
  

• उसके आधार पर, यहाँ एक स्ट्रॉमैन प्रस्ताव है:

  • एक नया ब्लॉक-प्रकार का निर्देश:
  • लेबल परिणामप्रकार N instr* end
  • बिल्कुल एन तत्काल बच्चों के निर्देश होने चाहिए, जहां "तत्काल बच्चे" का अर्थ है या तो एक ब्लॉक-प्रकार का निर्देश ( loop , block , या labels ) और संबंधित तक सब कुछ end , या एक एकल गैर-ब्लॉक निर्देश (जो स्टैक को प्रभावित नहीं करना चाहिए)।
  • अन्य ब्लॉक-प्रकार के निर्देशों की तरह एकल लेबल बनाने के बजाय, labels N+1 लेबल बनाता है: N N बच्चों को इंगित करता है, और एक labels ब्लॉक के अंत की ओर इशारा करता है। प्रत्येक बच्चे में, लेबल सूचकांक 0 से N-1 क्रम में बच्चों को संदर्भित करता है, और लेबल अनुक्रमणिका N अंत को संदर्भित करता है।

  दूसरे शब्दों में, यदि आपके पास
  loop ;; outer labels 3 block ;; child 0 br X end nop ;; child 1 nop ;; child 2 end end

  एक्स के आधार पर, br अर्थ है:

  | एक्स | लक्ष्य |
  | ---------- | ------ |
  | 0 | block का अंत |
  | 1 | चाइल्ड 0 ( block शुरुआत) |
  | 2 | बच्चा 1 (नहीं) |
  | 3 | बच्चा 2 (नहीं) |
  | 4 | labels का अंत |
  | 5 | बाहरी लूप की शुरुआत |

  • निष्पादन पहले बच्चे से शुरू होता है।

  • यदि निष्पादन बच्चों में से एक के अंत तक पहुँचता है, तो यह अगले तक जारी रहता है। यदि यह अंतिम बच्चे के अंत तक पहुँच जाता है, तो यह पहले बच्चे के पास वापस चला जाता है। (यह समरूपता के लिए है, क्योंकि बच्चों का क्रम महत्वपूर्ण नहीं है।)

  • labels की शुरुआत में बच्चों में से किसी एक को ब्रांच करने से ऑपरेंड स्टैक इसकी गहराई तक खुल जाता है।

  • तो अंत तक ब्रांचिंग करता है, लेकिन यदि परिणाम प्रकार गैर- block समान खोलने के बाद धक्का देता है।

  • प्रभुत्व: labels निर्देश से पहले मूल ब्लॉक प्रत्येक बच्चे पर हावी है, साथ ही labels के अंत के बाद बीबी पर भी हावी है। बच्चे एक दूसरे पर या अंत पर हावी नहीं होते हैं।

  • डिजाइन नोट्स:

  • एन को आगे निर्दिष्ट किया गया है ताकि कोड को एक पास में मान्य किया जा सके। इसमें सूचकांकों के लक्ष्य जानने से पहले, बच्चों की संख्या जानने के लिए labels ब्लॉक के अंत तक पहुंचना अजीब होगा।

  • सुनिश्चित नहीं है कि अंततः लेबल के बीच ऑपरेंड स्टैक पर मूल्यों को पारित करने का कोई तरीका होना चाहिए, लेकिन मूल्यों को block या loop में पास करने में असमर्थता के अनुरूप, जिसे प्रारंभ करने के लिए असमर्थित किया जा सकता है साथ।

यह वास्तव में अच्छा होगा यदि लूप में कूदना संभव हो, है ना? आईआईयूसी, अगर उस मामले के लिए जिम्मेदार थे तो बुरा लूप + br_table कॉम्बो की कभी आवश्यकता नहीं होगी ...

संपादित करें: ओह, आप loop में ऊपर की ओर कूदकर बिना लूप बना सकते हैं labels । विश्वास नहीं कर सकता कि मैं चूक गया।

@qwertie एक दिया पाश एक प्राकृतिक पाश नहीं है, तो Wasm-लक्ष्य संकलक का उपयोग कर इसे व्यक्त करना चाहिए labels के बजाय loop । नियंत्रण प्रवाह व्यक्त करने के लिए स्विच जोड़ने के लिए कभी भी आवश्यक नहीं होना चाहिए, यदि आप यही कह रहे हैं। (आखिरकार, कम से कम आप फ़ंक्शन में प्रत्येक मूल ब्लॉक के लिए एक लेबल के साथ एक विशाल labels ब्लॉक का उपयोग कर सकते हैं। यह संकलक को प्रभुत्व और प्राकृतिक लूप के बारे में नहीं बताता है, इसलिए आप चूक सकते हैं अनुकूलन। लेकिन labels केवल उन मामलों में आवश्यक है जहां वे अनुकूलन लागू नहीं होते हैं।)

नेस्टेड लूप संरचना, वह चीज जो कम करने की गारंटी देती है, शुरुआत में काफी दूर फेंक दी जाती है। […]

बिल्कुल नहीं: कम से कम एसएम में, आईआर ग्राफ पूरी तरह से सामान्य ग्राफ नहीं है; हम कुछ ग्राफ़ इनवेरिएंट मानते हैं जो एक संरचित स्रोत (JS या wasm) से उत्पन्न होने का अनुसरण करते हैं और अक्सर एल्गोरिदम को सरल और/या अनुकूलित करते हैं। पूरी तरह से सामान्य CFG का समर्थन करने के लिए या तो पाइपलाइन में कई पासों को ऑडिटिंग/बदलने की आवश्यकता होगी ताकि इन अपरिवर्तनीयों को ग्रहण न किया जा सके (या तो उन्हें सामान्यीकृत करके या इरेड्यूसिबिलिटी के मामले में उन्हें निराश करके) या ग्राफ को कम करने योग्य बनाने के लिए नोड-विभाजन दोहराव। यह निश्चित रूप से करने योग्य है, लेकिन यह सच नहीं है कि यह केवल एक कृत्रिम अड़चन होने का मामला है।

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

जब हमने अतीत में मनमाने ढंग से गोटो समर्थन के साथ wasm को विस्तारित करने के लिए पिछड़े-संगत पथों पर चर्चा की है, तो एक बड़ा सवाल यह है कि यहां उपयोग का मामला क्या है: क्या यह "निर्माताओं को एक रिलोपर-प्रकार एल्गोरिदम चलाने के बिना सरल बनाता है" या यह है "वास्तव में अपरिवर्तनीय नियंत्रण प्रवाह के लिए अधिक कुशल कोडजन की अनुमति दें"? अगर यह सिर्फ पूर्व है, तो मुझे लगता है कि हम शायद मनमाने ढंग से लेबल/गोटो एम्बेड करने की कुछ योजना चाहते हैं (जो पीछे की ओर संगत है और भविष्य के ब्लॉक-संरचित प्रयास/पकड़ के साथ भी बना है); यह केवल लागत/लाभ और ऊपर उल्लिखित मुद्दों को तौलने की बात है।

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

@lukewagner
मैं इस बारे में अधिक विस्तार से सुनना चाहता हूं कि कौन से पास अपरिवर्तनीयों के आधार पर हैं। इरेड्यूसेबल फ्लो के लिए एक अलग कंस्ट्रक्शन का उपयोग करते हुए मैंने जो डिजाइन प्रस्तावित किया था, उसे एलआईसीएम जैसे ऑप्टिमाइज़ेशन पास के लिए अपेक्षाकृत आसान बनाना चाहिए ताकि उस फ्लो को साफ किया जा सके। लेकिन अगर अन्य प्रकार के टूटने हैं जिनके बारे में मैं नहीं सोच रहा हूं, तो मैं उनकी प्रकृति को बेहतर ढंग से समझना चाहता हूं ताकि मुझे बेहतर विचार मिल सके कि उन्हें कैसे और कैसे टाला जा सकता है।

जब हमने अतीत में मनमाने ढंग से गोटो समर्थन के साथ wasm को विस्तारित करने के लिए पिछड़े-संगत पथों पर चर्चा की है, तो एक बड़ा सवाल यह है कि यहां उपयोग का मामला क्या है: क्या यह "निर्माताओं को एक रिलोपर-प्रकार एल्गोरिदम चलाने के बिना सरल बनाता है" या यह है "वास्तव में अपरिवर्तनीय नियंत्रण प्रवाह के लिए अधिक कुशल कोडजन की अनुमति दें"?

मेरे लिए यह बाद वाला है; मेरा प्रस्ताव उम्मीद करता है कि निर्माता अभी भी एक रीलूपर-प्रकार एल्गोरिदम चलाएंगे ताकि बैकएंड को प्रभुत्व और प्राकृतिक लूप की पहचान करने के काम को बचाया जा सके, केवल आवश्यक होने पर labels वापस आ जाए। हालाँकि, यह अभी भी निर्माताओं को सरल बना देगा। यदि इरेड्यूसेबल कंट्रोल फ्लो में एक बड़ा जुर्माना है, तो एक आदर्श निर्माता को इससे बचने के लिए बहुत मेहनत करनी चाहिए, यह निर्धारित करने के लिए कि क्या यह डुप्लिकेट कोड के लिए अधिक कुशल है, न्यूनतम मात्रा में दोहराव जो काम कर सकता है, आदि। यदि एकमात्र दंड संभावित रूप से दे रहा है अप लूप ऑप्टिमाइज़ेशन, यह वास्तव में आवश्यक नहीं है, या कम से कम यह एक नियमित मशीन कोड बैकएंड (जिसके अपने स्वयं के लूप ऑप्टिमाइज़ेशन हैं) की तुलना में अधिक आवश्यक नहीं है।

मुझे वास्तव में अधिक डेटा इकट्ठा करना चाहिए कि व्यवहार में सामान्य इरेड्यूसेबल नियंत्रण प्रवाह कितना है ...

हालांकि, मेरा मानना ​​है कि इस तरह के प्रवाह को दंडित करना अनिवार्य रूप से मनमाना और अनावश्यक है। ज्यादातर मामलों में, समग्र प्रोग्राम रनटाइम पर प्रभाव छोटा होना चाहिए। हालांकि, अगर किसी हॉटस्पॉट में इरेड्यूसेबल कंट्रोल फ्लो शामिल होता है, तो एक गंभीर जुर्माना लगाया जाएगा; भविष्य में, WebAssembly ऑप्टिमाइज़ेशन गाइड में इसे एक सामान्य गोचा के रूप में शामिल किया जा सकता है, और समझा सकता है कि इसे कैसे पहचाना जाए और इससे कैसे बचा जाए। यदि मेरा विश्वास सही है, तो यह प्रोग्रामर के लिए संज्ञानात्मक उपरि का एक पूरी तरह से अनावश्यक रूप है। और यहां तक ​​​​कि जब ओवरहेड छोटा होता है, तब भी WebAssembly के पास देशी कोड की तुलना में पहले से ही पर्याप्त ओवरहेड होता है, जिसे किसी भी अतिरिक्त से बचने की तलाश करनी चाहिए।

मैं यह मानने के लिए तैयार हूं कि मेरा विश्वास गलत है।

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

यह दिलचस्प लगता है, लेकिन मुझे लगता है कि अधिक सामान्य-उद्देश्य वाले आदिम के साथ शुरू करना बेहतर होगा। आखिरकार, दुभाषियों के लिए तैयार एक आदिम को अभी भी इरेड्यूसेबल नियंत्रण प्रवाह से निपटने के लिए बैकएंड की आवश्यकता होगी; यदि आप उस गोली को काटने जा रहे हैं, तो सामान्य मामले का भी समर्थन कर सकते हैं।

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

@comex मुझे लगता है कि कोई भी

>

नेस्टेड लूप संरचना, वह चीज जो कम करने की गारंटी देती है, है
शुरुआत में काफी फेंक दिया। [...] मैंने करंट की जाँच की
JavaScriptCore, V8, और SpiderMonkey में WebAssembly कार्यान्वयन, और
वे सभी इस पैटर्न का पालन करते प्रतीत होते हैं।

बिल्कुल नहीं: कम से कम एसएम में, आईआर ग्राफ पूरी तरह से सामान्य ग्राफ नहीं है; हम
कुछ ग्राफ़ इनवेरिएंट मान लें जो a . से उत्पन्न होने का अनुसरण करते हैं
संरचित स्रोत (JS या wasm) और अक्सर सरल और/या अनुकूलित करते हैं
एल्गोरिदम

V8 में वही। यह वास्तव में दोनों में एसएसए के साथ मेरी प्रमुख पकड़ में से एक है
संबंधित साहित्य और कार्यान्वयन जिन्हें वे लगभग कभी परिभाषित नहीं करते हैं
क्या एक "अच्छी तरह से गठित" CFG का गठन करता है, लेकिन परोक्ष रूप से विभिन्न ग्रहण करते हैं
अनिर्दिष्ट बाधाएं वैसे भी, आमतौर पर निर्माण द्वारा सुनिश्चित की जाती हैं
भाषा दृश्यपटल। मैं शर्त लगाता हूं कि मौजूदा कंपाइलरों में कई/अधिकांश अनुकूलन
वास्तव में मनमानी CFG से निपटने में सक्षम नहीं होगा।

जैसा कि @lukewagner कहते हैं,
अनुकूलित दुभाषियों के लिए "थ्रेडेड कोड"। यह कहना मुश्किल है कि वे कितने प्रासंगिक हैं
Wasm डोमेन के लिए हैं, और क्या इसकी अनुपस्थिति वास्तव में सबसे बड़ी है
अड़चन

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

LLVM में लूप ऑप्टिमाइजेशन आमतौर पर इरेड्यूसेबल कंट्रोल फ्लो को नजरअंदाज कर देगा और इसे ऑप्टिमाइज़ करने का प्रयास नहीं करेगा। वे जिस लूप विश्लेषण पर आधारित हैं, वह केवल प्राकृतिक लूपों को पहचानेगा, इसलिए आपको बस इस बात की जानकारी होनी चाहिए कि ऐसे CFG चक्र हो सकते हैं जिन्हें लूप के रूप में पहचाना नहीं जाता है। बेशक, अन्य अनुकूलन प्रकृति में अधिक स्थानीय हैं और इरेड्यूसेबल सीएफजी के साथ ठीक काम करते हैं।

स्मृति से, और शायद गलत, SPEC2006 में 401.bzip2 में एक एकल इरेड्यूसेबल लूप है और बस इतना ही। व्यवहार में यह काफी दुर्लभ है।

क्लैंग कंप्यूटेड गोटो का उपयोग करके फंक्शन में केवल एक indirectbr निर्देश का उत्सर्जन करेगा। यह थ्रेडेड दुभाषियों को indirectbr ब्लॉक के साथ लूप हेडर के रूप में प्राकृतिक लूप में बदलने का प्रभाव है। एलएलवीएम आईआर छोड़ने के बाद, मूल उलझन को फिर से संगठित करने के लिए कोड जनरेटर में सिंगल indirectbr को टेल-डुप्लिकेट किया जाता है।

अपरिवर्तनीय नियंत्रण प्रवाह के लिए कोई एकल-पास सत्यापन एल्गोरिथ्म नहीं है
जिससे मैं वाकिफ हूं। केवल कम करने योग्य नियंत्रण प्रवाह के लिए डिज़ाइन विकल्प था
इस आवश्यकता से अत्यधिक प्रभावित है।

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

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

श्रेष्ठ,
बेन

गुरु, 20 अप्रैल, 2017 को सुबह 5:20 बजे, जैकब स्टोकलुंड ओलेसेन <
सूचनाएं@github.com> ने लिखा:

LLVM में लूप ऑप्टिमाइज़ेशन आमतौर पर इरेड्यूसेबल कंट्रोल फ़्लो को नज़रअंदाज़ कर देगा
और इसे अनुकूलित करने का प्रयास न करें। लूप विश्लेषण वे वसीयत पर आधारित हैं
केवल प्राकृतिक छोरों को पहचानें, इसलिए आपको बस इस बात से अवगत रहना होगा कि वहाँ हो सकता है
सीएफजी चक्र बनें जिन्हें लूप के रूप में पहचाना नहीं जाता है। बेशक, अन्य
अनुकूलन प्रकृति में अधिक स्थानीय हैं और इरेड्यूसिबल के साथ ठीक काम करते हैं
सीएफ़जी.

स्मृति से, और शायद गलत, SPEC2006 में एक एकल इरेड्यूसबल लूप है
401.bzip2 और बस। व्यवहार में यह काफी दुर्लभ है।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/796#issuecomment-295352983 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALnq1K99AR5YaQuNOIFIckLLSIZbmbd0ks5rxkJQgaJpZM4J3ofA
.

मैं आगे यह भी कह सकता हूं कि अगर इरेड्यूसेबल कंस्ट्रक्शन्स को इसमें जोड़ा जाए तो
WebAssembly, वे TurboFan (V8 के अनुकूलन JIT) में काम नहीं करेंगे, इसलिए
फ़ंक्शंस या तो व्याख्या किए जा रहे हैं (बेहद धीमी) या होने के नाते
बेसलाइन कंपाइलर (कुछ हद तक धीमा) द्वारा संकलित, क्योंकि हम संभवतः नहीं करेंगे
इरेड्यूसेबल कंट्रोल फ्लो को सपोर्ट करने के लिए टर्बोफैन को अपग्रेड करने में निवेश का प्रयास।
इसका मतलब है कि WebAssembly में अपरिवर्तनीय नियंत्रण प्रवाह के साथ कार्य करेगा
शायद बहुत खराब प्रदर्शन के साथ समाप्त होता है।

बेशक, V8 में WebAssembly इंजन को चलाने के लिए एक और विकल्प होगा
टर्बोफैन रिड्यूसबल ग्राफ को फीड करने के लिए रिलूपर, लेकिन यह संकलन करेगा
(और स्टार्टअप बदतर)। my . में रीलूपिंग एक ऑफ़लाइन प्रक्रिया बनी रहनी चाहिए
राय, अन्यथा हम अपरिहार्य इंजन लागतों के साथ समाप्त हो रहे हैं।

श्रेष्ठ,
बेन

सोम, 1 मई, 2017 को दोपहर 12:48 बजे, बेन एल. टिट्ज़र [email protected] ने लिखा:

अपरिवर्तनीय नियंत्रण के लिए कोई एकल-पास सत्यापन एल्गोरिथ्म नहीं है
प्रवाह जिसे मैं जानता हूं। केवल कम करने योग्य नियंत्रण प्रवाह के लिए डिज़ाइन विकल्प
इस आवश्यकता से अत्यधिक प्रभावित था।

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

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

श्रेष्ठ,
बेन

गुरु, 20 अप्रैल, 2017 को सुबह 5:20 बजे, जैकब स्टोकलुंड ओलेसेन <
सूचनाएं@github.com> ने लिखा:

LLVM में लूप ऑप्टिमाइज़ेशन आमतौर पर इरेड्यूसेबल कंट्रोल फ़्लो को नज़रअंदाज़ कर देगा
और इसे अनुकूलित करने का प्रयास न करें। लूप विश्लेषण वे वसीयत पर आधारित हैं
केवल प्राकृतिक छोरों को पहचानें, इसलिए आपको बस इस बात से अवगत रहना होगा कि वहाँ हो सकता है
सीएफजी चक्र बनें जिन्हें लूप के रूप में पहचाना नहीं जाता है। बेशक, अन्य
अनुकूलन प्रकृति में अधिक स्थानीय हैं और इरेड्यूसिबल के साथ ठीक काम करते हैं
सीएफ़जी.

स्मृति से, और शायद गलत, SPEC2006 में एक इरेड्यूसबल लूप है
401.bzip2 में और बस। व्यवहार में यह काफी दुर्लभ है।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/796#issuecomment-295352983 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALnq1K99AR5YaQuNOIFIckLLSIZbmbd0ks5rxkJQgaJpZM4J3ofA
.

अपरिवर्तनीय नियंत्रण प्रवाह के रैखिक-समय सत्यापन के लिए स्थापित विधियां हैं। एक उल्लेखनीय उदाहरण जेवीएम है: स्टैकमैप्स के साथ, इसमें रैखिक-समय सत्यापन होता है। WebAssembly के पास पहले से ही प्रत्येक ब्लॉक जैसे निर्माण पर ब्लॉक हस्ताक्षर हैं। प्रत्येक बिंदु पर स्पष्ट प्रकार की जानकारी के साथ जहां एकाधिक नियंत्रण प्रवाह पथ विलय होते हैं, निश्चित-बिंदु एल्गोरिदम का उपयोग करना आवश्यक नहीं है।

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

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

आह ... मैं पहले जवाब देना चाहता था लेकिन जीवन रास्ते में आ गया।

मैं कुछ जेएस इंजनों के माध्यम से पकड़ रहा हूं और मुझे लगता है कि मुझे 'बस काम कर रहे' अपरिवर्तनीय नियंत्रण प्रवाह के बारे में अपने दावे को कमजोर करना होगा। मुझे अभी भी नहीं लगता कि इसे काम करना इतना कठिन होगा, लेकिन कुछ ऐसे निर्माण हैं जिन्हें इस तरह से अनुकूलित करना मुश्किल होगा जिससे वास्तव में लाभ होगा ...

ठीक है, मान लेते हैं, तर्क के लिए, कि अनुकूलन पाइपलाइन समर्थन को इरेड्यूसेबल नियंत्रण प्रवाह को ठीक से बनाना बहुत कठिन है। एक जेएस इंजन अभी भी आसानी से हैकी तरीके से इसका समर्थन कर सकता है, जैसे:

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

इसके साथ समस्याएं हो सकती हैं, उदाहरण के लिए, कोई भी अनुकूलन जो शाखाओं को मर्ज/डिलीट करता है, लेकिन इससे बचना बहुत आसान होना चाहिए; विवरण इंजन डिजाइन पर निर्भर करता है।

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

किसी भी तरह, हैकी दृष्टिकोण के लिए स्पष्ट नकारात्मक पक्ष यह है कि अनुकूलन वास्तविक नियंत्रण प्रवाह ग्राफ को नहीं समझते हैं; वे प्रभावी ढंग से कार्य करते हैं जैसे कि कोई भी लेबल किसी अन्य लेबल पर जा सकता है। विशेष रूप से, रजिस्टर आवंटन को एक चर को सभी लेबलों में लाइव के रूप में मानना ​​​​है, भले ही, कहें, यह हमेशा एक विशिष्ट लेबल पर कूदने से पहले असाइन किया जाता है, जैसा कि इस छद्म कोड में है:

a:
  control = 1;
  goto x;
b:
  control = 2;
  goto x;
...
x:
  // use control

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

जो भी हो, देर से ऑप्टिमाइज़ करना ऑप्टिमाइज़ न करने की तुलना में बहुत बेहतर है। एक सीधी छलांग एक छलांग + तुलना + भार + अप्रत्यक्ष छलांग की तुलना में बहुत अच्छी है; सीपीयू शाखा भविष्यवक्ता अंततः पिछले राज्य के आधार पर बाद के लक्ष्य की भविष्यवाणी करने में सक्षम हो सकता है, लेकिन साथ ही साथ संकलक भी नहीं कर सकता है। और आप 'वर्तमान स्थिति' चर पर एक रजिस्टर और/या स्मृति खर्च करने से बच सकते हैं।

प्रतिनिधित्व के लिए, जो बेहतर है: स्पष्ट ( labels निर्देश या समान) या निहित (वास्तविक लूप का अनुकूलन + एक विशिष्ट पैटर्न के बाद स्विच)?

निहित लाभ:

• विनिर्देश दुबला रखता है।

• मौजूदा लूप + स्विच कोड के साथ पहले से ही काम कर सकता है। लेकिन मैंने यह देखने के लिए बाइनरीन जेनरेट की गई सामग्री को नहीं देखा है कि यह सख्त पर्याप्त पैटर्न का पालन करता है या नहीं।

• इरेड्यूसेबल कंट्रोल फ्लो को व्यक्त करने का धन्य तरीका बनाना इस तथ्य पर प्रकाश डालता है कि यह सामान्य रूप से धीमा है और जब संभव हो तो इससे बचना चाहिए।

निहित करने के लिए कमियां:

• यह एक हैक की तरह लगता है। सच है, जैसा कि @titzer कहते हैं, यह वास्तव में उन इंजनों को नुकसान नहीं

• एक "ऑप्टिमाइज़ेशन क्लिफ" बनाता है, जिसे आमतौर पर JS की तुलना में WebAssembly से बचना चाहिए। पुन: गणना करने के लिए, अनुकूलित किया जाने वाला मूल पैटर्न है "जहां एक स्थानीय चर के लिए एक स्थिरांक का असाइनमेंट होता है, फिर एक शाखा एक सशर्त शाखा में होती है जो तुरंत उस स्थानीय चर पर स्विच हो जाती है"। लेकिन क्या होगा अगर, कहें, बीच में कुछ अन्य निर्देश हैं, या असाइनमेंट वास्तव में एक wasm const निर्देश का उपयोग नहीं कर रहा है, लेकिन केवल अनुकूलन के कारण स्थिर के रूप में जाना जाता है? कुछ इंजन दूसरों की तुलना में अधिक उदार हो सकते हैं जो वे इस पैटर्न के रूप में पहचानते हैं, लेकिन फिर कोड जो इसका लाभ उठाता है (जानबूझकर या नहीं) ब्राउज़रों के बीच काफी अलग प्रदर्शन होगा। अधिक स्पष्ट एन्कोडिंग होने से अपेक्षाएं अधिक स्पष्ट रूप से सेट होती हैं।

• काल्पनिक पोस्टप्रोसेसिंग चरणों में आईआर की तरह wasm का उपयोग करना कठिन बनाता है। यदि एक वास्म-टारगेटिंग कंपाइलर चीजों को सामान्य तरीके से करता है और अंत में एक रिलोपर चलाने से पहले एक आंतरिक आईआर के साथ सभी अनुकूलन/रूपांतरणों को संभालता है और अंततः वासम उत्पन्न करता है, तो यह जादू निर्देश अनुक्रमों के अस्तित्व पर ध्यान नहीं देगा। लेकिन अगर कोई प्रोग्राम wasm कोड पर ही कोई ट्रांसफॉर्मेशन चलाना चाहता है, तो उसे उन सीक्वेंस को तोड़ने से बचना होगा, जो कष्टप्रद होंगे।

वैसे भी, मुझे किसी भी तरह से परवाह नहीं है - जब तक, क्या हमें निहित दृष्टिकोण पर निर्णय लेना चाहिए, प्रमुख ब्राउज़र वास्तव में प्रासंगिक अनुकूलन करने के लिए प्रतिबद्ध हैं।

…

मूल रूप से अपरिवर्तनीय प्रवाह का समर्थन करने के सवाल पर वापस जा रहे हैं - बाधाएं क्या हैं, कितना लाभ है - यहां ऑप्टिमाइज़ेशन पास के IonMonkey से कुछ विशिष्ट उदाहरण दिए गए हैं जिन्हें इसका समर्थन करने के लिए संशोधित करना होगा:

AliasAnalysis.cpp: रिवर्स पोस्टऑर्डर (एक बार) में ब्लॉकों पर पुनरावृति करता है, और एक निर्देश के लिए ऑर्डरिंग निर्भरता उत्पन्न करता है (जैसा कि इंस्ट्रक्शन रीऑर्डरिंग में उपयोग किया जाता है) केवल पहले देखे गए स्टोर को संभवतः एलियासिंग के रूप में देखकर। यह चक्रीय नियंत्रण प्रवाह के लिए काम नहीं करता है। लेकिन (स्पष्ट रूप से चिह्नित) छोरों को विशेष रूप से नियंत्रित किया जाता है, एक दूसरे पास के साथ जो एक ही लूप में कहीं भी बाद के किसी भी स्टोर के खिलाफ लूप में निर्देशों की जांच करता है।

-> तो labels ब्लॉक के लिए कुछ लूप मार्किंग होनी चाहिए। इस मामले में, मुझे लगता है कि पूरे labels ब्लॉक को लूप के रूप में चिह्नित करना 'बस काम करेगा' (व्यक्तिगत लेबल को विशेष रूप से चिह्नित किए बिना), क्योंकि विश्लेषण लूप के भीतर नियंत्रण प्रवाह की देखभाल करने के लिए बहुत सटीक है।

FlowAliasAnalysis.cpp: एक वैकल्पिक एल्गोरिथम जो थोड़ा अधिक स्मार्ट है। इसके अलावा रिवर्स पोस्टऑर्डर में ब्लॉकों पर पुनरावृति होती है, लेकिन प्रत्येक ब्लॉक का सामना करने पर यह लूप हेडर को छोड़कर, अपने प्रत्येक पूर्ववर्तियों (माना जाता है कि पहले से ही गणना की गई है) के लिए गणना की गई अंतिम-भंडार जानकारी को मर्ज करता है, जहां यह बैकएज को ध्यान में रखता है।

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

BacktrackingAllocator.cpp: रजिस्टर आवंटन के लिए समान व्यवहार: यह निर्देशों की सूची के माध्यम से एक रैखिक रिवर्स पास करता है और मानता है कि एक निर्देश के सभी उपयोग इसके बाद दिखाई देंगे (यानी पहले संसाधित किया जा सकता है), लूप बैकेज का सामना करने के अलावा: रजिस्टर जो हैं एक लूप की शुरुआत में रहते हैं बस पूरे लूप के माध्यम से लाइव रहते हैं।

-> प्रत्येक लेबल को लूप हेडर की तरह व्यवहार करने की आवश्यकता होगी, लेकिन संपूर्ण लेबल ब्लॉक के लिए जीवंतता का विस्तार करना होगा। लागू करना मुश्किल नहीं है, लेकिन फिर से, परिणाम हैकी दृष्टिकोण से बेहतर नहीं होगा। मुझे लगता है।

@comex यहां एक और विचार यह है कि wasm इंजनों से कितना काम करने की उम्मीद है। उदाहरण के लिए, आप ऊपर आयन के उपनाम विश्लेषण का उल्लेख करते हैं, हालांकि कहानी का दूसरा पक्ष यह है कि उपनाम विश्लेषण WebAssembly कोड के लिए उतना महत्वपूर्ण नहीं है, कम से कम अभी के लिए जबकि अधिकांश प्रोग्राम रैखिक मेमोरी का उपयोग कर रहे हैं।

आयन के BacktrackingAllocator.cpp लाइवनेस एल्गोरिदम के लिए कुछ काम करने की आवश्यकता होगी, लेकिन यह निषेधात्मक नहीं होगा। अधिकांश आयन पहले से ही इरेड्यूसेबल नियंत्रण प्रवाह के विभिन्न रूपों को संभालता है, क्योंकि OSR लूप में कई प्रविष्टियाँ बना सकता है।

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

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

मुझे आईओएस पर क्यूमू बैकएंड के रूप में WebAssembly का उपयोग करने में दिलचस्पी है, जहां वेबकिट (और गतिशील लिंकर, लेकिन यह कोड हस्ताक्षर की जांच करता है) एकमात्र प्रोग्राम है जिसे स्मृति को निष्पादन योग्य के रूप में चिह्नित करने की अनुमति है। Qemu का कोडजन मानता है कि गोटो स्टेटमेंट किसी भी प्रोसेसर का एक हिस्सा होगा जिसके लिए उसे कोडजेन करना होगा, जो बिना गोटो को जोड़े एक WebAssembly बैकएंड को लगभग असंभव बना देता है।

@tbodt - क्या आप बाइनरीन के रिलोपर का उपयोग करने में सक्षम होंगे? आइए आप मूल रूप से Wasm-with-goto उत्पन्न करते हैं और फिर इसे Wasm के लिए संरचित नियंत्रण प्रवाह में परिवर्तित करते हैं।

@eholk ऐसा लगता है कि मशीन कोड के सीधे अनुवाद से

@tbodt बाइनरीएन का उपयोग रास्ते में एक अतिरिक्त आईआर जोड़ता है, हाँ, लेकिन यह बहुत धीमा नहीं होना चाहिए, मुझे लगता है, यह संकलन गति के लिए अनुकूलित है। और इसमें गोटो आदि को संभालने के अलावा अन्य लाभ भी हो सकते हैं क्योंकि आप वैकल्पिक रूप से बाइनरीएन ऑप्टिमाइज़र चला सकते हैं, जो कि क्यूमू ऑप्टिमाइज़र (wasm- विशिष्ट चीजें) नहीं करता है।

वास्तव में मुझे उस पर आपके साथ सहयोग करने में बहुत दिलचस्पी होगी, यदि आप चाहें :) मुझे लगता है कि क्यूमू को वासम में पोर्ट करना बहुत उपयोगी होगा।

तो दूसरे विचार पर, गोटो वास्तव में पूरी तरह से मदद नहीं करेगा। Qemu का कोडजन मूल ब्लॉकों के लिए कोड उत्पन्न करता है जब वे पहली बार चलाए जाते हैं। यदि कोई ब्लॉक उस ब्लॉक पर कूदता है जो अभी तक उत्पन्न नहीं हुआ है, तो यह ब्लॉक उत्पन्न करता है और पिछले ब्लॉक को गोटो के साथ अगले ब्लॉक में पैच करता है। जहां तक ​​​​मुझे पता है, गतिशील कोड लोडिंग और मौजूदा कार्यों की पैचिंग ऐसी चीजें नहीं हैं जो वेब असेंबली में की जा सकती हैं।

@kripken मुझे सहयोग करने में दिलचस्पी होगी, आपके साथ चैट करने के लिए सबसे अच्छी जगह कहां होगी?

आप मौजूदा कार्यों को सीधे पैच नहीं कर सकते हैं, लेकिन आप call_indirect और WebAssembly.Table को जिट कोड में उपयोग कर सकते हैं। किसी भी मूल ब्लॉक के लिए जो उत्पन्न नहीं हुआ है, आप जावास्क्रिप्ट को कॉल कर सकते हैं, WebAssembly मॉड्यूल और इंस्टेंस को सिंक्रोनाइज़ कर सकते हैं, निर्यात किए गए फ़ंक्शन को निकाल सकते हैं और इसे तालिका में इंडेक्स पर लिख सकते हैं। भविष्य की कॉल तब आपके जेनरेट किए गए फ़ंक्शन का उपयोग करेगी।

मुझे यकीन नहीं है कि किसी ने अभी तक यह कोशिश की है, हालांकि, कई खुरदुरे किनारों की संभावना है।

अगर टेलकॉल लागू किया गया तो यह काम कर सकता है। अन्यथा ढेर बहुत जल्दी बह जाएगा।

एक और चुनौती डिफ़ॉल्ट तालिका में स्थान आवंटित करना होगा। आप किसी तालिका अनुक्रमणिका में पता कैसे मैप करते हैं?

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

(लेकिन हो सकता है कि हम आलसी के बजाय पूरे कार्य को संकलित करने के लिए क्यूमू प्राप्त कर सकें?)

@tbodt बाइनरीएन के साथ ऐसा करने पर सहयोग के लिए, एक विकल्प है कि आप अपने काम के साथ एक रेपो बनाएं (और वहां मुद्दों का उपयोग कर सकते हैं), दूसरा क्यूमु के लिए बाइनरीन में एक विशिष्ट मुद्दा खोलना है।

हम एक समय में पूरे फ़ंक्शन को संकलित करने के लिए qemu नहीं प्राप्त कर सकते हैं, क्योंकि qemu में "फ़ंक्शन" की अवधारणा नहीं है।

जहां तक ​​ब्लॉकों के पूरे कैश को पुन: संकलित करने की बात है, ऐसा लगता है कि इसमें काफी समय लग सकता है। मैं समझूंगा कि क्यूमू के बिल्टिन प्रोफाइलर का उपयोग कैसे करें और फिर बाइनरीन पर एक समस्या खोलें।

पार्श्व प्रश्न। मेरे विचार में, WebAssembly को लक्षित करने वाली भाषा कुशल पारस्परिक रूप से पुनरावर्ती कार्य प्रदान करने में सक्षम होनी चाहिए। उनकी उपयोगिता के चित्रण के लिए मैं आपको पढ़ने के लिए आमंत्रित करता हूं: http://sharp-gamedev.blogspot.com/2011/08/forgotten-control-flow-construct.html

विशेष रूप से, चीरी द्वारा व्यक्त की गई आवश्यकता को पारस्परिक रूप से पुनरावर्ती कार्य द्वारा संबोधित किया जाता है।

मैं पूंछ रिकर्सन की आवश्यकता को समझता हूं, लेकिन मैं सोच रहा हूं कि पारस्परिक रूप से रिकर्सिव फ़ंक्शन केवल तभी लागू किया जा सकता है जब अंतर्निहित मशीनरी गोटो प्रदान करती है या नहीं। यदि वे करते हैं, तो मेरे लिए जो उनके पक्ष में वैध तर्क देता है क्योंकि प्रोग्रामिंग भाषा का एक टन होगा जो अन्यथा WebAssembly को लक्षित करने में कठिन समय होगा। यदि वे नहीं करते हैं तो शायद पारस्परिक रूप से पुनरावर्ती कार्य का समर्थन करने के लिए न्यूनतम तंत्र की आवश्यकता होगी (पूंछ रिकर्सन के साथ)।

@davidgrenier , एक Wasm मॉड्यूल में कार्य सभी परस्पर पुनरावर्ती हैं। क्या आप विस्तार से बता सकते हैं कि आप उनके बारे में क्या अक्षम मानते हैं? क्या आप केवल टेल कॉल्स की कमी या कुछ और की बात कर रहे हैं?

जनरल टेल कॉल आ रहे हैं। पूंछ रिकर्सन (आपसी या अन्यथा) इसका एक विशेष मामला होगा।

मैं यह नहीं कह रहा था कि उनके बारे में कुछ भी अक्षम नहीं था। मैं कह रहा हूं, कि यदि आपके पास है, तो आपको सामान्य गोटो की आवश्यकता नहीं है क्योंकि पारस्परिक रूप से पुनरावर्ती कार्य वह सभी भाषा कार्यान्वयनकर्ता प्रदान करते हैं जो WebAssembly को लक्षित करने की आवश्यकता होनी चाहिए।

दृश्य प्रोग्रामिंग में आरेखों से कोड निर्माण के लिए गोटो बहुत उपयोगी है। हो सकता है कि अब विज़ुअल प्रोग्रामिंग बहुत लोकप्रिय नहीं है लेकिन भविष्य में इसे और अधिक लोग मिल सकते हैं और मुझे लगता है कि wasm को इसके लिए तैयार रहना चाहिए। आरेखों और गोटो से कोड निर्माण के बारे में अधिक जानकारी: http://drakon-editor.sourceforge.net/generation.html

आगामी Go 1.11 रिलीज़ को WebAssembly के लिए प्रायोगिक समर्थन प्राप्त होगा। इसमें गो की सभी सुविधाओं के लिए पूर्ण समर्थन शामिल होगा, जिसमें गोरौटाइन, चैनल आदि शामिल हैं। हालांकि, उत्पन्न WebAssembly का प्रदर्शन वर्तमान में उतना अच्छा नहीं है।

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

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

हमारे लिए रिलूपर एल्गोरिथम का उपयोग करना कोई विकल्प नहीं है, क्योंकि गोरोइन के बीच स्विच करते समय हमें किसी फ़ंक्शन के विभिन्न बिंदुओं पर निष्पादन को फिर से शुरू करने में सक्षम होना चाहिए।

बस स्पष्ट करने के लिए, उसके लिए एक नियमित गोटो पर्याप्त नहीं होगा, आपके उपयोग के मामले के लिए एक गणना गोटो आवश्यक है, क्या यह सही है?

मुझे लगता है कि प्रदर्शन के मामले में नियमित गोटो शायद पर्याप्त होगा। बुनियादी ब्लॉकों के बीच कूद वैसे भी स्थिर होते हैं और गोरोइन्स को स्विच करने के लिए br_table इसकी शाखाओं में गोटो के साथ पर्याप्त प्रदर्शनकारी होना चाहिए। आउटपुट आकार हालांकि एक अलग सवाल है।

ऐसा लगता है कि आपके पास प्रत्येक फ़ंक्शन में सामान्य नियंत्रण प्रवाह है, लेकिन गोरोइन को फिर से शुरू करते समय फ़ंक्शन प्रविष्टि से "मध्य" में कुछ अन्य स्थानों पर कूदने की क्षमता की भी आवश्यकता होती है - ऐसे कितने स्थान हैं? यदि यह हर एक बुनियादी ब्लॉक है, तो रिलोपर को एक टॉपलेवल लूप उत्सर्जित करने के लिए मजबूर किया जाएगा, जिससे प्रत्येक निर्देश गुजरता है, लेकिन यदि यह केवल कुछ ही है, तो यह कोई समस्या नहीं होनी चाहिए। (यह वास्तव में emscripten में setjmp समर्थन के साथ होता है - हम केवल LLVM के मूल ब्लॉकों के बीच अतिरिक्त आवश्यक पथ बनाते हैं, और सामान्य रूप से relooper प्रक्रिया करते हैं।)

किसी अन्य फ़ंक्शन के लिए प्रत्येक कॉल एक ऐसा स्थान होता है और अधिकांश बुनियादी ब्लॉकों में कम से कम एक कॉल निर्देश होता है। हम कमोबेश अनइंडिंग कर रहे हैं और कॉल स्टैक को पुनर्स्थापित कर रहे हैं।

मैं देखता हूँ, धन्यवाद। हाँ, मैं मानता हूँ कि इसके लिए व्यावहारिक होने के लिए आपको या तो स्थिर गोटो या कॉल स्टैक रिस्टोरिंग सपोर्ट की आवश्यकता है (जिस पर भी विचार किया गया है)।

क्या सीपीएस शैली में फ़ंक्शन को कॉल करना या WASM में call/cc लागू करना संभव होगा?

@ हेमडेल , कुछ प्रकार के

इस सूत्र के माध्यम से पढ़ने पर, मुझे यह आभास होता है कि सुविधा बनने से पहले मनमाने लेबल और गोटो में एक बड़ी बाधा है:

• असंरचित नियंत्रण प्रवाह अपरिवर्तनीय नियंत्रण प्रवाह रेखांकन को संभव बनाता है
• किसी भी "तेज़, सरल सत्यापन, आसान, एसएसए फॉर्म में एक पास रूपांतरण" को समाप्त करना
• गैर-रैखिक प्रदर्शन के लिए जेआईटी कंपाइलर खोलना
• यदि मूल भाषा संकलक अग्रिम कार्य कर सकता है, तो वेबपृष्ठ ब्राउज़ करने वाले लोगों को विलंब का सामना नहीं करना चाहिए

_*हालांकि ब्रौन एट अल के ऑन-द-फ्लाई एसएसए निर्माण एल्गोरिथम जैसे विकल्प हो सकते हैं जो इरेड्यूसेबल कंट्रोल फ्लो को संभालते हैं_

यदि हम अभी भी वहीं अटके हुए हैं, _and_ टेल कॉल आगे बढ़ रहे हैं, तो शायद यह भाषा कंपाइलरों को अभी भी गोटो में अनुवाद करने के लिए कहने लायक होगा, लेकिन WebAssembly आउटपुट से पहले अंतिम चरण के रूप में, "लेबल ब्लॉक" को फ़ंक्शंस में विभाजित करें, और गोटो को टेल कॉल में बदलें।

स्कीम डिजाइनर गाय स्टील के 1977 के पेपर, लैम्ब्डा: द अल्टीमेट गोटो के अनुसार , परिवर्तन संभव होना चाहिए, और टेल कॉल का प्रदर्शन

विचार?

यदि हम अभी भी वहीं अटके हुए हैं, _and_ टेल कॉल आगे बढ़ रहे हैं, तो शायद यह भाषा कंपाइलरों को अभी भी गोटो में अनुवाद करने के लिए कहने लायक होगा, लेकिन WebAssembly आउटपुट से पहले अंतिम चरण के रूप में, "लेबल ब्लॉक" को फ़ंक्शंस में विभाजित करें, और गोटो को टेल कॉल में बदलें।

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

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

साथ ही यह GCC और Go को WebAssembly का उत्पादन शुरू करने की अनुमति देगा।

मुझे पता है कि V8 WebAssembly पारिस्थितिकी तंत्र का एक महत्वपूर्ण घटक है, लेकिन यह उस पारिस्थितिकी तंत्र का एकमात्र हिस्सा लगता है जो वर्तमान नियंत्रण प्रवाह की स्थिति से लाभान्वित होता है, अन्य सभी बैकएंड जिन्हें मैं वैसे भी CFG में बदलने के बारे में जानता हूं और इससे अप्रभावित हैं WebAssembly अपरिवर्तनीय नियंत्रण प्रवाह का प्रतिनिधित्व कर सकता है या नहीं।

संबंधित लेख: WebAssembly समस्याएँ भाग 2: हमें फिर से लूपर एल्गोरिथ्म की आवश्यकता क्यों है?

इनपुट CFGs स्वीकार करने के लिए v8 सिर्फ relooper को शामिल नहीं कर सका? ऐसा लगता है कि पारिस्थितिकी तंत्र के बड़े हिस्से v8 के कार्यान्वयन विवरण पर अवरुद्ध हैं।

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

@graph , क्या आप इस बारे में अधिक जानकारी प्रदान कर सकते हैं कि "स्विच स्टेटमेंट धीमे कैसे हैं"? हमेशा प्रदर्शन में सुधार करने के अवसर की तलाश में... (यदि आप इस धागे को बंद नहीं करना चाहते हैं, तो मुझे सीधे ईमेल करें, [email protected]।)

मैं यहां पोस्ट करूंगा क्योंकि यह सभी ब्राउज़रों पर लागू होता है। इस तरह के सरल बयान जब एमस्क्रिप्टन के साथ संकलित किए जाते हैं, जहां तेजी से जब मैं बयानों में परिवर्तित होता हूं।

for(y = ....) {
    for(x = ....) {
        switch(type){
        case IS_RGBA:....
         ....
        case IS_BGRA
        ....
        case IS_RGB
        ....
....

मुझे लगता है कि संकलक एक जंप टेबल को जो कुछ भी समर्थन करता है उसे परिवर्तित कर रहा था। मैंने जेनरेट असेंबली में नहीं देखा इसलिए पुष्टि नहीं कर सकता।

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

@graph एक पूर्ण बेंचमार्क यहां बहुत मददगार होगा। सामान्य तौर पर, सी में एक स्विच वासम में एक बहुत तेज़ कूद तालिका में बदल सकता है, लेकिन ऐसे कोने के मामले हैं जो अभी तक अच्छी तरह से काम नहीं करते हैं, जिन्हें हमें एलएलवीएम या ब्राउज़र में ठीक करने की आवश्यकता हो सकती है।

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

@graph , अगर emscripten एक br_table उत्पन्न करता है तो jit कभी-कभी एक जंप टेबल उत्पन्न करेगा और कभी-कभी (यदि यह सोचता है कि यह तेज़ होगा) यह मुख्य स्थान को रैखिक रूप से या इन-लाइन बाइनरी खोज के साथ खोजेगा। यह क्या करता है अक्सर स्विच के आकार पर निर्भर करता है। यह निश्चित रूप से संभव है कि चयन नीति इष्टतम नहीं है ... मैं @kripken से सहमत रननेबल कोड यहां बहुत उपयोगी होगा।

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

@ lars-t-hansen @kripken @graph यह अच्छी तरह से हो सकता है कि br_table वर्तमान में बहुत ही गैर-अनुकूलित है जैसा कि यह एक्सचेंज दिखाता है: https://twitter.com/battagline/status/1168310096515883008

@aardappel , यह उत्सुक है, कल मैंने जो बेंचमार्क चलाया, वह यह नहीं दिखा, मेरे सिस्टम पर फ़ायरफ़ॉक्स में ब्रेक-ईवन पॉइंट लगभग 5 मामलों में था जैसा कि मुझे याद है और उसके बाद br_table विजेता था। निश्चित रूप से माइक्रोबेंचमार्क, और लुकअप कुंजियों के समान वितरण के कुछ प्रयासों के साथ। यदि "अगर" घोंसला सबसे संभावित चाबियों की ओर पक्षपाती है ताकि कुछ से अधिक परीक्षणों की आवश्यकता न हो तो "अगर" घोंसला जीत जाएगा।

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

@ लार्स-टी-हैनसेन हां, हम उसके परीक्षण मामले को नहीं जानते हैं, हो सकता है कि इसका कोई बाहरी मूल्य हो। किसी भी तरह, ऐसा लगता है कि क्रोम के पास फ़ायरफ़ॉक्स की तुलना में अधिक काम है।

मैं छुट्टी पर हूं, इसलिए मेरे उत्तरों की कमी है। समझने के लिए धन्यवाद।

@kripken @ lars-t-hansen मैंने कुछ परीक्षण चलाए हैं ऐसा लगता है कि हाँ यह फ़ायरफ़ॉक्स में अब बेहतर है। अभी भी कुछ मामले हैं जहां अगर-और-आउट-प्रदर्शन स्विच करते हैं। यहाँ एक मामला है:

#include <stdio.h>

#include <chrono>
#include <random>

class Chronometer {
public:
    Chronometer() {

    }

    void start() {
        mStart = std::chrono::steady_clock::now();
    }

    double seconds() {
        std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
        return std::chrono::duration_cast<std::chrono::duration<double>>(end - mStart).count();
    }

private:
    std::chrono::steady_clock::time_point mStart;
};

int main() {
    printf("Starting tests!\n");
    Chronometer timer;
    // we want to prevent optimizations based on known size as most applications
    // do not know the size in advance.
    std::random_device rd;  //Will be used to obtain a seed for the random number engine
    std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
    std::uniform_int_distribution<> dis(100000000, 1000000000);
    std::uniform_int_distribution<> opKind(0, 3);
    int maxFrames = dis(gen);
    int switchSelect = 0;
    constexpr int SW1 = 1;
    constexpr int SW2 = 8;
    constexpr int SW3 = 32;
    constexpr int SW4 = 38;

    switch(opKind(gen)) {
    case 0:
        switchSelect = SW1;
        break;
    case 1:
        switchSelect = SW2; break;
    case 2:
        switchSelect = SW3; break;
    case 4:
        switchSelect = SW4; break;
    }
    printf("timing with SW = %d\n", switchSelect);
    timer.start();
    int accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        switch(switchSelect) {
        case SW1:
            accumulator = accumulator*3 + i; break;
        case SW2:
            accumulator = (accumulator < 3)*i; break;
        case SW3:
            accumulator = (accumulator&0xFF)*i + accumulator; break;
        case SW4:
            accumulator = (accumulator*accumulator) - accumulator + i; break;
        }
    }
    printf("switch time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);
    timer.start();
    accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        if(switchSelect == SW1)
            accumulator = accumulator*3 + i;
        else if(switchSelect == SW2)
            accumulator = (accumulator < 3)*i;
        else if(switchSelect == SW3)
            accumulator = (accumulator&0xFF)*i + accumulator;
        else if(switchSelect == SW4)
            accumulator = (accumulator*accumulator) - accumulator + i;
    }
    printf("if-else time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);

    return 0;
}

स्विच के मूल्य के आधार पर चयन करें। अगर-अन्य बेहतर प्रदर्शन करते हैं। उदाहरण आउटपुट:

Starting tests!
timing with SW = 32
switch time = 2.049000 seconds
accumulated value: 0
if-else time = 0.401000 seconds
accumulated value: 0

जैसा कि आप स्विच सेलेक्ट = 32 के लिए देख सकते हैं अगर-और तेज़ है। अन्य मामलों के लिए अगर-थोड़ा तेज है। केस स्विच सेलेक्ट = 1 और 0 के लिए, स्विच स्टेटमेंट तेज है।

Test in Firefox 69.0.3 (64-bit)
compiled using: emcc -O3 -std=c++17 main.cpp -o main.html
emcc version: emcc (Emscripten gcc/clang-like replacement) 1.39.0 (commit e047fe4c1ecfae6ba471ca43f2f630b79516706b)

20 अक्टूबर 2019 तक नवीनतम स्थिर एमस्क्रिपेन का उपयोग करना। ताजा इंस्टॉल ./emcc activate latest ।

मैंने ऊपर देखा कि एक टाइपो है, लेकिन यह इस मामले को प्रभावित नहीं करना चाहिए कि अगर-और तेज़ SW3 केस है क्योंकि वे समान निर्देश निष्पादित कर रहे हैं।

फिर से यह 5 के ब्रेक ईवन पॉइंट से भी आगे जा रहा है: दिलचस्प है कि इस मामले के लिए स्विचसेलेक्ट = 32 के लिए यह गति में समान है जैसे कि और। जैसा कि आप 1003 के लिए देख सकते हैं अगर-थोड़ा तेज है। इस मामले में स्विच जीतना चाहिए।

Starting tests!
timing with SW = 1003
switch time = 2.253000 seconds
accumulated value: 1903939380
if-else time = 2.197000 seconds
accumulated value: 1903939380

#include <stdio.h>

#include <chrono>
#include <random>

class Chronometer {
public:
    Chronometer() {

    }

    void start() {
        mStart = std::chrono::steady_clock::now();
    }

    double seconds() {
        std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
        return std::chrono::duration_cast<std::chrono::duration<double>>(end - mStart).count();
    }

private:
    std::chrono::steady_clock::time_point mStart;
};

int main() {
    printf("Starting tests!\n");
    Chronometer timer;
    // we want to prevent optimizations based on known size as most applications
    // do not know the size in advance.
    std::random_device rd;  //Will be used to obtain a seed for the random number engine
    std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
    std::uniform_int_distribution<> dis(100000000, 1000000000);
    std::uniform_int_distribution<> opKind(0, 8);
    int maxFrames = dis(gen);
    int switchSelect = 0;
    constexpr int SW1 = 1;
    constexpr int SW2 = 8;
    constexpr int SW3 = 32;
    constexpr int SW4 = 38;
    constexpr int SW5 = 64;
    constexpr int SW6 = 67;
    constexpr int SW7 = 1003;
    constexpr int SW8 = 256;

    switch(opKind(gen)) {
    case 0:
        switchSelect = SW1;
        break;
    case 1:
        switchSelect = SW2; break;
    case 2:
        switchSelect = SW3; break;
    case 3:
        switchSelect = SW4; break;
    case 4:
        switchSelect = SW5; break;
    case 5:
        switchSelect = SW6; break;
    case 6:
        switchSelect = SW7; break;
    case 7:
        switchSelect = SW8; break;
    }
    printf("timing with SW = %d\n", switchSelect);
    timer.start();
    int accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        switch(switchSelect) {
        case SW1:
            accumulator = accumulator*3 + i; break;
        case SW2:
            accumulator = (accumulator < 3)*i; break;
        case SW3:
            accumulator = (accumulator&0xFF)*i + accumulator; break;
        case SW4:
            accumulator = (accumulator*accumulator) - accumulator + i; break;
        case SW5:
            accumulator = (accumulator << 3) - accumulator + i; break;
        case SW6:
            accumulator = (i - accumulator) & 0xFF; break;
        case SW7:
            accumulator = i*i + accumulator; break;
        }
    }
    printf("switch time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);
    timer.start();
    accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        if(switchSelect == SW1)
            accumulator = accumulator*3 + i;
        else if(switchSelect == SW2)
            accumulator = (accumulator < 3)*i;
        else if(switchSelect == SW3)
            accumulator = (accumulator&0xFF)*i + accumulator;
        else if(switchSelect == SW4)
            accumulator = (accumulator*accumulator) - accumulator + i;
        else if(switchSelect == SW5)
            accumulator = (accumulator << 3) - accumulator + i;
        else if(switchSelect == SW6)
            accumulator = (i - accumulator) & 0xFF;
        else if(switchSelect == SW7)
            accumulator = i*i + accumulator;

    }
    printf("if-else time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);

    return 0;
}

इन परीक्षण मामलों पर एक नज़र डालने के लिए धन्यवाद दोस्तों।

हालांकि यह एक बहुत ही विरल switch है, जिसे एलएलवीएम को वैसे भी अगर-फिर के सेट के बराबर में परिवर्तित करना चाहिए, लेकिन जाहिर तौर पर यह इस तरह से करता है जो मैनुअल की तुलना में कम कुशल है। क्या आपने यह देखने के लिए wasm2wat चलाने की कोशिश की है कि ये दो लूप कोड में कैसे भिन्न हैं?

यह प्रत्येक पुनरावृत्ति पर समान मान का उपयोग करके इस परीक्षण पर भी दृढ़ता से निर्भर करता है। यह परीक्षण बेहतर होगा यदि यह सभी मूल्यों के माध्यम से साइकिल चलाए, या बेहतर अभी तक, उनमें से यादृच्छिक रूप से चुना गया (यदि वह सस्ते में किया जा सकता है)।

बेहतर अभी तक, लोगों द्वारा प्रदर्शन के लिए स्विच का उपयोग करने का वास्तविक कारण एक घनी सीमा के साथ है, इसलिए आप गारंटी दे सकते हैं कि यह वास्तव में नीचे br_table का उपयोग कर रहा है। यह देखना कि कितने मामलों में br_table if से तेज है, यह जानना सबसे उपयोगी बात होगी।

तंग लूप में स्विच का उपयोग किया गया था क्योंकि यह प्रदर्शन पर क्लीनर कोड था। लेकिन wasm के लिए प्रदर्शन प्रभाव बहुत बड़ा था इसलिए इसे बदसूरत if-statement में बदल दिया गया था। मेरे उपयोग के बहुत से मामलों में छवि प्रसंस्करण के लिए यदि मैं एक स्विच से अधिक प्रदर्शन चाहता हूं, तो मैं स्विच को लूप के बाहर ले जाऊंगा, और बस प्रत्येक मामले के लिए लूप की प्रतियां रखूंगा। आम तौर पर स्विच केवल पिक्सेल प्रारूप, रंग प्रारूप, एन्कोडिंग और आदि के कुछ रूपों के बीच स्विच कर रहा है ... और कई मामलों में स्थिरांक की गणना परिभाषित या एनम के माध्यम से की जाती है न कि रैखिक। अब मैं देखता हूं कि मेरा मुद्दा गोटो डिजाइन से संबंधित नहीं है। मेरे स्विच स्टेटमेंट के लिए क्या हो रहा था, इसके बारे में मुझे अभी अधूरी समझ थी। मुझे उम्मीद है कि इन मामलों में इमेज प्रोसेसिंग के लिए wasm को ऑप्टिमाइज़ करने के लिए इसे पढ़ने वाले ब्राउज़र देवों के लिए मेरे नोट्स उपयोगी हैं। शुक्रिया।

मैंने कभी नहीं सोचा था कि गोटो इतनी गर्म बहस हो सकती है । मैं हर भाषा की नाव में एक गोटो होना चाहिए। गोटो जोड़ने का एक अन्य कारण यह है कि यह संकलक के लिए wasm को संकलित करने की जटिलता को कम करता है। मुझे पूरा यकीन है कि ऊपर कहीं उल्लेख किया गया है। अब मेरे पास के बारे में शिकायत करने के लिए कुछ नहीं है।

वहां कोई और प्रगति?

गरमागरम बहस के कारण मुझे लगता है कि कुछ ब्राउज़र गैर-मानक बाइटकोड एक्सटेंशन के रूप में गोटो के लिए समर्थन जोड़ देंगे। तब शायद जीसीसी एक गैर-मानक संस्करण के समर्थन के रूप में खेल में प्रवेश कर सकता है। जो मुझे नहीं लगता कि कुल मिलाकर अच्छा है लेकिन अधिक कंपाइलर प्रतियोगिता की अनुमति देगा। क्या इस पर विचार किया गया है?

हाल ही में बहुत प्रगति नहीं हुई है, लेकिन आप funclets प्रस्ताव को देखना

@ मेरे लिए
यह उस तरह काम नहीं करता है। वर्तमान WebAssembly संरचना से कई लाभ हैं (जो स्पष्ट नहीं हैं, दुर्भाग्य से)। वासम के दर्शन में गहराई से गोता लगाने का प्रयास करें।

"मनमाने ढंग से लेबल और गोटोस" की अनुमति देना हमें गैर-सत्यापन योग्य बाइटकोड के (प्राचीन) समय में वापस लाएगा। सभी कंपाइलर "इसे सही तरीके से करने" के बजाय, चीजों को करने के "आलसी तरीके" पर स्विच करेंगे।

यह स्पष्ट है कि वर्तमान स्थिति में wasm में कुछ प्रमुख चूक हैं। लोग अंतराल को भरने पर काम कर रहे हैं (जैसे @binji द्वारा नहीं लगता कि "वैश्विक ततैया संरचना" को फिर से काम करने की आवश्यकता है। बस मेरी विनम्र राय।

@vshymanskyy funclets प्रस्ताव, जो मनमानी लेबल और गोटो के बराबर कार्यक्षमता प्रदान करता है, रैखिक समय में पूरी तरह से मान्य है।

मुझे यह भी उल्लेख करना चाहिए कि हमारे रैखिक-समय के वासम कंपाइलर में, हम आंतरिक रूप से सभी वासम नियंत्रण प्रवाह को एक फ़ंकलेट-जैसे प्रतिनिधित्व में संकलित करते हैं, जिसके बारे में मुझे इस ब्लॉक पोस्ट में कुछ जानकारी है और इस आंतरिक प्रतिनिधित्व के लिए वासम नियंत्रण प्रवाह से रूपांतरण लागू किया गया है। यहाँ । कंपाइलर को इसकी सभी प्रकार की जानकारी इस फ़ंकलेट-जैसे प्रतिनिधित्व से मिलती है, इसलिए यह कहना पर्याप्त है कि रैखिक समय में इसकी प्रकार-सुरक्षा को मान्य करना तुच्छ है।

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

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

ईमानदारी से, मैंने अपनी नाक यहाँ पर अटकी हुई है क्योंकि वर्षों पहले, मैं WASM के लिए एक TinyCC पोर्ट बनाने की कोशिश कर रहा था ताकि मैं ESP8266 पर ESP8266 को लक्षित करते हुए एक विकास वातावरण चला सकूं। मेरे पास केवल ~ 4 एमबी स्टोरेज है, इसलिए री-लूपर और एएसटी पर स्विच करने के साथ-साथ कई अन्य बदलाव सवाल से बाहर हैं। (साइड-नोट: रिलोपर केवल रिलूपर की तरह ही कैसे है? यह बहुत भयानक है और किसी ने उस चूसने वाले को सी में फिर से नहीं लिखा है?) भले ही इस बिंदु पर यह संभव हो, मुझे नहीं पता कि मैं एक टिनीसीसी लक्ष्य लिखूंगा या नहीं WASM के लिए क्योंकि यह अब मेरे लिए उतना दिलचस्प नहीं है।

हालांकि यह धागा। पवित्र गाय इस धागे ने मुझे इतना अस्तित्वगत आनंद दिया है। लोकतंत्र या गणतंत्र, या धर्म की तुलना में मानवता में विभाजन को गहराई से देखना। मुझे ऐसा लगता है कि क्या इसे कभी हल किया जा सकता है। अगर ए बी की दुनिया में रहने के लिए आ सकता है, या बी ए के दावे को मान्य करता है कि प्रक्रियात्मक प्रोग्रामिंग का अपना स्थान है ... मुझे लगता है कि हम विश्व शांति को हल कर सकते हैं।

क्या V8 का प्रभारी कोई व्यक्ति इस सूत्र में पुष्टि कर सकता है कि इरेड्यूसेबल नियंत्रण प्रवाह के विरुद्ध विरोध V8 के वर्तमान कार्यान्वयन से प्रभावित नहीं है?

मैं पूछ रहा हूं क्योंकि यही मुझे सबसे ज्यादा परेशान करता है। मेरे लिए ऐसा लगता है कि इस सुविधा के पेशेवरों और विपक्षों के बारे में विशेष स्तर पर चर्चा होनी चाहिए। यह बिल्कुल भी प्रभावित नहीं होना चाहिए कि किसी विशेष कार्यान्वयन को वर्तमान में कैसे डिज़ाइन किया गया है। हालाँकि, ऐसे बयान आए हैं जो मुझे विश्वास दिलाते हैं कि V8 का कार्यान्वयन इसे प्रभावित कर रहा है। शायद मैं गलत हूँ। एक खुला बयान मदद कर सकता है।

खैर, यह जितना दुर्भाग्यपूर्ण है, अब तक मौजूद मौजूदा कार्यान्वयन इतने महत्वपूर्ण हैं कि भविष्य (संभवतः अतीत की तुलना में लंबा) इतना महत्वपूर्ण नहीं है। मैं यह समझाने की कोशिश कर रहा था कि # 1202 पर, कुछ कार्यान्वयन की तुलना में स्थिरता अधिक महत्वपूर्ण है, लेकिन ऐसा लगता है कि मैं भ्रम में हूं। यह समझाने का सौभाग्य है कि किसी परियोजना में कहीं न कहीं कुछ विकास निर्णय एक सार्वभौमिक सत्य का गठन नहीं कर रहे हैं, या डिफ़ॉल्ट रूप से, सही माना जाना चाहिए।

यह धागा W3C कोयला खदान में एक कैनरी है। हालांकि कई W3C व्यक्तियों के लिए मेरे मन में बहुत सम्मान है, लेकिन जावास्क्रिप्ट को एक्मा इंटरनेशनल को सौंपने का निर्णय, और W3C को नहीं, बिना किसी पूर्वाग्रह के किया गया था।

@cnlohr की तरह, मुझे TCC wasm पोर्ट की उम्मीद थी, और अच्छे कारण के लिए;

"Wasm को प्रोग्रामिंग भाषाओं के लिए एक पोर्टेबल संकलन लक्ष्य के रूप में डिज़ाइन किया गया है, जो क्लाइंट और सर्वर अनुप्रयोगों के लिए वेब पर परिनियोजन को सक्षम बनाता है।" - webassembly.org

निश्चित रूप से, कोई भी प्रमाणित कर सकता है कि क्यों goto [INSERT JARGON] है, लेकिन हम राय पर मानकों को कैसे प्राथमिकता देते हैं। हम सभी सहमत हो सकते हैं कि POSIX C एक अच्छा आधारभूत लक्ष्य है, विशेष रूप से यह देखते हुए कि आज के लैंग्स या तो C से गढ़े गए हैं या बेंचमार्क किए गए हैं और WASM का होमपेज हेडलाइन खुद को लैंग्स के लिए एक पोर्टेबल संकलन लक्ष्य बताता है। ज़रूर, कुछ सुविधाओं को थ्रेड और सिम की तरह रोडमैप किया जाएगा। लेकिन, goto रूप में मौलिक के रूप में पूरी तरह से अवहेलना करने के लिए, इसे रोडमैपिंग की शालीनता भी नहीं देना, WASM के घोषित उद्देश्य और मानकीकरण निकाय के इस तरह के रुख के अनुरूप नहीं है जो <marquee> को हरा देता है। पीलापन से परे है।

SEI CERT C कोडिंग स्टैंडर्ड Rec के अनुसार। "संसाधनों का उपयोग और जारी करते समय त्रुटि पर फ़ंक्शन छोड़ते समय गोटो श्रृंखला का उपयोग करने पर विचार करें" ;

कई कार्यों के लिए कई संसाधनों के आवंटन की आवश्यकता होती है। सभी आवंटित संसाधनों को मुक्त किए बिना इस फ़ंक्शन के बीच में कहीं भी विफल होने और लौटने से स्मृति रिसाव उत्पन्न हो सकता है। इस तरह से संसाधनों में से एक (या सभी) को मुक्त करना भूल जाना एक सामान्य त्रुटि है, इसलिए मुक्त संसाधनों के क्रम को बनाए रखते हुए एक गोटो श्रृंखला निकास को व्यवस्थित करने का सबसे सरल और साफ तरीका है।

अनुशंसा तब goto का उपयोग करके पसंदीदा पॉज़िक्स सी समाधान के साथ एक उदाहरण प्रदान करती है। आलोचना करने वाले इस बात की ओर इशारा करेंगे कि goto को अभी भी हानिकारक माना जाता है । दिलचस्प है, यह राय उन विशेष कोडिंग मानकों में से एक में सन्निहित नहीं है, केवल एक नोट है। जो हमें कैनरी में लाता है, जिसे "हानिकारक माना जाता है"।

बॉटमलाइन, "सीएसएस क्षेत्र" या goto को हानिकारक मानते हुए केवल उस समस्या के प्रस्तावित समाधान के साथ तौला जाना चाहिए जिसके लिए ऐसी सुविधा का उपयोग किया जाता है। यदि उक्त "हानिकारक" सुविधा को हटाना बिना किसी विकल्प के उचित उपयोग के मामलों को हटाने के बराबर है, तो यह कोई समाधान नहीं है, यह वास्तव में भाषा के उपयोगकर्ताओं के लिए हानिकारक है।

सी में भी कार्य शून्य लागत नहीं हैं। अगर कोई गोटो और लेबल के प्रतिस्थापन की पेशकश करता है, तो कृपया कैनिहाज! अगर कोई कहता है कि मुझे इसकी आवश्यकता नहीं है, तो उन्हें यह कैसे पता चलेगा? जब प्रदर्शन की बात आती है, तो goto हमें इंजीनियरों से बहस करने के लिए थोड़ा अतिरिक्त, कठिन दे सकता है कि हमें भाषा की शुरुआत के बाद से मौजूद प्रदर्शनकारी, आसानी से ग्रोक सुविधाओं की आवश्यकता नहीं है।

goto का समर्थन करने की योजना के बिना, WASM एक खिलौना संकलन लक्ष्य है, और यह ठीक है, शायद W3C वेब को इसी तरह देखता है। मुझे उम्मीद है कि WASM एक मानक के रूप में 32 बिट एड्रेस स्पेस में से उच्च तक पहुंच जाएगा, और संकलन दौड़ में प्रवेश करेगा। मुझे उम्मीद है कि इंजीनियरिंग प्रवचन "यह संभव नहीं है ..." से दूर हो सकता है ताकि जीसीसी सी एक्सटेंशन जैसे लेबल को वैल्यू के रूप में तेजी से ट्रैक किया जा सके क्योंकि डब्ल्यूएएसएम अद्भुत होना चाहिए। निजी तौर पर, टीसीसी इस बिंदु पर काफी अधिक प्रभावशाली और अधिक उपयोगी है, बिना सभी व्यर्थ पॉन्टीफिकेशन के, हिप्स्टर लैंडिंग पृष्ठ और चमकदार लोगो के बिना।

@d4tocchini :

SEI CERT C कोडिंग स्टैंडर्ड Rec के अनुसार। "संसाधनों का उपयोग और जारी करते समय त्रुटि पर फ़ंक्शन छोड़ते समय गोटो श्रृंखला का उपयोग करने पर विचार करें" ;

कई कार्यों के लिए कई संसाधनों के आवंटन की आवश्यकता होती है। सभी आवंटित संसाधनों को मुक्त किए बिना इस फ़ंक्शन के बीच में कहीं भी विफल होने और लौटने से स्मृति रिसाव उत्पन्न हो सकता है। इस तरह से संसाधनों में से एक (या सभी) को मुक्त करना भूल जाना एक सामान्य त्रुटि है, इसलिए मुक्त संसाधनों के क्रम को बनाए रखते हुए एक गोटो श्रृंखला निकास को व्यवस्थित करने का सबसे सरल और साफ तरीका है।

अनुशंसा तब goto का उपयोग करके पसंदीदा पॉज़िक्स सी समाधान के साथ एक उदाहरण प्रदान करती है। आलोचना करने वाले इस बात की ओर इशारा करेंगे कि goto को अभी भी हानिकारक माना जाता है । दिलचस्प बात यह है कि यह राय उन विशेष कोडिंग मानकों में शामिल नहीं है, केवल एक नोट है। जो हमें कैनरी में लाता है, जिसे "हानिकारक माना जाता है"।

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

@rossberg , उस उदाहरण में लेबल किए गए ब्रेक पर अच्छा बिंदु, लेकिन मैं आपकी गुणात्मक धारणा से असहमत हूं कि सी को "वापस गिरना" चाहिए। लेबल किए गए ब्रेक की तुलना में गोटो एक समृद्ध निर्माण है। यदि सी को पोर्टेबल संकलन लक्ष्यों में शामिल किया जाना है, और सी लेबल किए गए ब्रेक का समर्थन नहीं करता है, तो यह एक मूक बिंदु है। जावा ने ब्रेक/जारी रखा है जबकि पायथन ने प्रस्तावित सुविधा को अस्वीकार कर दिया है , और सूर्य जेवीएम और डिफ़ॉल्ट सीपीथन दोनों को सी में लिखा गया है, क्या आप सहमत नहीं होंगे कि सी समर्थित भाषा के रूप में प्राथमिकता सूची में उच्च होना चाहिए?

यदि goto को इतनी आसानी से विचार से हटा दिया जाना है, तो क्या एम्स्क्रिप्टेन के स्रोत के भीतर goto के सैकड़ों उपयोगों पर भी पुनर्विचार किया जाना चाहिए?

क्या कोई ऐसी भाषा है जिसे C में नहीं लिखा जा सकता है? C को एक भाषा के रूप में WASM की विशेषताओं को सूचित करना चाहिए। यदि आज के WASM के साथ POSIX C संभव नहीं है, तो आपका उचित रोडमैप है।

वास्तव में तर्क के विषय पर नहीं, लेकिन छाया नहीं डालने के लिए कि सामान्य रूप से तर्क में यादृच्छिक गलतियाँ यहाँ और वहाँ दुबकी हुई हैं:

पायथन ने ब्रेक का लेबल लगाया है

क्या आप विस्तार से समझा सकते हैं? (उर्फ: पायथन में लेबल ब्रेक नहीं हैं।)

@pfalcon , हाँ मेरा बुरा, मैंने पाइथन प्रस्तावित लेबल ब्रेक/जारी रखने और इसे अस्वीकार करने के लिए स्पष्ट करने के लिए अपनी टिप्पणी संपादित की

यदि गोटो को इतनी आसानी से विचार से हटा दिया जाना है, तो क्या एमस्क्रिप्टन के स्रोत के भीतर गोटो के सैकड़ों उपयोगों पर भी पुनर्विचार किया जाना चाहिए?

1) ध्यान दें कि उनमें से कितना musl libc में मौजूद है, सीधे emscripten में नहीं। (दूसरा सबसे अधिक उपयोग किया जाता है परीक्षण/थर्ड_पार्टी)
2) स्रोत स्तर के निर्माण बाइटकोड निर्देशों के समान नहीं हैं
3) Emscripten, wasm मानक के समान अमूर्तता के स्तर पर नहीं है, इसलिए, नहीं, उस आधार पर इस पर पुनर्विचार नहीं किया जाना चाहिए।

विशेष रूप से, यह आज उपयोगी हो सकता है कि libc से गोटो को फिर से लिखा जाए, क्योंकि तब हमारे पास परिणामी cfg पर अधिक नियंत्रण होगा, जो इसे अच्छी तरह से संभालने के लिए relooper/cfgstackify पर भरोसा करने से अधिक होगा। हमने ऐसा नहीं किया है क्योंकि यह अपस्ट्रीम मसल से बेतहाशा भिन्न कोड के साथ काम करने की एक गैर-तुच्छ राशि है।

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

मानकीकरण निकाय की ओर से ऐसा रुख है कि <marquee> को हरा रंग फीका से परे है।

यह एक विशेष रूप से असिन कथन है।

1) हम-व्यापक-इंटरनेट उस निर्णय को लेने से एक दशक से अधिक दूर हैं
2) We-the-wasm-CG उस टैग के लोगों का एक पूरी तरह से (लगभग?) अलग समूह है, और संभवत: स्पष्ट पिछली गलतियों से भी व्यक्तिगत रूप से नाराज हैं।

हिप्स्टर लैंडिंग पृष्ठ और चमकदार लोगो के बिना, सभी व्यर्थ pontificating के बिना।

टोन मुद्दों में भागे बिना इसे "मैं निराश हूं" के लिए फिर से लिखा जा सकता था।

जैसा कि यह धागा दिखाता है, ये वार्तालाप काफी कठिन हैं जैसा कि यह है।

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

मुझे लगता है कि यह धागा उत्पादक होने से बहुत आगे बढ़ गया है - यह अब चार साल से अधिक समय से चल रहा है और ऐसा लगता है कि मनमाने ढंग से goto s के लिए और इसके खिलाफ हर संभव तर्क का उपयोग यहां किया गया है; यह भी ध्यान दिया जाना चाहिए कि इनमें से कोई भी तर्क विशेष रूप से नया नहीं है;)

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

वासम डिजाइन विकल्प जो मनमाने ढंग से कूदने से मना करते हैं, इसके दर्शन के मूल हैं। यह संभावना नहीं है कि यह goto s को फ़ंकलेट जैसी किसी चीज़ के बिना समर्थन कर सकता है, उन्हीं कारणों से यह शुद्ध अप्रत्यक्ष छलांग का समर्थन नहीं करता है।

वासम डिजाइन विकल्प जो मनमाने ढंग से कूदने से मना करते हैं, इसके दर्शन के मूल हैं। यह संभावना नहीं है कि यह फंकलेट जैसी किसी चीज़ के बिना गोटो का समर्थन कर सकता है, उन्हीं कारणों से यह शुद्ध अप्रत्यक्ष छलांग का समर्थन नहीं करता है।

@penzn फ़ंकलेट का प्रस्ताव क्यों अटका हुआ है? यह अक्टूबर 2018 से मौजूद है और अभी भी चरण 0 में है।

अगर हम एक रन-ऑफ-द-मिल ओपन-सोर्स प्रोजेक्ट पर चर्चा कर रहे थे, तो मैं इसके साथ कांटा और किया जाएगा। हम यहां एक दूरगामी एकाधिकार मानक की बात कर रहे हैं। जोरदार सामुदायिक प्रतिक्रिया विकसित की जानी चाहिए क्योंकि हम परवाह करते हैं।

@J0eCool

1. ध्यान दें कि उनमें से कितना musl libc में मौजूद है, सीधे emscripten में नहीं। (दूसरा सबसे अधिक उपयोग किया जाता है परीक्षण/थर्ड_पार्टी)

हां, सामान्य तौर पर सी में इसका कितना उपयोग किया गया था, इसकी मंजूरी थी।

1. स्रोत स्तर की संरचनाएं बाइटकोड निर्देशों के समान नहीं हैं

बेशक, हम जिस पर चर्चा कर रहे हैं वह एक आंतरिक चिंता है जो स्रोत स्तर की संरचना को प्रभावित करती है। यह निराशा का हिस्सा है, ब्लैक बॉक्स को अपनी चिंताओं को लीक नहीं करना चाहिए।

1. Emscripten, wasm मानक के समान अमूर्तता के स्तर पर नहीं है, इसलिए, नहीं, उस आधार पर इस पर पुनर्विचार नहीं किया जाना चाहिए।

मुद्दा यह था कि आप बड़े पैमाने पर WebAssembly टूलचैन के भीतर भी, बड़ी सी बड़ी परियोजनाओं में goto s पाएंगे। सामान्य रूप से भाषाओं के लिए एक पोर्टेबल कंपाइलर लक्ष्य जो अपने स्वयं के कंपाइलरों को लक्षित करने के लिए पर्याप्त अभिव्यंजक नहीं है, हमारे उद्यम की प्रकृति के बिल्कुल अनुरूप नहीं है।

विशेष रूप से, यह आज उपयोगी हो सकता है कि libc से गोटो को फिर से लिखा जाए, क्योंकि तब हमारे पास परिणामी cfg पर अधिक नियंत्रण होगा, जो इसे अच्छी तरह से संभालने के लिए relooper/cfgstackify पर भरोसा करने से अधिक होगा।

यह गोलाकार है। उपरोक्त कई लोगों ने ऐसी आवश्यकता की अचूकता के संबंध में गंभीर अनुत्तरित प्रश्न उठाए हैं।

हमने ऐसा नहीं किया है क्योंकि यह अपस्ट्रीम मसल से बेतहाशा भिन्न कोड के साथ काम करने की एक गैर-तुच्छ राशि है।

गोटो को हटाना संभव है, जैसा कि आपने कहा था, यह काम की गैर- तुच्छ

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

आशा की एक किरण! मुझे संतुष्टि होगी अगर गोटो/लेबल समर्थन को रोडमैप आइटम के साथ गंभीरता से लिया गया + गेंद को आगे बढ़ाने के लिए आधिकारिक निमंत्रण, भले ही साल बाहर हो।

यह एक विशेष रूप से असिन कथन है।

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

"क्या V8 का कोई प्रभारी इस सूत्र में पुष्टि कर सकता है कि इरेड्यूसेबल कंट्रोल फ्लो के खिलाफ विरोध V8 के वर्तमान कार्यान्वयन से प्रभावित नहीं है?

मैं पूछ रहा हूं क्योंकि यही मुझे सबसे ज्यादा परेशान करता है। [...]

अगर आप लोग किसी काम की बात सुनते हैं, तो Go 1.11 के बारे में @neelance की प्रतिक्रिया को दिल से लें। इससे बहस करना मुश्किल है। निश्चित रूप से, हम सभी गोटो की गैर-तुच्छ डस्टिंग कर सकते हैं, लेकिन फिर भी, हम एक गंभीर पूर्ण हिट लेते हैं जिसे केवल गोटो निर्देश के साथ तय किया जा सकता है।

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

यहाँ एक और वास्तविक दुनिया का मुद्दा है जो गुम गोटो/funclets के कारण होता है: https://github.com/golang/go/issues/42979

इस कार्यक्रम के लिए, गो कंपाइलर वर्तमान में 18,000 नेस्टेड block s के साथ एक wasm बाइनरी उत्पन्न करता है। wasm बाइनरी का आकार स्वयं 2.7MB है, लेकिन जब मैं इसे wasm2wat माध्यम से चलाता हूं तो मुझे 4.7GB .wat फ़ाइल मिलती है। मैं

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

मैं यह जोड़ना चाहता हूं कि मुझे यह अजीब लगता है कि लोग कैसे सोचते हैं कि यह बिल्कुल ठीक है अगर केवल एक कंपाइलर (एम्सस्क्रिप्टन [1]) वास्तव में WebAssembly का समर्थन कर सकता है।
मुझे कुछ हद तक लिबोपस स्थिति की याद दिलाता है (एक मानक जो मानक रूप से कॉपीराइट कोड पर निर्भर करता है)।

मुझे यह भी अजीब लगता है कि कैसे WebAssembly देव इसके खिलाफ इतने जोरदार प्रतीत होते हैं, इसके बावजूद चीजों के संकलक अंत से सभी के बारे में बताते हुए कि यह आवश्यक है। याद रखें: WebAssembly एक मानक है, घोषणापत्र नहीं। और तथ्य यह है कि, अधिकांश आधुनिक कंपाइलर आंतरिक रूप से एसएसए + मूल ब्लॉक के कुछ रूपों का उपयोग करते हैं (या लगभग समान गुणों के साथ कुछ समकक्ष), जिनमें स्पष्ट लूप की कोई अवधारणा नहीं है [2]। जेआईटी भी कुछ इसी तरह का उपयोग करते हैं, यह कितना आम है।
"जस्ट यूज़ गोटो" के बिना किसी एस्केप हैच के होने के लिए पूर्ण आवश्यकता, मेरी जानकारी के लिए [3], भाषा-से-भाषा अनुवादकों के बाहर अभूतपूर्व है --- और फिर भी, केवल भाषा-से-भाषा अनुवादक जो गोटो-लेस भाषाओं को लक्षित करें। विशेष रूप से, मैंने कभी नहीं सुना है कि यह WebAssembly के अलावा किसी भी प्रकार के IR या बाइटकोड के लिए किया जाना है।

शायद यह WebAssembly का नाम बदलकर WebEmscripten (WebScripten?) करने का समय है।

जैसा कि @ d4tocchini ने कहा था, अगर यह WebAssembly (आवश्यक, मानकीकरण की स्थिति के कारण) एकाधिकार स्थिति के लिए नहीं था, तो संभवतः इसे अब तक फोर्क किया गया होगा, जो कि संकलक डेवलपर्स को पहले से ही समर्थन करने के लिए आवश्यक रूप से समर्थन कर सकता है।
और नहीं, "बस एमस्क्रिप्टन का उपयोग करें" एक वैध प्रतिवाद नहीं है, क्योंकि यह मानक को एक एकल संकलक विक्रेता पर निर्भर करता है। मुझे आशा है कि मुझे आपको यह बताने की आवश्यकता नहीं है कि यह बुरा क्यों है।

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

यहां एक और वास्तविक दुनिया का मुद्दा है जो गुम गोटो/फंकलेट्स के कारण होता है: गोलंग/गो#42979

इस कार्यक्रम के लिए, गो कंपाइलर वर्तमान में 18,000 नेस्टेड block s के साथ एक wasm बाइनरी उत्पन्न करता है। wasm बाइनरी का आकार स्वयं 2.7MB है, लेकिन जब मैं इसे wasm2wat माध्यम से चलाता हूं तो मुझे 4.7GB .wat फ़ाइल मिलती है। मैं

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

यह उदाहरण वाकई दिलचस्प है। इतना सरल स्ट्रेट लाइन प्रोग्राम इस कोड को कैसे उत्पन्न करता है? सरणी तत्वों की संख्या और ब्लॉकों की संख्या के बीच क्या संबंध है? विशेष रूप से, क्या मुझे इसका अर्थ यह समझना चाहिए कि प्रत्येक सरणी तत्व पहुंच के लिए _multiple_ ब्लॉक को ईमानदारी से संकलित करने की आवश्यकता होती है?

और नहीं, "बस emscripten का उपयोग करें" एक वैध प्रतिवाद नहीं है

मुझे लगता है कि इस नस में वास्तविक प्रतिवाद यह होगा कि एक अन्य संकलक जो वासम को लक्षित करना चाहता है, वह अपने स्वयं के रिलोपर-जैसे एल्गोरिथ्म को लागू कर सकता है। व्यक्तिगत रूप से, मुझे लगता है कि वासम के पास अंततः एक मल्टी-बॉडी लूप (फ़ंकलेट्स के करीब) या ऐसा ही कुछ होना चाहिए जो goto लिए एक प्राकृतिक लक्ष्य हो।

@ कॉनराड-वाट ऐसे कई कारक हैं जो प्रत्येक असाइनमेंट को CFG में कई बुनियादी ब्लॉकों का उपयोग करने का कारण बनते हैं। उनमें से एक यह है कि स्लाइस पर लंबाई की जांच होती है क्योंकि संकलन समय पर लंबाई ज्ञात नहीं होती है। आम तौर पर मैं कहूंगा कि संकलक बुनियादी ब्लॉकों को अपेक्षाकृत सस्ते निर्माण के रूप में मानते हैं, लेकिन वासम के साथ वे कुछ हद तक महंगे हैं, खासकर इस विशेष मामले में।

@neelance संशोधित उदाहरण में जहां कोड कई कार्यों के बीच विभाजित है, (रनटाइम/संकलन) मेमोरी ओवरहेड बहुत कम दिखाया गया है। क्या इस मामले में कम ब्लॉक उत्पन्न होते हैं, या यह सिर्फ इतना है कि अलग-अलग कार्यों का मतलब है कि इंजन जीसी अधिक बारीक हो सकता है?

@ कॉनराड-वाट यह गो कोड भी नहीं है जो मेमोरी का उपयोग कर रहा है, लेकिन WebAssembly होस्ट: जब मैं क्रोम 86 के साथ वासम बाइनरी को इंस्टेंट करता हूं, तो मेरा सीपीयू 2 मिनट के लिए 100% हो जाता है और टैब का मेमोरी उपयोग चरम पर होता है 11.3 जीबी। इस से पहले Wasm द्विआधारी / गो कोड का निष्पादित है। यह wasm बाइनरी का आकार है जो समस्या पैदा कर रहा है।

यह तो मेरी समझ में पहले से ही थी। मैं विशेष रूप से संकलन/तत्काल के दौरान मेमोरी ओवरहेड का कारण बनने के लिए बड़ी संख्या में ब्लॉक/टाइप एनोटेशन की अपेक्षा करता हूं।

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

वैकल्पिक रूप से, यह हो सकता है कि विभाजित कोड का परिणाम (मोटे तौर पर) ब्लॉकों की कुल संख्या में होता है, लेकिन क्योंकि प्रत्येक फ़ंक्शन अलग से JIT संकलित होता है, प्रत्येक फ़ंक्शन को संकलित करने के लिए उपयोग किया जाने वाला मेटाडेटा/IR अधिक उत्सुकता से Wasm इंजन द्वारा GC'd हो सकता है . इसी तरह की समस्या V8 साल पहले हुई थी जब बड़े asm.js कार्यों को पार्स/संकलित किया गया था। इस मामले में, वासम के लिए अधिक सामान्य नियंत्रण प्रवाह शुरू करने से समस्या का समाधान नहीं होगा।

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

मुझे लगता है कि नेस्टेड block s की गहराई के संबंध में क्रोम के wasm रनटाइम में कुछ घातीय जटिलता वृद्धि हुई है। विभाजित संस्करण में समान संख्या में ब्लॉक हैं लेकिन एक छोटी अधिकतम गहराई है।

इस मामले में, वासम के लिए अधिक सामान्य नियंत्रण प्रवाह शुरू करने से समस्या का समाधान नहीं होगा।

मैं सहमत हूं कि इस जटिलता के मुद्दे को शायद क्रोम के अंत में हल किया जा सकता है। लेकिन मैं हमेशा यह सवाल पूछना पसंद करता हूं कि "यह मुद्दा पहली जगह में क्यों था?"। मैं तर्क दूंगा कि अधिक सामान्य नियंत्रण प्रवाह के साथ, यह मुद्दा कभी अस्तित्व में नहीं होता। इसके अलावा, सभी बुनियादी ब्लॉकों को जंप टेबल के रूप में व्यक्त किए जाने के कारण अभी भी महत्वपूर्ण सामान्य प्रदर्शन ओवरहेड है, जो मुझे लगता है कि अनुकूलन से दूर जाने की संभावना नहीं है।

मुझे लगता है कि नेस्टेड ब्लॉक की गहराई के संबंध में क्रोम के wasm रनटाइम में कुछ घातीय जटिलता वृद्धि हुई है। विभाजित संस्करण में समान संख्या में ब्लॉक हैं लेकिन एक छोटी अधिकतम गहराई है।

क्या इसका मतलब यह है कि एन ऐरे एक्सेस के साथ एक स्ट्रेट लाइन फंक्शन में, फाइनल ऐरे एक्सेस नेस्टेड (कुछ स्थिर कारक) एन ब्लॉक डीप होगा? यदि हां, तो क्या त्रुटि-प्रबंधन कोड को अलग-अलग करके इसे कम करने का कोई तरीका है? मैं किसी भी कंपाइलर को चुगने की उम्मीद करता हूं अगर उसे 3000 नेस्टेड लूप (बहुत मोटा सादृश्य) का विश्लेषण करना है, तो यदि यह अर्थपूर्ण कारणों से अपरिहार्य है, तो यह अधिक सामान्य नियंत्रण प्रवाह के लिए एक तर्क भी होगा।

यदि नेस्टिंग का अंतर उससे कम है, तो मेरा झुकाव यह होगा कि V8 मेटाडेटा की लगभग कोई GC'ing नहीं करता है _during_ एक एकल Wasm फ़ंक्शन का संकलन, इसलिए भले ही हमारे पास शुरू से ही भाषा में एक ट्वीक्ड फ़ंकलेट प्रस्ताव जैसा कुछ हो , वही ओवरहेड्स अभी भी उनके बिना कुछ दिलचस्प GC ऑप्टिमाइज़ेशन किए दिखाई देंगे।

इसके अलावा, सभी बुनियादी ब्लॉकों को जंप टेबल के रूप में व्यक्त किए जाने के कारण अभी भी महत्वपूर्ण सामान्य प्रदर्शन ओवरहेड है, जो मुझे लगता है कि अनुकूलन से दूर जाने की संभावना नहीं है।

सहमत हूं कि यहां अधिक प्राकृतिक लक्ष्य रखना स्पष्ट रूप से बेहतर है (विशुद्ध रूप से तकनीकी दृष्टिकोण से)।

क्या इसका मतलब यह है कि एन ऐरे एक्सेस के साथ एक स्ट्रेट लाइन फंक्शन में, फाइनल ऐरे एक्सेस नेस्टेड (कुछ स्थिर कारक) एन ब्लॉक डीप होगा? यदि हां, तो क्या त्रुटि-प्रबंधन कोड को अलग-अलग करके इसे कम करने का कोई तरीका है? मैं किसी भी कंपाइलर को चुगने की उम्मीद करता हूं अगर उसे 3000 नेस्टेड लूप (बहुत मोटा सादृश्य) का विश्लेषण करना है, तो यदि यह अर्थपूर्ण कारणों से अपरिहार्य है, तो यह अधिक सामान्य नियंत्रण प्रवाह के लिए एक तर्क भी होगा।

दूसरी तरफ: पहला असाइनमेंट गहराई से घोंसला है, आखिरी नहीं। नेस्टेड block s और शीर्ष पर एक एकल br_table यह है कि कैसे एक पारंपरिक switch स्टेटमेंट wasm में व्यक्त किया जाता है। यह जंप टेबल है जिसका मैंने उल्लेख किया है। कोई 3000 नेस्टेड लूप नहीं हैं।

यदि नेस्टिंग का अंतर उससे कम है, तो मेरा झुकाव यह होगा कि V8 एक एकल Wasm फ़ंक्शन के संकलन के दौरान मेटाडेटा की लगभग कोई GC'ing नहीं करता है, इसलिए भले ही हमारे पास शुरुआत से ही भाषा में एक ट्वीक किए गए funclets प्रस्ताव जैसा कुछ हो। , वही ओवरहेड्स अभी भी उनके बिना कुछ दिलचस्प GC ऑप्टिमाइज़ेशन किए दिखाई देंगे।

हां, कुछ कार्यान्वयन भी हो सकते हैं जिनमें बुनियादी ब्लॉकों की संख्या के संबंध में घातीय जटिलता है। लेकिन बुनियादी ब्लॉक (यहां तक ​​​​कि बड़ी मात्रा में) को संभालना बहुत सारे कंपाइलर पूरे दिन करते हैं। उदाहरण के लिए, गो कंपाइलर अपने संकलन के दौरान इस संख्या में बुनियादी ब्लॉकों को आसानी से संभाल लेता है, भले ही वे कई अनुकूलन पास द्वारा संसाधित हो जाते हैं।

हां, कुछ कार्यान्वयन भी हो सकते हैं जिनमें बुनियादी ब्लॉकों की संख्या के संबंध में घातीय जटिलता है। लेकिन बुनियादी ब्लॉक (यहां तक ​​​​कि बड़ी मात्रा में) को संभालना बहुत सारे कंपाइलर पूरे दिन करते हैं। उदाहरण के लिए, गो कंपाइलर अपने संकलन के दौरान इस संख्या में बुनियादी ब्लॉकों को आसानी से संभाल लेता है, भले ही वे कई अनुकूलन पास द्वारा संसाधित हो जाते हैं।

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

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

निश्चित रूप से, लेकिन यहां एक प्रदर्शन मुद्दा ऑर्थोगोनल होगा कि मूल स्रोत भाषा में उन मूल ब्लॉकों के बीच नियंत्रण प्रवाह कैसे व्यक्त किया जाता है।

तुम्हारी बात सही है।

मैं अब भी मानता हूं कि बुनियादी ब्लॉकों का प्रतिनिधित्व जंप निर्देशों के माध्यम से नहीं बल्कि जंप वेरिएबल और एक विशाल जंप टेबल/नेस्टेड ब्लॉकों के माध्यम से बुनियादी ब्लॉकों की सरल अवधारणा को काफी जटिल तरीके से व्यक्त करना है। इससे प्रदर्शन ओवरहेड होता है और जटिलता के मुद्दों का जोखिम होता है जैसे कि हमने यहां देखा था। मेरा मानना ​​है कि जटिल प्रणालियों की तुलना में सरल प्रणालियां बेहतर और अधिक मजबूत होती हैं। मैंने अभी भी ऐसे तर्क नहीं देखे हैं जो मुझे विश्वास दिलाते हैं कि सरल प्रणाली एक खराब विकल्प है। मैंने केवल यह सुना है कि V8 को मनमाने नियंत्रण प्रवाह को लागू करने में कठिन समय होगा और मेरा खुला प्रश्न मुझे यह बताने के लिए कि यह कथन गलत है (https://github.com/WebAssembly/design/issues/796#issuecomment-623431527) नहीं है अभी तक उत्तर दिया गया है।

@नीलांस

गहन प्रक्रिया समाप्त होने से पहले ही क्रोम कोड को चलाने में सक्षम है

ऐसा लगता है कि बेसलाइन कंपाइलर लिफ्टऑफ़ ठीक है, और समस्या ऑप्टिमाइज़िंग कंपाइलर TurboFan में है। कृपया कोई समस्या दर्ज करें, या कृपया एक टेस्टकेस प्रदान करें और यदि आप चाहें तो मैं एक फाइल कर सकता हूं।

अधिक आम तौर पर: क्या आपको लगता है कि wasm स्टैक स्विचिंग योजनाएँ गो के गोरोइन कार्यान्वयन के मुद्दों को हल करने में सक्षम होंगी? यह सबसे अच्छा लिंक है जो मुझे मिल सकता है, लेकिन यह अब काफी सक्रिय है, एक द्वि-साप्ताहिक बैठक के साथ, और कई मजबूत उपयोग के मामले जो काम को प्रेरित करते हैं। यदि गो बड़े स्विच पैटर्न से बचने के लिए wasm coroutines का उपयोग कर सकता है तो मुझे लगता है कि मनमाना गोटो आवश्यक नहीं होगा।

गो कंपाइलर रिलूपर एल्गोरिथम का उपयोग नहीं कर रहा है, क्योंकि यह स्वाभाविक रूप से स्विचिंग गोरोइन की अवधारणा के साथ असंगत है।

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

यदि आप रुचि रखते हैं, तो मुझे गो पर इसके साथ प्रयोग करने में बहुत खुशी होगी! यह स्पष्ट रूप से wasm में बिल्ट-इन स्टैक स्विचिंग सपोर्ट जितना अच्छा नहीं होगा, लेकिन यह पहले से ही बड़े स्विच पैटर्न से बेहतर हो सकता है। और बाद में बिल्ट-इन स्टैक स्विचिंग सपोर्ट पर स्विच करना आसान होगा। सीधे तौर पर, यह प्रयोग कैसे काम कर सकता है, यह है कि गो एमिट सामान्य रूप से संरचित कोड है, बिना स्टैक स्विचिंग की चिंता किए, और उचित बिंदुओं पर एक विशेष maybe_switch_goroutine फ़ंक्शन के लिए बस एक कॉल उत्सर्जित करें। Asyncify ट्रांसफ़ॉर्म मूल रूप से बाकी सभी का ध्यान रखेगा।

मुझे क्यूमू जैसे गतिशील पुन: संकलन अनुकरणकर्ताओं के लिए गोटो में दिलचस्पी है। अन्य कंपाइलरों के विपरीत, क्यूमू को किसी भी समय प्रोग्राम कंट्रोल फ्लो स्ट्रक्चर का ज्ञान नहीं होता है, और इसलिए गोटो ही एकमात्र उचित लक्ष्य है। प्रत्येक ब्लॉक को एक फ़ंक्शन के रूप में और प्रत्येक गोटो को टेलकॉल के रूप में संकलित करके, टेलकॉल इसे संबोधित कर सकते हैं।

@kripken आपकी बहुत उपयोगी पोस्ट के लिए धन्यवाद।

ऐसा लगता है कि बेसलाइन कंपाइलर लिफ्टऑफ़ ठीक है, और समस्या ऑप्टिमाइज़िंग कंपाइलर TurboFan में है। कृपया कोई समस्या दर्ज करें, या कृपया एक टेस्टकेस प्रदान करें और यदि आप चाहें तो मैं एक फाइल कर सकता हूं।

यहाँ एक wasm बाइनरी है जिसे आप wasm_exec.html के साथ चला सकते हैं।

क्या आपको लगता है कि wasm स्टैक स्विचिंग योजनाएँ गो के गोरोइन कार्यान्वयन के मुद्दों को हल करने में सक्षम होंगी?

हां, पहली नज़र में ऐसा लगता है कि इससे मदद मिलेगी।

हालाँकि, हमारे पास wasm संरचित नियंत्रण प्रवाह + Asyncify का उपयोग करने के अच्छे परिणाम हैं।

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

मेरा मानना ​​है कि यदि आप इसे लागू करना चाहते हैं तो एलएलवीएम का स्टैकिफायर एल्गोरिदम आसान/बेहतर है: https://medium.com/leaningtech/solving-the-structured-control-flow-problem-once-and-for-all-5123117b1ee2

मैंने गो परियोजना के लिए एक प्रस्ताव दायर किया है: https://github.com/golang/go/issues/43033

@neelance , @kripken के सुझाव को देखकर अच्छा लगा , गोलंग + wasm के साथ थोड़ी मदद करता है। इस मुद्दे को ध्यान में रखते हुए गोटो/लेबल में से एक है जो स्टैक स्विचिंग नहीं है, और यह देखते हुए कि Asyncify स्टैक स्विचिंग जारी होने तक Asyncify के साथ नए डीपीएस/विशेष आवरण बनाता है, आदि - क्या आप इसे समाधान के रूप में या इष्टतम शमन से कम के रूप में चिह्नित करेंगे? यदि गोटो निर्देश उपलब्ध थे तो यह अनुमानित लाभों की तुलना कैसे करता है?

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

अगर मैं गलत पढ़ रहा हूं तो कृपया मुझे सुधारें, लेकिन उठाए गए कुछ सवालों के लिए मामूली विशिष्टताओं पर ध्यान केंद्रित करने वाली प्रतिक्रियाओं के अलावा, ऐसा प्रतीत होता है कि यहां रखरखाव करने वालों ने इस मामले पर कोई स्पष्टता नहीं दी है और न ही कठिन प्रश्नों का उत्तर दिया है। पूरे सम्मान के साथ, क्या यह सुस्त ossification कैलस कॉरपोरेट पॉलिटिक्स की पहचान नहीं है? अगर ऐसा है, तो मैं दुर्दशा को समझता हूं... उन सभी भाषाओं/संकलकों की कल्पना करें, जिन्हें वासम का ब्रांड समर्थन का दावा कर सकता है यदि केवल एएनएसआई सी एक कंपैट लिटमस टेस्ट होता!

@neelance @darkuranium @d4tocchini सभी Wasm योगदानकर्ताओं को नहीं लगता कि गोटो की कमी सही बात है, वास्तव में, मैं व्यक्तिगत रूप से इसे Wasm की # 1 डिज़ाइन गलती के रूप में रेट करूंगा। मैं इसे जोड़ने के बिल्कुल पक्ष में हूं (या तो फंकलेट के रूप में या सीधे)।

हालाँकि, इस सूत्र पर बहस करने से गोटो नहीं होने वाला है, और जादुई रूप से वासम में शामिल सभी लोगों को आश्वस्त करने और आपके लिए काम करने के लिए नहीं जा रहा है। यहाँ कदम उठाने हैं:

1. वासम सीजी में शामिल हों।
2. कोई व्यक्ति गोटो प्रस्ताव का चैंपियन बनने के लिए समय लगाता है। मैं मौजूदा funclets प्रस्ताव से शुरू करने की सलाह देता हूं, क्योंकि यह पहले से ही @sunfishcode द्वारा वर्तमान इंजनों और उपकरणों के लिए "कम से कम घुसपैठ" के रूप में अच्छी तरह से सोचा गया है जो ब्लॉक संरचना पर भरोसा करते हैं, इसलिए इसमें कच्चे की तुलना में सफल होने का एक उच्च मौका है। के लिए जाओ।
3. 4 प्रस्ताव चरणों के माध्यम से इसे आगे बढ़ाने में सहायता करें। इसमें आपके रास्ते में आने वाली किसी भी आपत्ति के लिए अच्छे डिजाइन बनाना, चर्चा शुरू करना, इस उद्देश्य से पर्याप्त लोगों को खुश करना शामिल है कि चरणों के माध्यम से आगे बढ़ने पर आपको बहुमत के वोट मिलते हैं।

@ d4tocchini ईमानदारी से, मैं वर्तमान में सुझाए गए समाधानों को "दिए गए परिस्थितियों को आगे बढ़ाने का सबसे अच्छा तरीका है जिसे मैं बदल नहीं सकता" उर्फ ​​​​"वर्कअराउंड" के रूप में देखता हूं। मैं अभी भी जंप/गोटो निर्देश (या funclets) को सरल तरीका मानता हूं और इस प्रकार बेहतर है। (फिर भी विकल्पों का सुझाव देने में मदद करने के लिए

@aardappel जहां तक ​​​​मुझे पता है, @sunfishcode ने funclets प्रस्ताव को आगे बढ़ाने की कोशिश की और असफल रहा। यह मेरे लिए अलग क्यों होगा?

@neelance मुझे नहीं लगता कि @sunfishcode के पास अपने प्रारंभिक निर्माण से परे प्रस्ताव को आगे बढ़ाने के लिए अधिक समय है, इसलिए यह "विफल" के बजाय "रुका हुआ" है। जैसा कि मैं इंगित करने की कोशिश कर रहा था, पाइपलाइन के माध्यम से सभी तरह से प्राप्त करने के प्रस्ताव के लिए निरंतर काम करने के लिए एक चैंपियन की आवश्यकता है।

@नीलांस

टेस्टकेस के लिए धन्यवाद! मैं स्थानीय रूप से उसी समस्या की पुष्टि कर सकता हूं। मैंने https://bugs.chromium.org/p/v8/issues/detail?id=11237 . दायर किया

हमें गो [..] में रिलूपर को लागू करने की आवश्यकता होगी।

बीटीडब्ल्यू, अगर यह मदद करेगा, तो हम एक सी फाइल के रूप में बाइनरीन का पुस्तकालय निर्माण कर सकते हैं। शायद यह एकीकृत करना आसान है?

इसके अलावा, बाइनरीएन का उपयोग करके आप वहां मौजूद रिलोपर कार्यान्वयन का उपयोग कर सकते हैं। आप इसे IR के बेसिक ब्लॉक्स पास कर सकते हैं और इसे फिर से लूपिंग करने दे सकते हैं।

@taralx

मेरा मानना ​​​​है कि एलएलवीएम का स्टैकिफायर एल्गोरिदम आसान/बेहतर है,

ध्यान दें कि वह लिंक अपस्ट्रीम LLVM के बारे में नहीं है, वह Cheerp कंपाइलर है (जो LLVM का एक कांटा है)। उनके स्टैकिफायर का नाम एलएलवीएम के समान है, लेकिन यह अलग है।

यह भी ध्यान दें कि चेरप पोस्ट 2011 से मूल एल्गोरिदम को संदर्भित करता है - आधुनिक रिलोपर कार्यान्वयन (जैसा कि पहले उल्लेख किया गया है) में कई वर्षों से वे समस्याएं नहीं हैं जिनका उन्होंने उल्लेख किया है। मुझे उस सामान्य दृष्टिकोण के लिए एक सरल या बेहतर विकल्प के बारे में पता नहीं है, जो कि चेरप और अन्य लोगों के समान ही है - ये एक विषय पर भिन्नताएं हैं।

@kripken मुद्दा दर्ज करने के लिए धन्यवाद।

बीटीडब्ल्यू, अगर यह मदद करेगा, तो हम एक सी फाइल के रूप में बाइनरीन का पुस्तकालय निर्माण कर सकते हैं। शायद यह एकीकृत करना आसान है?

संभावना नहीं है। गो कंपाइलर को कुछ समय पहले शुद्ध गो में बदल दिया गया है और यह किसी अन्य सी निर्भरता का उपयोग नहीं करता है। मुझे नहीं लगता कि यह कोई अपवाद होगा।

यहाँ फ़ंकलेट प्रस्ताव की वर्तमान स्थिति है: प्रक्रिया का अगला चरण चरण 1 में प्रवेश करने के लिए सीजी वोट के लिए कॉल करना है।

मैं स्वयं वर्तमान में WebAssembly के अन्य क्षेत्रों पर ध्यान केंद्रित कर रहा हूं और मेरे पास फ़ंकलेट्स को आगे बढ़ाने के लिए बैंडविड्थ नहीं है; अगर कोई फ़ंकलेट्स के लिए चैंपियन की भूमिका निभाने में दिलचस्पी रखता है, तो मुझे इसे सौंपने में खुशी होगी।

संभावना नहीं है। गो कंपाइलर को कुछ समय पहले शुद्ध गो में बदल दिया गया है और यह किसी अन्य सी निर्भरता का उपयोग नहीं करता है। मुझे नहीं लगता कि यह कोई अपवाद होगा।

इसके अलावा, यह रिलोपर के व्यापक उपयोग की समस्या को हल नहीं करता है, जिससे WebAssembly रनटाइम में गंभीर प्रदर्शन में बाधा आती है।

@ वुरिख

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

@kripken क्या आपके पास कोई सुझाव है कि कोई इस तरह के डेटा को कैसे एकत्र कर सकता है? कोई कैसे दिखाएगा कि संरचित नियंत्रण प्रवाह के कारण एक पूर्ण घाटा है?

यह संभावना नहीं है कि संकलन चरण के प्रदर्शन का विश्लेषण करने के लिए बहुत काम है, जो यहां शिकायत का हिस्सा है।

मैं कुछ हद तक हैरान हूं कि हमारे पास अभी तक एक स्विच केस का निर्माण नहीं हुआ है, लेकिन फंकलेट्स इसमें शामिल हैं।

@नीलांस

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

एक विकल्प हाथ से उत्सर्जित मशीन कोड की तुलना करना है, जो उन्होंने उस लिंक किए गए पेपर में किया था।

एक अन्य विकल्प यह है कि वासम को किसी ऐसी चीज के लिए संकलित किया जाए जो आपको लगता है कि नियंत्रण प्रवाह को बेहतर तरीके से संभाल सकता है, अर्थात संरचना को "पूर्ववत करें"। एलएलवीएम ऐसा करने में सक्षम होना चाहिए, इसलिए एलएलवीएम (जैसे डब्ल्यूएवीएम या वासमर) का उपयोग करने वाले वीएम में या वासमबॉक्ससी के माध्यम से वासम चलाना दिलचस्प हो सकता है। आप शायद एलएलवीएम में सीएफजी अनुकूलन अक्षम कर सकते हैं और देख सकते हैं कि यह कितना मायने रखता है।

@taralx

दिलचस्प है, क्या मुझे संकलन समय या स्मृति उपयोग के बारे में कुछ याद आया? संरचित नियंत्रण प्रवाह वास्तव में वहां बेहतर होना चाहिए - उदाहरण के लिए सामान्य सीएफजी की तुलना में एसएसए फॉर्म में जाना बहुत आसान है। यह वास्तव में उन कारणों में से एक था जो पहले स्थान पर संरचित नियंत्रण प्रवाह के साथ गए थे। इसे भी बहुत सावधानी से मापा जाता है क्योंकि यह वेब पर लोड समय को प्रभावित करता है।

(या आपका मतलब डेवलपर की मशीन पर कंपाइलर प्रदर्शन है? यह सच है कि wasm वहां अधिक काम करने की दिशा में झुकता है, और क्लाइंट पर कम।)

मेरा मतलब एम्बेडर में प्रदर्शन को संकलित करना था, लेकिन ऐसा लगता है कि इसे एक बग के रूप में माना जा रहा है, जरूरी नहीं कि यह एक शुद्ध पूर्ण मुद्दा हो?

@taralx

हाँ, मुझे लगता है कि यह एक बग है। यह सिर्फ एक वीएम पर एक टीयर में होता है। और इसका कोई मौलिक कारण नहीं है - संरचित नियंत्रण प्रवाह के लिए अधिक संसाधनों की आवश्यकता नहीं होती है, इसके लिए कम की आवश्यकता होती है। यही है, मैं शर्त लगाता हूं कि इस तरह के पूर्ण बग होने की संभावना अधिक होगी यदि wasm में गोटो होता है।

@क्रिपकेन

संरचित नियंत्रण प्रवाह वास्तव में वहां बेहतर होना चाहिए - उदाहरण के लिए सामान्य सीएफजी की तुलना में एसएसए फॉर्म में जाना बहुत आसान है। यह वास्तव में उन कारणों में से एक था जो पहले स्थान पर संरचित नियंत्रण प्रवाह के साथ गए थे। इसे भी बहुत सावधानी से मापा जाता है क्योंकि यह वेब पर लोड समय को प्रभावित करता है।

एक बहुत ही विशिष्ट प्रश्न, बस के मामले में: क्या आप किसी वासम कंपाइलर के बारे में जानते हैं जो वास्तव में ऐसा करता है - "बहुत सरल" "संरचित नियंत्रण प्रवाह" से एसएसए फॉर्म में जा रहा है। क्योंकि एक त्वरित नज़र से, Wasm का नियंत्रण प्रवाह (पूरी तरह से/अंततः) संरचित नहीं है। औपचारिक रूप से संरचित नियंत्रण वह है जहां कोई break s, continue s, return s (मोटे तौर पर, योजना का प्रोग्रामिंग का मॉडल, कॉल/सीसी जैसे जादू के बिना) नहीं है। जब वे मौजूद होते हैं, तो ऐसे नियंत्रण प्रवाह को मोटे तौर पर "अर्ध-संरचित" कहा जा सकता है।

पूरी तरह से संरचित नियंत्रण प्रवाह के लिए एक प्रसिद्ध एसएसए एल्गो है: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503 । अर्ध-संरचित नियंत्रण प्रवाह के बारे में इसका क्या कहना है:

संरचित बयानों के लिए हमने दिखाया है कि पार्सिंग के दौरान एक ही पास में एसएसए फॉर्म और डोमिनेटर ट्री दोनों कैसे उत्पन्न होते हैं। निम्नलिखित खंड में हम दिखाएंगे कि हमारी पद्धति को असंरचित बयानों (लूप/एक्जिट और रिटर्न) के एक निश्चित वर्ग तक विस्तारित करना संभव है जो मनमाने बिंदुओं पर नियंत्रण संरचनाओं से बाहर निकलने का कारण बन सकता है। हालांकि, चूंकि इस तरह के निकास एक प्रकार (अनुशासित) गोटो हैं, इसलिए यह आश्चर्यजनक नहीं है कि संरचित बयानों की तुलना में उन्हें संभालना अधिक कठिन होता है।

OTOH, एक और प्रसिद्ध एल्गोरिथम है, https://pp.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf जो यकीनन सिंगल-पास भी है, लेकिन इसमें न केवल गैर-संरचित नियंत्रण के साथ समस्याएं हैं प्रवाह, लेकिन इरेड्यूसबल नियंत्रण प्रवाह के साथ भी (यद्यपि इसके लिए इष्टतम परिणाम नहीं देता है)।

तो, सवाल फिर से है कि क्या आप जानते हैं कि कुछ प्रोजेक्ट वास्तव में ब्रैंडिस/मोसेनबॉक एल्गोरिदम को विस्तारित करने की परेशानी के माध्यम से चला गया, और ब्रौन एट अल की तुलना में उस मार्ग पर ठोस लाभ प्राप्त किया। एल्गोरिथम (एक साइड नोट के रूप में, मेरा सहज ज्ञान युक्त झुकाव यह है कि ब्रौन एल्गो बिल्कुल "ऊपरी बाउंड" एक्सटेंशन है, हालांकि मैं औपचारिक सबूत के बारे में बात नहीं कर रहा हूं, यह खुद को सहज रूप से साबित करने के लिए बहुत गूंगा हूं, इसलिए यह है - सहज ज्ञान युक्त झुकाव )

और प्रश्न का सामान्य विषय स्थापित करना है (हालांकि मैं "रखरखाव" कहूंगा) वासम ने मनमानी गोटो समर्थन से बाहर निकलने का अंतिम कारण क्यों चुना। साल के लिए इस धागे देख वजह से, मानसिक मॉडल मैं बनाया है कि यह अलघुकरणीय CFGs सामना करना पड़ रहा से बचने के लिए किया है है। और वास्तव में, कई अनुकूलन एल्गोरिथम जा रहा है (बहुत) कम करने योग्य CFGs के लिए आसान के साथ कम करने योग्य और अलघुकरणीय CFGs के बीच खाई झूठ,, और कहा कि क्या कई optimizers में कोडित है। (सेमी) Wasm में संरचित नियंत्रण प्रवाह गारंटी करने के लिए सिर्फ एक सस्ता तरीका है न्यूनीकरणीयता

संरचित CFG के लिए SSA उत्पादन की किसी विशेष सुगमता का उल्लेख करना (और Wasm CFGs वास्तव में औपचारिक अर्थों में संरचित नहीं लगता है) किसी तरह ऊपर की स्पष्ट तस्वीर को बादल देता है। इसलिए मैं पूछ रहा हूं कि क्या ऐसे विशिष्ट संदर्भ हैं कि एसएसए निर्माण व्यावहारिक रूप से वास्म सीएफजी फॉर्म से लाभान्वित होता है।

धन्यवाद।

@kripken मैं अभी थोड़ा भ्रमित हूं और सीखने के लिए उत्सुक हूं। मैं स्थिति को देख रहा हूँ और मैं वर्तमान में निम्नलिखित देख रहा हूँ:

आपके प्रोग्राम के स्रोत का एक निश्चित नियंत्रण प्रवाह होता है। यह CFG या तो रिड्यूसिबल है या नहीं है, उदाहरण के लिए गोटो का इस्तेमाल सोर्स लैंग्वेज में किया गया है या नहीं। इस तथ्य को बदलने का कोई तरीका नहीं है। इस सीएफजी को मशीन कोड में बदला जा सकता है, उदाहरण के लिए गो कंपाइलर मूल रूप से करता है।

यदि CFG पहले से ही कम करने योग्य है, तो सब ठीक है और wasm VM इसे जल्दी से लोड कर सकता है। कोई भी अनुवाद पास यह पता लगाने में सक्षम होना चाहिए कि यह एक साधारण मामला है और त्वरित कार्य करें। इरेड्यूसेबल सीएफजी को अनुमति देने से इस मामले में कमी नहीं आनी चाहिए।

यदि CFG कम करने योग्य नहीं है, तो दो विकल्प हैं:

• कंपाइलर इसे कम करने योग्य बनाता है, उदाहरण के लिए एक जंप टेबल पेश करके। यह कदम जानकारी खो देता है। बाइनरी का उत्पादन करने वाले कंपाइलर के लिए विशिष्ट विश्लेषण किए बिना मूल CFG को पुनर्स्थापित करना कठिन है। जानकारी के इस नुकसान के कारण, उत्पन्न कोई भी मशीन कोड प्रारंभिक CFG से उत्पन्न कोड की तुलना में कुछ धीमा होगा। हम इस मशीन कोड को सिंगल पास एल्गोरिथम के साथ उत्पन्न करने में सक्षम हो सकते हैं, लेकिन यह सूचना हानि की कीमत पर है। [1]

• हम कंपाइलर को एक इरेड्यूसेबल CFG उत्सर्जित करने की अनुमति देते हैं। VM को इसे कम करने योग्य बनाना पड़ सकता है। यह लोड समय को धीमा कर देता है, लेकिन केवल उन मामलों में जहां सीएफजी वास्तव में कम करने योग्य नहीं है। कंपाइलर के पास लोड टाइम परफॉर्मेंस या रन टाइम परफॉर्मेंस के लिए ऑप्टिमाइज़ करने का विकल्प होता है।

[1] मुझे पता है कि यह वास्तव में जानकारी का नुकसान नहीं है अगर ऑपरेशन को उलटने का कोई तरीका है, लेकिन मैं इसका बेहतर तरीके से वर्णन नहीं कर सका।

मेरी सोच में दोष कहाँ है?

@pfalcon

क्या आप किसी वासम कंपाइलर के बारे में जानते हैं जो वास्तव में ऐसा करता है - "बहुत सरल" "संरचित नियंत्रण प्रवाह" से एसएसए फॉर्म में जा रहा है।

VMs के बारे में: मैं सीधे नहीं जानता। लेकिन IIRC ने उस दिन @titzer और @lukewagner ने कहा कि इस तरह से लागू करना सुविधाजनक था - शायद उनमें से एक विस्तृत कर सकता है। मुझे यकीन नहीं है कि इरेड्यूसिबिलिटी वहां पूरा मुद्दा था या नहीं। और मुझे यकीन नहीं है कि उन्होंने उन एल्गोरिदम को लागू किया है जिनका आप उल्लेख करते हैं या नहीं।

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

@नीलांस

यदि CFG पहले से ही कम करने योग्य है, तो सब ठीक है और wasm VM इसे जल्दी से लोड कर सकता है। कोई भी अनुवाद पास यह पता लगाने में सक्षम होना चाहिए कि यह एक साधारण मामला है और त्वरित कार्य करें। इरेड्यूसेबल सीएफजी को अनुमति देने से इस मामले में कमी नहीं आनी चाहिए।

शायद मैं आपको पूरी तरह समझ नहीं पा रहा हूं। लेकिन यह कि एक wasm VM कोड को जल्दी से लोड कर सकता है, यह न केवल इस बात पर निर्भर करता है कि यह कम करने योग्य है या नहीं, बल्कि यह कैसे एन्कोड किया गया है। विशेष रूप से, हम एक प्रारूप की कल्पना कर सकते थे जो एक सामान्य सीएफजी है, और फिर वीएम को यह सत्यापित करने के लिए काम करने की ज़रूरत है कि यह कम करने योग्य है। Wasm ने उस काम से बचने का विकल्प चुना - एन्कोडिंग आवश्यक रूप से कम करने योग्य है (अर्थात, जैसा कि आप wasm पढ़ते हैं और तुच्छ सत्यापन करते हैं, आप यह भी साबित कर रहे हैं कि यह बिना कोई अतिरिक्त काम किए कम करने योग्य है)।

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

कुल मिलाकर मुझे लगता है कि इरेड्यूसेबल सीएफजी की अनुमति देने से तेजी से मामला धीमा हो सकता है, जब तक कि इरेड्यूसिबल वाले को एक अलग तरीके से एन्कोड नहीं किया जाता है (जैसे कि फंकलेट्स का प्रस्ताव है)।

@क्रिपकेन

आपके विवरण के लिये धन्यवाद।

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

निष्कर्ष के रूप में मैं नहीं देखता कि कोई कैसे तर्क दे सकता है कि पूरी तरह से कमजोर नोटेशन तेज है। एक कम करने योग्य स्रोत CFG के मामले में यह उतना ही तेज़ है। और मामले में अगर एक अपरिवर्तनीय स्रोत सीएफजी कोई अधिक से अधिक तर्क दे सकता है कि यह काफी धीमा नहीं है, लेकिन कुछ वास्तविक दुनिया के मामलों ने पहले ही दिखाया है कि यह सामान्य रूप से मामला नहीं है।

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

@नीलांस

हां, मैं सहमत हूं कि हम एक नया निर्माण जोड़ सकते हैं - जैसे फंकलेट - और इसका उपयोग न करने से, यह मौजूदा मामले को धीमा नहीं करेगा।

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

कुछ wasm प्रस्ताव केवल गति के बारे में नहीं हैं, जैसे GC (जो JS के साथ साइकिल संग्रह की अनुमति देता है)। लेकिन गति के बारे में प्रस्तावों के लिए, फ़ंकलेट्स की तरह, हमें यह दिखाने की ज़रूरत है कि गति जटिलता को सही ठहराती है। हमने SIMD के बारे में यह बहस की थी जो गति के बारे में भी है, और यह तय किया कि यह इसके लायक था क्योंकि हमने देखा कि यह वास्तविक दुनिया कोड (2x या उससे भी अधिक) पर बहुत बड़े स्पीडअप को मज़बूती से प्राप्त कर सकता है।

(सामान्य CFG को अनुमति देने के लिए गति के अलावा अन्य लाभ हैं, मैं सहमत हूँ, जैसे कि कंपाइलरों के लिए wasm को लक्षित करना आसान बनाना। लेकिन हम wasm VMs में जटिलता को जोड़े बिना इसे हल कर सकते हैं। हम पहले से ही LLVM और Binaryen में मनमाने CFG के लिए समर्थन प्रदान करते हैं। , कंपाइलर्स को CFGs उत्सर्जित करने की अनुमति देता है और संरचित नियंत्रण प्रवाह के बारे में चिंता नहीं करता है। यदि यह काफी अच्छा नहीं है, तो हम - उपकरण लोगों का मतलब है, मेरे सहित - और अधिक करना चाहिए।)

Funclet की गति के बारे में उतना नहीं है जितना वे गैर-तुच्छ नियंत्रण प्रवाह वाली भाषाओं को WebAssembly में संकलित करने की अनुमति देने के बारे में हैं, सी और गो सबसे स्पष्ट हैं लेकिन यह किसी भी भाषा पर लागू होता है जिसमें एसिंक/प्रतीक्षा होती है। साथ ही, पदानुक्रमित नियंत्रण प्रवाह रखने का विकल्प वास्तव में VMs में _more_ बग की ओर जाता है, जैसा कि इस तथ्य से प्रमाणित है कि V8 के अलावा सभी Wasm कंपाइलर किसी भी तरह CFG में पदानुक्रमित नियंत्रण प्रवाह को विघटित करते हैं। CFG में EBB, Wasm और अधिक में कई नियंत्रण प्रवाह निर्माणों का प्रतिनिधित्व कर सकते हैं, और संकलन के लिए एक ही निर्माण होने से विभिन्न उपयोगों के साथ कई अलग-अलग प्रकार के होने की तुलना में बहुत कम बग होते हैं।

यहां तक ​​​​कि लाइटबीम, एक बहुत ही सरल, स्ट्रीमिंग कंपाइलर, ने एक अतिरिक्त अनुवाद चरण जोड़ने के बाद गलत संकलन बग में भारी कमी देखी, जिसने नियंत्रण प्रवाह को सीएफजी में विघटित कर दिया। यह इस प्रक्रिया के दूसरे पक्ष के लिए दोगुना हो जाता है - Relooper फंकलेट उत्सर्जित करने की तुलना में कहीं अधिक त्रुटि-प्रवण है, और मुझे LLVM के लिए Wasm बैकएंड पर काम करने वाले डेवलपर्स और अन्य कंपाइलरों द्वारा कहा गया है जो कार्यान्वित किए जाने वाले funclets थे, वे प्रत्येक को उत्सर्जित करेंगे कोडजेन की विश्वसनीयता और सरलता में सुधार करने के लिए अकेले फंकलेट्स का उपयोग करके कार्य करता है। Wasm का उत्पादन करने वाले सभी कंपाइलर EBB का उपयोग करते हैं, Wasm का उपयोग करने वाले सभी कंपाइलरों में से एक EBB का उपयोग करता है, यह फ़ंकलेट या CFG का प्रतिनिधित्व करने के किसी अन्य तरीके को लागू करने से इनकार करता है, बस बीच में एक हानिकारक कदम जोड़ रहा है जो V8 टीम के अलावा अन्य सभी पक्षों को नुकसान पहुंचाता है। .

"अपरिवर्तनीय नियंत्रण प्रवाह हानिकारक माना जाता है" केवल एक बात करने वाला बिंदु है, आप आसानी से प्रतिबंध जोड़ सकते हैं कि funclets का नियंत्रण प्रवाह कम हो सकता है और फिर यदि आप भविष्य में अपरिवर्तनीय नियंत्रण प्रवाह की अनुमति देना चाहते हैं तो कमजोर नियंत्रण प्रवाह वाले सभी मौजूदा वासम मॉड्यूल अपरिवर्तित काम करेंगे एक इंजन पर जो अतिरिक्त रूप से इरेड्यूसेबल नियंत्रण प्रवाह का समर्थन करता है। यह केवल वैलिडेटर में रिड्यूसिबिलिटी चेक को हटाने का मामला होगा।

@ वुरिख

आप आसानी से प्रतिबंध जोड़ सकते हैं कि फंकलेट्स का नियंत्रण प्रवाह कम हो सकता है

आप कर सकते हैं, लेकिन यह मामूली नहीं है - वीएम को इसे सत्यापित करने की आवश्यकता होगी। मुझे नहीं लगता कि यह एक रैखिक पास में संभव है, जो बेसलाइन कंपाइलर्स के लिए एक समस्या होगी, जो अब अधिकांश वीएम में मौजूद हैं। (वास्तव में, केवल लूप बैकेज ढूंढना - जो एक आसान समस्या है, और अन्य कारणों से भी जरूरी है - एक फॉरवर्ड पास में नहीं किया जा सकता है, है ना?)

V8 के अलावा सभी Wasm कंपाइलर वैसे भी CFG में पदानुक्रमित नियंत्रण प्रवाह को विघटित करते हैं।

क्या आप TurboFan द्वारा उपयोग किए जाने वाले "सी ऑफ नोड्स" दृष्टिकोण की बात कर रहे हैं? मैं उस पर विशेषज्ञ नहीं हूं इसलिए मैं इसे दूसरों को जवाब देने के लिए छोड़ दूंगा।

लेकिन अधिक आम तौर पर, भले ही आप कंपाइलर्स को अनुकूलित करने के लिए उपरोक्त तर्क नहीं खरीदते हैं, यह बेसलाइन कंपाइलर्स के लिए और भी अधिक सच है, जैसा कि पहले उल्लेख किया गया है।

फ़ंकलेट की गति के बारे में उतना नहीं है जितना वे गैर-तुच्छ नियंत्रण प्रवाह वाली भाषाओं को WebAssembly [..] को संकलित करने की अनुमति देने के बारे में हैं

मैं टूल साइड पर 100% सहमत हूं। अधिकांश कंपाइलरों से संरचित कोड उत्सर्जित करना कठिन है! लेकिन मुद्दा यह है कि यह वीएम पक्ष पर इसे आसान बनाता है, और यही वह है जिसे करने के लिए चुना गया था। लेकिन फिर से, मैं मानता हूं कि इसमें आपके द्वारा उल्लिखित डाउनसाइड्स सहित ट्रेडऑफ़ हैं।

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

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

• मैं बाइनरी सीएफजी कोड को गो में पोर्ट करने पर विचार कर सकता हूं, अगर इससे गो कंपाइलर - @neelance को मदद मिलेगी?
• हम फ़ंकलेट या उनके जैसे कुछ को विशुद्ध रूप से टूल साइड पर लागू कर सकते हैं। अर्थात्, हम आज इसके लिए पुस्तकालय कोड प्रदान करते हैं, लेकिन एक बाइनरी प्रारूप भी जोड़ सकते हैं। (wasm ऑब्जेक्ट फाइलों में, टूल साइड पर wasm बाइनरी फॉर्मेट में जोड़ने के लिए पहले से ही मिसाल है।)

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

यदि इस पर कोई ठोस कार्य किया गया है, तो यह ध्यान देने योग्य है कि (AFAIU) इसे वासम में जोड़ने का सबसे छोटा मुहावरेदार तरीका है (जैसा कि @rossberg ने संकेत दिया है ) ब्लॉक निर्देश को पेश करना होगा

मल्टीलूप (t <sub>in</sub> ) <sup>_n_</sup> t <sub>out</sub> (_instr_* end ) <sup>_n_</sup>

जो n लेबल वाले निकायों को परिभाषित करता है (n इनपुट प्रकार एनोटेशन के साथ अग्रेषित घोषित)। निर्देशों के br परिवार को तब सामान्यीकृत किया जाता है ताकि मल्टीलूप द्वारा परिभाषित सभी लेबल प्रत्येक निकाय के भीतर इन-स्कोप हों, क्रम में (जैसा कि, किसी भी निकाय को किसी अन्य निकाय के भीतर से मल्टीलूप बॉडी को

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

यह फ़ंकलेट्स के समान अभिव्यक्ति का स्तर प्राप्त करता है लेकिन नियंत्रण निर्देशों के एक नए स्थान को पेश करने से बचता है। वास्तव में अगर फंकलेट्स को और आगे बढ़ाया गया होता तो मुझे लगता है कि यह कुछ इस तरह से बदल गया होता।

संपादित करें: फॉल-थ्रू व्यवहार के लिए इसे ट्वीव करना औपचारिक अर्थशास्त्र को मामूली रूप से जटिल करेगा, लेकिन शायद

इंजनों को सरल/तेज़ बनाने के लिए उपकरणों पर ऑफ़लोडिंग कार्य का वासम डिज़ाइन सिद्धांत बहुत महत्वपूर्ण है, और यह बहुत फायदेमंद रहेगा।

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

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

आप कर सकते हैं, लेकिन यह मामूली नहीं है - वीएम को इसे सत्यापित करने की आवश्यकता होगी। मुझे नहीं लगता कि यह एक रैखिक पास में संभव है, जो बेसलाइन कंपाइलर्स के लिए एक समस्या होगी, जो अब अधिकांश वीएम में मौजूद हैं।

हो सकता है कि मैं बेसलाइन कंपाइलर की अपेक्षाओं को गलत समझ रहा हूं, लेकिन वे क्यों परवाह करेंगे? यदि आप एक गोटो देखते हैं, तो एक जंप निर्देश डालें।

मैं टूल साइड पर 100% सहमत हूं। अधिकांश कंपाइलरों से संरचित कोड उत्सर्जित करना कठिन है! लेकिन मुद्दा यह है कि यह वीएम पक्ष पर इसे आसान बनाता है, और यही वह है जिसे करने के लिए चुना गया था। लेकिन फिर से, मैं मानता हूं कि इसमें आपके द्वारा उल्लिखित डाउनसाइड्स सहित ट्रेडऑफ़ हैं।

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

आप कर सकते हैं, लेकिन यह मामूली नहीं है - वीएम को इसे सत्यापित करने की आवश्यकता होगी। मुझे नहीं लगता कि यह एक रैखिक पास में संभव है, जो बेसलाइन कंपाइलर्स के लिए एक समस्या होगी, जो अब अधिकांश वीएम में मौजूद हैं। (वास्तव में, केवल लूप बैकेज ढूंढना - जो एक आसान समस्या है, और अन्य कारणों से भी जरूरी है - एक फॉरवर्ड पास में नहीं किया जा सकता है, है ना?)

ठीक है, यहाँ बात है, कंपाइलर्स में उपयोग किए जाने वाले एल्गोरिदम के बारे में मेरा ज्ञान पूर्ण निश्चितता के साथ यह बताने के लिए पर्याप्त मजबूत नहीं है कि स्ट्रीमिंग कंपाइलर में इरेड्यूसेबल कंट्रोल फ्लो का पता लगाया जा सकता है या नहीं, लेकिन बात यह है कि इसकी आवश्यकता नहीं है। सत्यापन संकलन के साथ मिलकर हो सकता है। यदि कोई स्ट्रीमिंग एल्गोरिदम मौजूद नहीं है, जो न तो आप और न ही मुझे पता है कि यह नहीं है, तो फ़ंक्शन पूरी तरह से प्राप्त होने के बाद आप एक गैर-स्ट्रीमिंग एल्गोरिदम का उपयोग कर सकते हैं। यदि (किसी कारण से) अपरिवर्तनीय नियंत्रण प्रवाह अनंत लूप की तरह वास्तव में कुछ खराब हो जाता है, तो आप संकलन को समय-समय पर समाप्त कर सकते हैं और/या संकलन थ्रेड को रद्द कर सकते हैं। हालांकि, यह मानने का कोई कारण नहीं है कि ऐसा होगा।

हो सकता है कि मैं बेसलाइन कंपाइलर की अपेक्षाओं को गलत समझ रहा हूं, लेकिन वे क्यों परवाह करेंगे? यदि आप एक गोटो देखते हैं, तो एक जंप निर्देश डालें।

भौतिक हार्डवेयर के सीमित रजिस्टरों के लिए आपको वासम की अनंत रजिस्टर मशीन (नहीं, यह एक स्टैक मशीन नहीं है ) को मैप करने की आवश्यकता के कारण यह इतना आसान नहीं है, लेकिन यह एक समस्या है जिसे किसी भी स्ट्रीमिंग कंपाइलर को हल करना होगा और यह पूरी तरह से ऑर्थोगोनल है CFG बनाम पदानुक्रमित नियंत्रण प्रवाह।

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

कोई भी मामला जिसमें अपरिवर्तनीय नियंत्रण प्रवाह कार्यान्वयन को लिखना कठिन बना देता है, जिसमें से मैं किसी के बारे में नहीं सोच सकता, बस स्टब आउट किया जा सकता है और एक त्रुटि वापस कर सकता है, और यदि आपको 100% निश्चित नियंत्रण का पता लगाने के लिए एक अलग, गैर-स्ट्रीमिंग एल्गोरिदम की आवश्यकता है फ्लो इरेड्यूसिबल है (इसलिए आप गलती से इरेड्यूसेबल कंट्रोल फ्लो को स्वीकार नहीं करते हैं) तो वह बेसलाइन कंपाइलर से ही अलग से चल सकता है। मुझे किसी ऐसे व्यक्ति द्वारा बताया गया है जिस पर मुझे विश्वास करने का कारण है कि वह इस विषय पर एक अधिकार है (हालांकि मैं उन्हें लागू करने से बचूंगा क्योंकि मुझे पता है कि वे इस धागे में घसीटा नहीं जाना चाहते हैं) कि एक अपेक्षाकृत सरल स्ट्रीमिंग एल्गोरिथ्म मौजूद है एक CFG की अप्रासंगिकता का पता लगाने के लिए, लेकिन मैं प्रत्यक्ष रूप से यह नहीं कह सकता कि यह सच है।

@oridb

हो सकता है कि मैं बेसलाइन कंपाइलर की अपेक्षाओं को गलत समझ रहा हूं, लेकिन वे क्यों परवाह करेंगे? यदि आप एक गोटो देखते हैं, तो एक जंप निर्देश डालें।

बेसलाइन कंपाइलर्स को अभी भी लूप बैकेज पर अतिरिक्त चेक डालने जैसे काम करने की ज़रूरत है (इस तरह वेब पर एक लटकता हुआ पृष्ठ अंततः धीमी स्क्रिप्ट संवाद दिखाएगा), इसलिए उन्हें इस तरह की चीजों की पहचान करने की आवश्यकता है। साथ ही, वे उचित रूप से कुशल रजिस्टर आवंटन करने का प्रयास करते हैं (बेसलाइन कंपाइलर्स अक्सर ऑप्टिमाइज़िंग कंपाइलर की गति के बारे में 1/2 पर चलते हैं - जो बहुत प्रभावशाली है क्योंकि वे सिंगल-पास हैं!) जुड़ने और विभाजन सहित नियंत्रण प्रवाह की संरचना होने से यह बहुत आसान हो जाता है।

@gwvo

उस ने कहा, सब कुछ गैर-तुच्छ की तरह, यह एक व्यापार-बंद है, काला और सफेद नहीं। [..] हम बहुत अधिक लाभ के लिए दुनिया को हुप्स के माध्यम से उछाल रहे हैं।

पूरी तरह से सहमत हैं कि यह एक ट्रेडऑफ है, और यहां तक ​​​​कि शायद तब भी गलत हो गया था। लेकिन मेरा मानना ​​​​है कि उन हुप्स को टूल साइड पर ठीक करना कहीं अधिक व्यावहारिक है।

फिर, "बाजार फैसला करता है" और हम देखते हैं कि इंजनों पर इसके लिए बेहतर कोड उत्सर्जित करने का दबाव है या नहीं।

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

@ वुरिख

मैंने बेसलाइन कंपाइलर पर एक साल से अधिक समय तक काम किया और मेरा जीवन आसान हो गया और एक अंतरिम कदम जोड़ने के बाद उत्सर्जित कोड तेज हो गया जिसने वासम के नियंत्रण प्रवाह को सीएफजी में बदल दिया।

बहुत ही रोचक! वह कौन सा वीएम था?

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

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

लूप बैकेज के लिए: एक बैकएज को एक निर्देश के रूप में परिभाषित करें जो पहले निर्देश स्ट्रीम में कूदता है। सबसे खराब स्थिति में, यदि ब्लॉकों को पीछे की ओर रखा जाता है, तो आपको आवश्यकता से अधिक बैकएज चेक मिलते हैं।

रजिस्टर आवंटन के लिए: यह सिर्फ मानक रैखिक स्कैन रजिस्टर आवंटन है । रजिस्टर आवंटन के लिए एक चर का जीवनकाल चर के पहले उल्लेख से लेकर अंतिम उल्लेख तक होता है, जिसमें सभी ब्लॉक शामिल होते हैं जो बीच में रैखिक रूप से होते हैं। सबसे खराब स्थिति में, यदि ब्लॉकों को इधर-उधर कर दिया जाता है, तो आपको आवश्यकता से अधिक जीवनकाल मिलता है और इस प्रकार अनावश्यक रूप से चीजों को ढेर में गिरा दिया जाता है। एकमात्र अतिरिक्त लागत प्रत्येक चर के पहले और अंतिम उल्लेख को ट्रैक कर रही है, जो एक एकल रैखिक स्कैन के साथ सभी चर के लिए किया जा सकता है। (wasm के लिए मुझे लगता है कि "चर" या तो स्थानीय या स्टैक स्लॉट है।)

@क्रिपकेन

मैं बाइनरी सीएफजी कोड को गो में पोर्ट करने पर विचार कर सकता हूं, अगर इससे गो कंपाइलर - @neelance को मदद मिलेगी?

Asyncify को एकीकृत करने के लिए? कृपया प्रस्ताव पर टिप्पणी करें।

@comex

अच्छे अंक!

एकमात्र अतिरिक्त लागत प्रत्येक चर के पहले और अंतिम उल्लेख को ट्रैक कर रही है

हां, मुझे लगता है कि यह एक महत्वपूर्ण अंतर है। लीनियर स्कैन रजिस्टर आवंटन वर्तमान में किए गए wasm बेसलाइन कंपाइलर्स की तुलना में बेहतर (लेकिन करने में धीमा) और साथ ही वे सरल बनाते हैं विकल्प जैसे ही वे जाते हैं ("बेवकूफ" उस पोस्ट में प्रयुक्त शब्द है)।

आवंटन को पंजीकृत करने के लिए V8 का स्ट्रीमिंग दृष्टिकोण ठीक उसी तरह काम करना चाहिए, जब ब्लॉकों को पारस्परिक रूप से पुनरावर्ती होने की अनुमति दी जाती है (जैसे कि https://github.com/WebAssembly/design/issues/796#issuecomment-742690194), क्योंकि वे एकमात्र जीवनकाल से निपटते हैं एक ही ब्लॉक (स्टैक) के भीतर बंधे हैं या फ़ंक्शन-वाइड (स्थानीय) माना जाता है।

IIUC ( टिप्पणी के संदर्भ में) V8 के लिए मुख्य मुद्दा CFG के प्रकार में निहित है जिसे Turbofan अनुकूलित कर सकता है।

@क्रिपकेन

हमने VM पर wasm को यथासंभव सरल बनाने का प्रयास किया है, इसलिए इसे जटिल अनुकूलन की आवश्यकता नहीं है

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

उदाहरण के लिए, मुझे पूरा यकीन है कि एलएलवीएम (वर्तमान में हमारे # 1 वासम निर्माता) फ़ंकलेट्स का उपयोग करने के लिए स्विच नहीं करेंगे, जब तक कि यह आश्वस्त न हो कि यह प्रमुख इंजनों में प्रदर्शन प्रतिगमन नहीं है।

@kripken यह https://github.com/bytecodealliance/wasmtime/tree/main/crates/lightbeam

धन्यवाद @Vurich , दिलचस्प। विशेष रूप से स्टार्टअप के लिए लेकिन थ्रूपुट के लिए उपलब्ध होने पर पूर्ण संख्या देखना बहुत अच्छा होगा। मुझे लगता है कि आपका दृष्टिकोण V8 और स्पाइडरमोन्की इंजीनियरों द्वारा लिए गए दृष्टिकोण की तुलना में अधिक धीरे-धीरे संकलित होगा, जबकि तेज़ कोड उत्सर्जित करेगा। तो यह इस स्पेस में एक अलग ट्रेडऑफ है। यह प्रशंसनीय प्रतीत होता है कि आपका दृष्टिकोण wasm के संरचित नियंत्रण प्रवाह से लाभान्वित नहीं होता है, जैसा कि आपने कहा, जबकि उनका करता है।

नहीं, यह एक स्ट्रीमिंग कंपाइलर है और उन दो इंजनों में से किसी एक की तुलना में तेजी से कोड उत्सर्जित करता है (हालांकि ऐसे खराब मामले हैं जो उस समय तय नहीं किए गए थे जब मैंने प्रोजेक्ट छोड़ा था)। जबकि मैंने तेजी से कोड उत्सर्जित करने के लिए अपनी पूरी कोशिश की, यह मुख्य रूप से माध्यमिक चिंता के आउटपुट की दक्षता के साथ कोड को जल्दी से उत्सर्जित करने के लिए डिज़ाइन किया गया है। स्टार्टअप लागत, मेरे ज्ञान के लिए, शून्य है (वास्मटाइम की अंतर्निहित लागत से ऊपर जो बैकएंड के बीच साझा की जाती है) क्योंकि प्रत्येक डेटा संरचना अनियमित शुरू होती है और संकलन निर्देश-दर-निर्देश किया जाता है। जबकि मेरे पास V8 या स्पाइडरमोन्की की तुलना करने के लिए संख्याएं नहीं हैं, मेरे पास क्रेनलिफ्ट (wasmtime में प्राथमिक इंजन) की तुलना करने के लिए संख्याएं हैं। वे इस बिंदु पर कई महीने पुराने हैं, लेकिन आप देख सकते हैं कि यह न केवल क्रेनलिफ्ट की तुलना में तेजी से कोड उत्सर्जित करता है, बल्कि यह क्रेनलिफ्ट की तुलना में तेज कोड भी उत्सर्जित करता है। उस समय, यह स्पाइडरमॉन्की की तुलना में तेज़ कोड भी उत्सर्जित करता था, हालाँकि इसके लिए आपको मेरी बात माननी होगी, इसलिए यदि आप मुझ पर विश्वास नहीं करते हैं तो मैं आपको दोष नहीं दूँगा। जबकि मेरे पास हाथ में हाल के नंबर नहीं हैं, मेरा मानना ​​​​है कि अब राज्य यह है कि क्रेनलिफ्ट और स्पाइडरमोन्की दोनों ने छोटे मुट्ठी भर बगों को ठीक किया जो लाइटबीम की तुलना में इन माइक्रोबेंचमार्क में उनके कम प्रदर्शन वाले आउटपुट का मुख्य स्रोत थे। लेकिन संकलन गति अंतर उस पूरे समय में नहीं बदला जब मैं परियोजना पर था क्योंकि प्रत्येक संकलक अभी भी मौलिक रूप से समान है, और यह संबंधित वास्तुकला है जो प्रदर्शन के विभिन्न स्तरों की ओर जाता है। जबकि मैं आपकी अटकलों की सराहना करता हूं, मुझे नहीं पता कि आपकी यह धारणा कहां से आई है कि जिस विधि को मैंने रेखांकित किया है वह धीमी होगी।

यहां बेंचमार्क हैं, ::compile बेंचमार्क संकलन गति के लिए हैं और ::run बेंचमार्क मशीन कोड आउटपुट की निष्पादन गति के लिए हैं। https://gist.github.com/Vurich/8696e67180aa3c93b4548fb1f298c29e

कार्यप्रणाली यहां है, आप इसे क्लोन कर सकते हैं और अपने लिए परिणामों की पुष्टि करने के लिए बेंचमार्क को फिर से चला सकते हैं लेकिन पीआर संभवतः wasmtime के नवीनतम संस्करण के साथ असंगत होगा, इसलिए यह आपको केवल उस समय के प्रदर्शन की तुलना दिखाएगा जब मैंने पिछली बार अपडेट किया था। जनसंपर्क https://github.com/bytecodealliance/wasmtime/pull/1660

कहा जा रहा है, मेरा तर्क _not_ है कि CFG स्ट्रीमिंग कंपाइलर में प्रदर्शन के लिए एक उपयोगी आंतरिक प्रतिनिधित्व है। मेरा तर्क यह है कि CFG किसी भी कंपाइलर में प्रदर्शन को नकारात्मक रूप से प्रभावित नहीं करते हैं, और निश्चित रूप से उस स्तर तक नहीं जो GCC और Go टीमों को WebAssembly के उत्पादन से पूरी तरह से लॉक करने का औचित्य साबित करेगा। इस सूत्र में लगभग किसी ने भी फंकलेट्स या वासम के समान विस्तार के खिलाफ बहस करते हुए वास्तव में उन परियोजनाओं पर काम नहीं किया है जिनका दावा है कि इस प्रस्ताव से नकारात्मक रूप से प्रभावित होंगे। यह कहने के लिए नहीं कि आपको इस विषय पर टिप्पणी करने के लिए पहले अनुभव की आवश्यकता है, मुझे लगता है कि हर किसी के पास मूल्यवान इनपुट का कुछ स्तर होता है, लेकिन यह कहना है कि बाइकशेड के रंग पर एक अलग राय रखने और बनाने के बीच एक रेखा है बेकार की अटकलों के अलावा और कुछ नहीं पर आधारित दावे।

@ वुरिख

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

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

कारण मैं उलझन में आप V8 और Spidermonkey आधारभूत संकलन बार हरा कर सकते हैं कर रहा हूँ, क्योंकि के रूप में है लिंक मैंने पहले दिया था, उन दो आधारभूत compilers असाधारण संकलन समय के लिए देखते हैं। विशेष रूप से वे कोई आंतरिक आईआर उत्पन्न नहीं करते हैं, वे सीधे वासम से मशीन कोड पर जाते हैं। आपने कहा था कि आपका कंपाइलर एक आंतरिक आईआर (एक सीएफजी के लिए) उत्सर्जित करता है - मैं उम्मीद करता हूं कि आपका संकलन समय धीमा हो जाएगा (अधिक शाखाओं, मेमोरी बैंडविड्थ इत्यादि के कारण)।

लेकिन कृपया उन बेसलाइन कंपाइलर्स के खिलाफ बेंचमार्क करें! मुझे यह देखना अच्छा लगेगा कि मेरा अनुमान गलत है, और मुझे यकीन है कि वी 8 और स्पाइडरमोन्की इंजीनियरों को भी ऐसा ही होगा। इसका मतलब यह होगा कि आपको एक बेहतर डिज़ाइन मिल गया है जिसे अपनाने पर उन्हें विचार करना चाहिए।

V8 के खिलाफ परीक्षण करने के लिए, आप d8 --liftoff --no-wasm-tier-up चला सकते हैं, और स्पाइडरमोन्की के लिए आप sm --wasm-compiler=baseline चला सकते हैं।

(क्रैनलिफ्ट की तुलना करने के निर्देशों के लिए धन्यवाद, लेकिन क्रेनलिफ्ट बेसलाइन कंपाइलर नहीं है, इसलिए इसके खिलाफ संकलन समय की तुलना करना इस संदर्भ में प्रासंगिक नहीं है। अन्यथा बहुत दिलचस्प है, मैं सहमत हूं।)

मेरा अंतर्ज्ञान यह है कि बेसलाइन कंपाइलर्स को funclets/ multiloop का समर्थन करने के लिए अपनी संकलन रणनीति को महत्वपूर्ण रूप से बदलने की आवश्यकता नहीं @kripken द्वारा संदर्भित "नियंत्रण प्रवाह की संरचना, जिसमें शामिल होने और विभाजन शामिल हैं" पर भरोसा किया जाता है, पारस्परिक रूप से पुनरावर्ती ब्लॉकों के संग्रह के लिए सभी इनपुट प्रकारों की आवश्यकता से संतुष्ट होता है (जो वैसे भी स्ट्रीमिंग सत्यापन के लिए प्राकृतिक विकल्प लगता है) . लाइटबीम/वासमटाइम इंजन बेसलाइन कंपाइलर्स को हरा सकता है या नहीं, इससे कोई फर्क नहीं पड़ता; महत्वपूर्ण बात यह है कि क्या इंजन बेसलाइन कम्पाइलर उतने ही तेज रह सकते हैं जितने अभी हैं।

एफडब्ल्यूआईडब्ल्यू, मुझे भविष्य में सीजी मीटिंग में चर्चा के लिए लाए गए इस फीचर को देखने में दिलचस्पी होगी, और मैं @Vurich से व्यापक रूप से सहमत प्रॉपर टेल कॉल्स गाथा के WebAssembly संस्करण से बचने की कोशिश करनी चाहिए)। एक बार जब मैं अपना (वर्तमान में बहुत देर से) थीसिस सबमिशन समाप्त कर लेता हूं, तो मुझे नए साल में इस तरह की सीजी चर्चा पर पहला कदम उठाने में खुशी होगी।

@क्रिपकेन

हां, मुझे लगता है कि यह एक महत्वपूर्ण अंतर है। लीनियर स्कैन रजिस्टर आवंटन वर्तमान में किए गए wasm बेसलाइन कंपाइलर्स की तुलना में बेहतर (लेकिन करने में धीमा) और साथ ही वे सरल बनाते हैं विकल्प जैसे ही वे जाते हैं ("बेवकूफ" उस पोस्ट में प्रयुक्त शब्द है)।

वाह, यह वास्तव में बहुत आसान है।

दूसरी ओर ... वह विशेष एल्गोरिथ्म इतना सरल है कि यह संरचित नियंत्रण प्रवाह के किसी भी गहरे गुण पर निर्भर नहीं करता है। यह बमुश्किल संरचित नियंत्रण प्रवाह के उथले गुणों पर भी निर्भर करता है।

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

निश्चित एबीआई इस प्रकार है (x86 पर):

• यदि मापदंडों की एक गैर-शून्य संख्या है (ब्लॉक में प्रवेश करते समय) या रिटर्न (ब्लॉक से बाहर निकलने पर), तो वास्म स्टैक का शीर्ष rax में चला जाता है, और शेष वास्म स्टैक x86 से मेल खाता है ढेर।
• अन्यथा, संपूर्ण wasm स्टैक x86 स्टैक से मेल खाता है।

यह क्यों मायने रखता है?

क्योंकि यह एल्गोरिथम बहुत कम जानकारी के साथ लगभग उसी तरह काम कर सकता है। एक विचार प्रयोग के रूप में, WebAssembly के एक वैकल्पिक-ब्रह्मांड संस्करण की कल्पना करें जहां कोई संरचित नियंत्रण प्रवाह निर्देश नहीं थे, बस देशी असेंबली के समान निर्देश कूदें। इसे केवल एक अतिरिक्त जानकारी के साथ संवर्धित करना होगा: यह बताने का एक तरीका कि कौन से निर्देश छलांग के लक्ष्य हैं।

तब एल्गोरिथ्म बस होगा: निर्देशों के माध्यम से रैखिक रूप से जाना; कूदने और कूदने के लक्ष्य से पहले, रजिस्टरों को निश्चित एबीआई में फ्लश करें।

एक अंतर यह है कि एक निश्चित एबीआई होना चाहिए, दो नहीं। यह टॉप-ऑफ-स्टैक मान के बीच अंतर नहीं कर सका, अर्थात् छलांग का 'परिणाम', बनाम केवल बाहरी ब्लॉक से स्टैक पर छोड़ा जा रहा है। तो इसे बिना शर्त टॉप-ऑफ-स्टैक को rax रखना होगा।

लेकिन मुझे संदेह है कि प्रदर्शन के लिए इसकी कोई मापनीय लागत होगी; अगर कुछ है, तो यह एक सुधार हो सकता है।

(सत्यापन भी अलग होगा लेकिन फिर भी सिंगल-पास होगा।)

ठीक है, आगे की चेतावनी:

1. यह एक वैकल्पिक ब्रह्मांड नहीं है; हम मौजूदा WebAssembly में बैकवर्ड-संगत एक्सटेंशन बनाने में फंस गए हैं।
2. स्पाइडरमोन्की का बेसलाइन कंपाइलर सिर्फ एक कार्यान्वयन है, और यह संभव है कि यह आवंटन पंजीकरण के संबंध में उप-अनुकूल है: कि अगर यह थोड़ा सा होशियार होता, तो रनटाइम लाभ संकलन-समय की लागत से अधिक हो जाता।
3. भले ही बेसलाइन कंपाइलर्स को अतिरिक्त जानकारी की आवश्यकता न हो, ऑप्टिमाइज़िंग कंपाइलर्स को तेज़ SSA निर्माण के लिए इसकी आवश्यकता हो सकती है।

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

@ कॉनराड-वाट @comex

वे बहुत अच्छे अंक हैं! बेसलाइन कंपाइलर्स के बारे में मेरा अंतर्ज्ञान तब गलत हो सकता है।

और @comex - हाँ, जैसा कि आपने कहा, यह चर्चा उन पहले से किसी एक लिंक

डिज़ाइन के अनुसार, WebAssembly कोड को TurboFan के IR (SSA-निर्माण सहित) में सीधे सिंगल पास में बदलना बहुत ही कुशल है, आंशिक रूप से WebAssembly के संरचित नियंत्रण प्रवाह के कारण।

@ कॉनराड-वाट मैं निश्चित रूप से सहमत हूं कि हमें केवल वीएम लोगों से सीधे प्रतिक्रिया प्राप्त करने और खुले दिमाग रखने की जरूरत है। स्पष्ट होने के लिए, मेरा लक्ष्य यहाँ कुछ भी रोकना नहीं है। मैंने यहां विस्तार से टिप्पणी की क्योंकि कई टिप्पणियों से लगता था कि वासम का संरचित नियंत्रण प्रवाह एक स्पष्ट गलती थी या एक जिसे स्पष्ट रूप से फंकलेट्स/मल्टीलूप के साथ उपचार किया जाना चाहिए - मैं सिर्फ यहां सोच का इतिहास प्रस्तुत करना चाहता था, और इसके मजबूत कारण थे वर्तमान मॉडल के लिए, इसलिए इसमें सुधार करना आसान नहीं हो सकता है।

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

"के लिए" पक्ष पर, यह जानना उपयोगी है कि किन ब्लॉकों में बैकेज हैं। एक स्ट्रीमिंग संकलक गुण (जैसे स्थानीय में सूचकांक WebAssembly के प्रकार प्रणाली में स्पष्ट नहीं कर रहे हैं ट्रैक कर सकते हैं i है स्थानीय में सरणी की सीमा के भीतर arr )। आगे कूदते समय, लक्ष्य को उस बिंदु पर मौजूद गुणों के साथ एनोटेट करना उपयोगी हो सकता है। इस तरह जब कोई लेबल पहुंच जाता है, तो इसके ब्लॉक को उन गुणों का उपयोग करके संकलित किया जा सकता है जो सभी किनारों पर होते हैं, सरणी-सीमा जांच को खत्म करने के लिए कहते हैं। लेकिन अगर किसी लेबल में संभावित रूप से अज्ञात बैकएज हो सकता है, तो उसके ब्लॉक को इस ज्ञान के साथ संकलित नहीं किया जा सकता है। बेशक, एक गैर-स्ट्रीमिंग कंपाइलर कुछ और महत्वपूर्ण लूप-इनवेरिएंट विश्लेषण कर सकता है, लेकिन स्ट्रीमिंग कंपाइलर के लिए यह चिंता करने की ज़रूरत नहीं है कि आगे क्या हो सकता है। (पक्ष विचार: @Vurich उल्लेख करता है कि स्थानीय लोगों के उपयोग के कारण WebAssembly एक स्टैक मशीन नहीं है। #1381 में मैंने स्थानीय लोगों पर कम भरोसा करने और अधिक स्टैक संचालन जोड़ने के कुछ कारण बताए। रजिस्टर आवंटन को आसान बनाना एक और कारण प्रतीत होता है वह दिशा।)

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

(मैं वीएम लोगों से अधिक सुनने के लिए एक और +1 में फेंकना चाहता हूं, भले ही मुझे लगता है कि @kripken विचारों का प्रतिनिधित्व करने के लिए एक अच्छा काम कर रहा है।)

जब मैं कहता हूं कि लाइटबीम एक आंतरिक आईआर उत्पन्न करता है, यह वास्तव में काफी भ्रामक है और मुझे स्पष्ट करना चाहिए था। मैं कुछ समय से प्रोजेक्ट पर काम कर रहा था और कभी-कभी आपको टनल विजन मिल सकता है। मूल रूप से, लाइटबीम निर्देश द्वारा इनपुट निर्देश का उपभोग करता है (इसमें वास्तव में अधिकतम एक-निर्देश लुकहेड है लेकिन यह विशेष रूप से महत्वपूर्ण नहीं है), और प्रत्येक निर्देश के लिए यह आलसी और निरंतर स्थान पर, कई आंतरिक आईआर निर्देशों का उत्पादन करता है। प्रति Wasm निर्देश की अधिकतम संख्या स्थिर और छोटी है, कुछ 6 की तरह। यह पूरे फ़ंक्शन के लिए IR निर्देशों का बफर नहीं बना रहा है और उस पर काम कर रहा है। फिर, यह उन IR निर्देशों को एक-एक करके पढ़ता है। आप वास्तव में इसे अधिक सामान्य सहायक कार्यों की लाइब्रेरी के रूप में सोच सकते हैं कि यह प्रत्येक वासम निर्देश को लागू करता है, मैं इसे केवल आईआर के रूप में संदर्भित करता हूं क्योंकि इससे यह समझाने में मदद मिलती है कि नियंत्रण प्रवाह आदि के लिए इसका एक अलग मॉडल कैसे है। यह संभवत: V8 या स्पाइडरमोन्की के बेसलाइन कंपाइलर के रूप में तेजी से कोड का उत्पादन नहीं करता है, लेकिन ऐसा इसलिए है क्योंकि यह पूरी तरह से अनुकूलित नहीं है और इसलिए नहीं कि यह वास्तुशिल्प रूप से कमी है। मेरा मुद्दा यह है कि मैं आंतरिक रूप से वासम के पदानुक्रमित नियंत्रण प्रवाह को मॉडल करता हूं जैसे कि यह एक सीएफजी था, वास्तव में एलएलवीएम या क्रेनलिफ्ट की तरह स्मृति में आईआर के बफर का उत्पादन करने के बजाय।

एक अन्य विकल्प यह है कि वासम को किसी ऐसी चीज के लिए संकलित किया जाए जो आपको लगता है कि नियंत्रण प्रवाह को बेहतर तरीके से संभाल सकता है, अर्थात संरचना को "पूर्ववत करें"। एलएलवीएम ऐसा करने में सक्षम होना चाहिए, इसलिए एलएलवीएम (जैसे डब्ल्यूएवीएम या वासमर) का उपयोग करने वाले वीएम में या वासमबॉक्ससी के माध्यम से वासम चलाना दिलचस्प हो सकता है।

@kripken दुर्भाग्य से, LLVM अभी तक संरचना को पूर्ववत करने में सक्षम नहीं लगता है। जंप थ्रेडिंग ऑप्टिमाइज़ेशन पास ऐसा करने में सक्षम होना चाहिए, लेकिन अभी तक इस पैटर्न को नहीं पहचानता है। यहां कुछ C++ कोड दिखाने वाला एक उदाहरण दिया गया है जो नकल करता है कि कैसे relooper एल्गोरिथम CFG को लूप+स्विच में बदल देगा। GCC इसे "dereloop" करने का प्रबंधन करता है, लेकिन क्लैंग नहीं करता है: https://godbolt.org/z/GGM9rP

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

@comex

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

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

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

एक अधिक सूक्ष्म लागत संकलक की रखरखाव है ... यह पहले से ही काफी जटिल है, और चूंकि यह एक-पास है और आईआर ग्राफ का निर्माण नहीं करता है या गतिशील मेमोरी का उपयोग बिल्कुल नहीं करता है, यह लेयरिंग और एब्स्ट्रैक्शन के लिए प्रतिरोधी है।

@RossTate

फिर से funclets/gotos, मैंने दूसरे दिन funclet spec को स्किम किया और पहली नज़र में ऐसा नहीं लग रहा था कि एक-पास कंपाइलर को इसके साथ कोई वास्तविक समस्या होनी चाहिए, निश्चित रूप से एक सरल रीगैलोक योजना के साथ नहीं। लेकिन एक बेहतर योजना के साथ भी यह ठीक हो सकता है: एक जॉइन पॉइंट तक पहुंचने वाले पहले किनारे को यह तय करना होगा कि रजिस्टर असाइनमेंट क्या है, और अन्य किनारों को अनुरूप होना होगा।

@ कॉनराड-वाट जैसा कि आपने अभी सीजी मीटिंग में उल्लेख किया है, मुझे लगता है कि आपका मल्टी-लूप कैसा दिखता है, इस बारे में विवरण देखने में हमें बहुत दिलचस्पी होगी।

@aardappel हाँ, जीवन मुझ पर तेजी से आया है, लेकिन मुझे इसे अगली बैठक में करना चाहिए। बस इस बात पर जोर देने के लिए कि यह विचार मेरा नहीं है क्योंकि @rossberg ने मूल रूप से

एक संदर्भ जो शिक्षाप्रद हो सकता है वह एक प्रकार का दिनांकित है, लेकिन डीजे ग्राफ़ का उपयोग करके इरेड्यूसिबल लोगों को संभालने के लिए लूप की परिचित धारणाओं को सामान्यीकृत करता है।

हमने इसके बारे में सीजी में कुछ चर्चा सत्र किए हैं, और मैंने एक सारांश और अनुवर्ती दस्तावेज़ लिखा है। लंबाई के कारण मैंने इसे एक अलग सार बना दिया है।

https://gist.github.com/conrad-watt/6a620cb8b7d8f0191296e3eb24dffdef

मुझे लगता है कि दो तत्काल कार्रवाई योग्य प्रश्न (अधिक विवरण के लिए अनुवर्ती अनुभाग देखें) हैं:

• क्या हम "जंगली" प्रोग्राम ढूंढ सकते हैं जो वर्तमान में पीड़ित हैं और multiloop से प्रदर्शन-वार लाभान्वित होंगे? ये ऐसे प्रोग्राम हो सकते हैं जिनके लिए एलएलवीएम ट्रांसफॉर्मेशन इरेड्यूसबल कंट्रोल फ्लो पेश करते हैं, भले ही सोर्स प्रोग्राम में मौजूद न हो।
• क्या कोई ऐसी दुनिया है जहां multiloop को "वेब" Wasm के लिए कुछ लिंकिंग/अनुवाद परिनियोजन परत के साथ पहले निर्माता-पक्ष लागू किया गया है?

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

चूँकि ये चर्चाएँ कुछ हद तक शाखाबद्ध हो सकती हैं, इसलिए उनमें से कुछ को बदलना उचित हो सकता है।

मैं इस मुद्दे पर प्रगति देखकर बहुत खुश हूं। शामिल सभी लोगों को एक बड़ा "धन्यवाद"!

क्या हम "जंगली" प्रोग्राम ढूंढ सकते हैं जो वर्तमान में पीड़ित हैं और मल्टीलूप से प्रदर्शन-वार लाभान्वित होंगे? ये ऐसे प्रोग्राम हो सकते हैं जिनके लिए एलएलवीएम ट्रांसफॉर्मेशन इरेड्यूसबल कंट्रोल फ्लो पेश करते हैं, भले ही सोर्स प्रोग्राम में मौजूद न हो।

मैं सर्कुलर रीजनिंग के खिलाफ थोड़ा सावधान करना चाहता हूं: वर्तमान में खराब प्रदर्शन वाले प्रोग्राम इस कारण से "जंगली में" होने की संभावना कम हैं।

मुझे लगता है कि अधिकांश गो कार्यक्रमों से बहुत लाभ होना चाहिए। गो कंपाइलर को या तो WebAssembly coroutines या multiloop होती है, जो कि Go के goroutines का समर्थन करने वाले कुशल कोड का उत्सर्जन करने में सक्षम हो।

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

• सहमत हूं कि इस चर्चा को funclets (या एक नया) रेपो के मुद्दों पर ले जाया जाना चाहिए।
• सहमत हूं कि एलएलवीएम (और गो, और अन्य) के बिना इससे लाभान्वित होने वाले कार्यक्रम को खोजना मुश्किल है, वास्तव में सबसे इष्टतम नियंत्रण प्रवाह (जो कि इरेड्यूसेबल हो सकता है) का उत्सर्जन करता है। FixIrreducibleControlFlow और दोस्तों की वजह से अक्षमता एक बड़े बाइनरी में "हजार कट से मौत" समस्या हो सकती है।
• जबकि मैं इस चर्चा से निकलने वाली पूर्ण न्यूनतम प्रगति के रूप में केवल टूल-कार्यान्वयन का स्वागत करता हूं, यह अभी भी इष्टतम नहीं होगा, क्योंकि उत्पादकों के पास सुविधा के लिए इस कार्यक्षमता का उपयोग करने का कठिन विकल्प है (लेकिन फिर अप्रत्याशित प्रदर्शन प्रतिगमन का सामना करना पड़ता है/ क्लिफ्स), या चीजों को अनुमानित करने के लिए अपने आउटपुट को मानक वासम तक सीमित करने के लिए कड़ी मेहनत करते हैं।
• यदि यह निर्णय लिया गया कि "गोटोस" केवल एक टूल-केवल सुविधा है, तो मैं तर्क दूंगा कि आप शायद मल्टीलूप की तुलना में एक सरल सुविधा से दूर हो सकते हैं, क्योंकि आपको केवल निर्माता सुविधा की परवाह है। पूर्ण न्यूनतम पर, एक goto <function_byte_offset> केवल एक चीज होगी जिसे नियमित Wasm फ़ंक्शन निकायों में डालने की आवश्यकता होगी ताकि WABT या Binaryen को इसे कानूनी Wasm में बदलने की अनुमति मिल सके। टाइप सिग्नेचर जैसी चीजें उपयोगी होती हैं यदि इंजन को एक मल्टीलूप को जल्दी से सत्यापित करने की आवश्यकता होती है, लेकिन यदि यह एक सुविधा उपकरण है, तो यह उत्सर्जन के लिए अधिकतम सुविधाजनक बना सकता है।

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

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

अधिक विशेष रूप से, उन्होंने इसे C/C++ के लिए एक महत्वपूर्ण कारक नहीं पाया। इरेड्यूसेबल कंट्रोल फ्लो के प्रदर्शन की तुलना में इसका C/C++ से अधिक लेना-देना हो सकता है। (मैं ईमानदारी से नहीं जानता।) ऐसा लगता है कि @neelance के पास यह

मेरा मानना ​​है कि इस समस्या के कई पहलू हैं, और इसका कई दिशाओं में समाधान करना सार्थक है।

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

दूसरा, हम इस बात पर विचार कर सकते हैं कि "pre" -WebAssembly की कौन सी विशेषताएं सीधे "सत्य" WebAssembly में शामिल करने लायक हैं। हम इसे एक सूचित तरीके से कर सकते हैं क्योंकि हमारे पास "प्री" -वेबअसेंबली मॉड्यूल होंगे जिनका हम विश्लेषण कर सकते हैं इससे पहले कि वे "सच्चे" वेबअसेंबली मॉड्यूल में बदल गए हों।

कुछ साल पहले मैंने एक गतिशील भाषा (https://github.com/ciao-lang/ciao) के लिए webassembly के लिए एक विशेष बाइटकोड एमुलेटर को संकलित करने का प्रयास किया और प्रदर्शन इष्टतम से बहुत दूर था (कभी-कभी मूल संस्करण की तुलना में 10 गुना धीमा)। मुख्य निष्पादन लूप में एक बड़ा बाइटकोड प्रेषण स्विच था, और वास्तविक हार्डवेयर पर चलने के लिए इंजन को दशकों तक बारीक रूप से ट्यून किया गया था, और हम लेबल और गोटो का भारी उपयोग करते हैं। मुझे आश्चर्य है कि क्या इस तरह के सॉफ़्टवेयर को इरेड्यूसीबल नियंत्रण प्रवाह के समर्थन से लाभ होगा या यदि समस्या एक और थी। मेरे पास आगे की जांच करने के लिए समय नहीं था, लेकिन अगर चीजें बेहतर हुई हैं तो मुझे फिर से प्रयास करने में खुशी होगी। बेशक मैं समझता हूं कि अन्य भाषाओं को वीएम से वासम में संकलित करना मुख्य उपयोग का मामला नहीं है, लेकिन मुझे यह जानकर अच्छा लगेगा कि क्या यह अंततः संभव होगा, विशेष रूप से सार्वभौमिक बाइनरी जो हर जगह कुशलतापूर्वक चलती हैं, वादा किए गए लाभों में से एक है। मी था। (धन्यवाद और क्षमा करें यदि इस विशेष विषय पर किसी अन्य मुद्दे पर चर्चा की गई है)

@jfmc मेरी समझ यह है कि, यदि कार्यक्रम यथार्थवादी है (अर्थात पैथोलॉजिकल होने के लिए नहीं बनाया गया है) और आप इसके प्रदर्शन की परवाह करते हैं, तो यह पूरी तरह से वैध उपयोग का मामला है। WebAssembly का लक्ष्य एक अच्छा सामान्य-उद्देश्य लक्ष्य होना है। इसलिए मुझे लगता है कि यह समझना बहुत अच्छा होगा कि आपने इतनी महत्वपूर्ण मंदी क्यों देखी। यदि ऐसा नियंत्रण प्रवाह पर प्रतिबंधों के कारण होता है, तो इस चर्चा में यह जानना बहुत उपयोगी होगा। यदि यह किसी और चीज के कारण होता है, तो यह जानना अभी भी उपयोगी होगा कि सामान्य रूप से WebAssembly को कैसे बेहतर बनाया जाए।