Design: क्या WebAssembly.Instance पहले से संकलित मॉड्यूल को पुन: संकलित कर सकता है?

कभी-कभी पुनर्संकलन का कारण बनने के लिए WebAssembly.Instance लिए अच्छा होगा, इस तरह अपरिवर्तनीय ग्लोबल्स वर्र्स को जेनरेट कोड में लगातार फोल्ड किया जा सकता है। उदाहरण के लिए, Emscripten सभी पॉइंटर्स को स्टैटिक डेटा में ऑफसेट करके स्थानांतरित करने योग्य कोड उत्पन्न करता है। जब मॉड्यूल को तत्काल किया जाता है तो ऑफ़सेट को अपरिवर्तनीय वैश्विक संस्करण के रूप में पारित किया जाता है। यदि WebAssembly.Instance पुन: संकलित कर सकता है, तो यह जेनरेट कोड का विशेषज्ञ हो सकता है।

विनिर्देश परिभाषित नहीं करता है कि "संकलन" क्या है, न ही यह बना देगा
ऐसा करने के लिए समझ में आता है, क्योंकि कार्यान्वयन के दृष्टिकोण बेतहाशा भिन्न हो सकते हैं
(दुभाषियों सहित)। इसलिए इस बारे में उसका कोई मानक नहीं कहा जा सकता है
किसी भी तरह से। सबसे अच्छा हम एक नोट जोड़ सकते हैं कि
WebAssembly.Instance "तेज़" होने की उम्मीद है।

२७ अक्टूबर २०१६ को ०३:२४ बजे, माइकल बेबेनिता नोटिफिकेशन @github.com
लिखा था:

WebAssembly के लिए अच्छा होगा। कभी-कभी पुन: संकलन का कारण बनने के लिए,
इस तरह अपरिवर्तनीय ग्लोबल्स वर्र्स को जेनरेट में लगातार फोल्ड किया जा सकता है
कोड। उदाहरण के लिए, एम्सस्क्रिप्टन सभी को ऑफसेट करके स्थानांतरित करने योग्य कोड उत्पन्न करता है
स्थिर डेटा के लिए संकेत। ऑफसेट को एक अपरिवर्तनीय वैश्विक var . के रूप में पारित किया जाता है
जब मॉड्यूल को तत्काल किया जाता है। यदि WebAssembly.Instance पुन: संकलित कर सकता है,
यह जेनरेट कोड का विशेषज्ञ हो सकता है।

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

सहमत हूं कि यह एक गैर-मानक नोट होगा।

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

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

• इम्प्लांट कंटेंट-एड्रेस्ड कैशिंग कर सकता है (जिसमें कुंजी में परिवेश पैरामीटर शामिल हो सकते हैं), जैसे हम वर्तमान में एफएफ में asm.js के साथ करते हैं। यह एक तरह का दर्द होगा और इसमें किसी भी निहित कैश की सभी पूर्वानुमान/अनुमानी समस्याएं हैं।
• हम एक नया तरीका बना सकते हैं (उदाहरण के लिए, एक नया WebAssembly.Cache एपीआई जहां आप बाइटकोड और इंस्टेंटेशन पैरामीटर में पास होते हैं और Promise<Instance> वापस प्राप्त करते हैं।

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

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

@lukewagner निहित या स्पष्ट कैशिंग के साथ भी हमारे पास एक ही समस्या हो सकती है: एक ही पता-स्थान/मूल में कितने WebAssembly.Memory बनाए जा सकते हैं एक ब्राउज़र सीमा है। आप जो सुझाव दे रहे हैं वह मुझे पसंद है, लेकिन मुझे लगता है कि यह इस मुद्दे के लिए ऑर्थोगोनल है। मुझे बताएं कि क्या मैंने आपके सुझाव को गलत समझा है।

शायद .compile और Module को Memory दिया जा सकता है, और Instance में .memory संपत्ति है जिसे अन्य संकलन/तत्काल में पारित किया जा सकता है ?

मैं पुन: संकलन की संभावना को खत्म करने की कोशिश नहीं कर रहा हूं, मुझे लगता है कि हम एक सामान्य मुहावरेदार एपीआई उपयोग चाहते हैं, जिसमें पहले-संकलन-समय (या कैश-पुनर्प्राप्ति समय पर) पर सही जानकारी Memory हो। यदि आवश्यक हो तो संकलन सीमा जांच करता है या नहीं।

@jfbastien निहित/स्पष्ट कैशिंग के साथ जो विशेष तत्काल पैरामीटर (इसलिए Memory ) प्रदान किया गया था, मुझे नहीं लगता कि पुनर्मूल्यांकन की कोई आवश्यकता कैसे होगी।

@jfbastien निहित/स्पष्ट कैशिंग के साथ जो विशेष तत्काल पैरामीटर (इसलिए Memory ) प्रदान किया गया था, मुझे नहीं लगता कि पुनर्मूल्यांकन की कोई आवश्यकता कैसे होगी।

वहाँ हो सकता है:

1. कई Memory s बनाएँ।
2. स्पष्ट (धीमी) सीमाओं की जांच के साथ कोड संकलित करें क्योंकि बहुत अधिक Memory यानी थे।
3. उस कोड को कैश करें।
4. पेज छोड़ें।
5. पेज फिर से लोड करें।
6. केवल एक Memory आवंटित करें, जो तेज़ संस्करण प्राप्त करता है।
7. कैश से प्राप्त करें।
8. धीमा कोड Instance ।

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

जैसा कि मैंने कहा: मुझे आपके द्वारा प्रस्तावित यह Cache एपीआई पसंद है, मुझे लगता है कि यह WebAssembly को अधिक उपयोगी बनाता है, लेकिन मुझे लगता है कि समस्या अभी भी है। मैं

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

1. कई Memory बनाएं
2. कैश से Instance अनुरोध करें, उनमें से एक को पास करें (धीमा) Memory s
3. धीमा-कोड संकलित, कैश्ड और Instance रूप में लौटाया जाता है
4. पेज छोड़ें
5. पेज फिर से लोड करें
6. केवल एक Memory आवंटित करें
7. कैश से Instance अनुरोध करें, तेजी से Memory
8. फास्ट-कोड संकलित, कैश्ड और Instance रूप में लौटाया जाता है

और चरण 8 के बाद, भविष्य के सभी पेज लोड को तेज या धीमा कोड कैश किया जाएगा।

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

मेरे लिए मुद्दा यह है: एक अनुकूलन जो हम सभी को प्रतिस्पर्धी कारणों से प्रभावी ढंग से करना होगा (4GB वर्चुअल मेमोरी बाउंड चेकिंग, जिसे मैं सिर्फ 4GB हैक कहूंगा) बिना त्याग के वर्तमान कल्पना में नहीं किया जा सकता है इन चीजों में से एक:

• यदि आप किसी भी wasm मेमोरी के लिए हमेशा 4GB वर्चुअल मेमोरी आवंटित करते हैं तो आप इससे दूर हो सकते हैं। यह लोगों को छोटे मॉड्यूल के लिए WebAssembly का उपयोग करने से हतोत्साहित करेगा, क्योंकि यदि आप इनमें से कई को आवंटित करते हैं, तो आप वर्चुअल मेमोरी आवंटन सीमा, वर्चुअल मेमोरी फ़्रेग्मेंटेशन, या अन्य समस्याओं का सामना करेंगे। मुझे यह भी डर है कि यदि आप उनमें से बहुत से आवंटन की अनुमति देते हैं तो आप एएसएलआर जैसे सुरक्षा शमन की प्रभावकारिता को कम कर देंगे। ध्यान दें कि मौजूदा एपीआई इस खतरे को साझा नहीं करते हैं, क्योंकि वे आवंटित स्मृति को प्रतिबद्ध करते हैं और भौतिक स्मृति की अनुमति से अधिक आवंटित करने से पहले वे या तो ओओएम या क्रैश हो जाएंगे।
• आप इससे दूर हो सकते हैं यदि आप तत्कालता के दौरान एक बेमेल मिलने पर पुन: संकलन की अनुमति देते हैं (संकलित कोड 4 जीबी हैक चाहता है लेकिन स्मृति में वर्चुअल मेमोरी आवंटन नहीं है)। यदि इंस्टेंटेशन ने मेमोरी को 4GB क्षेत्र में स्थानांतरित कर दिया, तो आप इससे दूर भी हो सकते हैं, लेकिन पिछले बिंदु को देखें। तो, शायद कभी भी ऐसा होता है, यह उस ब्राउज़र के लिए P1 बग होगा जिसने इसका सामना किया।

मुझे लगता है कि इसका मतलब यह है कि कल्पना विक्रेताओं को केवल 4GB आरक्षण की अनुमति देने के लिए प्रोत्साहित करेगी, कभी भी स्मृति आवंटित की जाती है, या इसका पता लगाने के लिए कैश/आलसी-संकलन/प्रोफ़ाइल अनुकूलन करने के लिए।

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

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

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

यदि हां, तो कैशिंग या एसिंक्स इंस्टेंटिएट के ये विकल्प कैसा महसूस करेंगे:

1. मॉड्यूल लेखक को न्यूनतम/अधिकतम मेमोरी के रूप में 4GB की आवश्यकता होनी चाहिए
2. संकलन का एक प्रकार (कम से कम async, शायद सिंक भी हो सकता है) जो केवल तेज़ मेमोरी को स्वीकार करने वाला एक उदाहरण उत्पन्न करता है।

"4GB हैक" के मुद्दे के लिए और इसका उपयोग करने वाली मेमोरी और कोड की अपेक्षा के बीच बेमेल, क्या यह कोड के दो संस्करणों को आंतरिक रूप से उत्सर्जित करने के लिए संकलन के लिए समझ में आता है? (जाहिर है यह अधिक स्मृति का उपयोग करेगा, जो दुखद है, लेकिन उम्मीद है कि संकलन समय ज्यादा खराब नहीं होगा, लेखक एक ही बार में दोनों उत्पन्न कर सकता है?)

@mtrofin मुझे नहीं लगता कि यदि आप इसका उपयोग करने का इरादा नहीं रखते हैं तो 4GiB के लिए पूछना समझ में आता है। वर्चुअल आवंटन उपयोग के इरादे से अलग है, इसलिए मुझे लगता है कि हमें दोनों को अलग करना होगा।

2 पर: यह अभी भी डेवलपर के लिए बहुत उपयोगी नहीं है: यदि वे उस संस्करण का उपयोग करते हैं और यह विफल हो जाता है, तो क्या?

@kripken मुझे नहीं लगता कि डबल संकलन एक अच्छा विचार है।

@kripken मुझे लगता है कि हम इस मुद्दे के किसी अन्य समाधान के बिना क्या करेंगे।

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

@mtrofin

मॉड्यूल लेखक को न्यूनतम/अधिकतम मेमोरी के रूप में 4GB की आवश्यकता होनी चाहिए

यह वास्तव में व्यावहारिक नहीं है, क्योंकि कई उपकरणों में 4GB की भौतिक मेमोरी नहीं होती है। इसके अलावा, यह कल्पना करना मुश्किल है।

संकलन का एक प्रकार (कम से कम async, शायद सिंक भी हो सकता है) जो केवल तेज़ मेमोरी को स्वीकार करने वाला एक उदाहरण उत्पन्न करता है।

मुझे नहीं लगता कि हम डबल कंपाइल चाहते हैं।

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

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

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

@lukewagner

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

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

आपके द्वारा आवंटित की जाने वाली 4GB मेमोरी की संख्या पर आपके पास क्या सीमा है? जब आप इस सीमा तक पहुंच जाते हैं तो आप क्या करते हैं - पूरी तरह से छोड़ दें, या तत्कालता पर पुन: संकलित करें?

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

मैं मानता हूं कि विश्लेषण हमें अधिक जांचों को समाप्त करने की अनुमति देता है, लेकिन यदि आप पीक परफ चाहते हैं तो 4GB हैक जाने का रास्ता है। हर कोई पीक परफ़ चाहता है, और मुझे लगता है कि सुरक्षा समस्याओं, संसाधन समस्याओं और अप्रत्याशित पुनर्संकलन के बिना पीक परफ़ प्राप्त करना संभव बनाना बहुत अच्छा होगा।

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

कोड जिसमें सीमा जांच होती है, स्मृति आकार के लिए एक रजिस्टर पिन करना और मेमोरी बेस के लिए एक रजिस्टर पिन करना सबसे अच्छा है।

4GB हैक का उपयोग करने वाले कोड को केवल मेमोरी बेस के लिए एक रजिस्टर पिन करने की आवश्यकता होती है।

तो, यह एक अच्छा समाधान नहीं है।

कल्पना और कार्यान्वयन को कम करने की झुंझलाहट के अलावा, एक वादा कार्रवाई में संकलन और तात्कालिकता के संयोजन के नुकसान क्या हैं?

मुद्दा यह है कि यदि आप इस तरह के बहुत से आवंटन की अनुमति देते हैं तो यह सुरक्षा जोखिम पैदा करता है क्योंकि प्रत्येक ऐसा
आवंटन ASLR की प्रभावकारिता को कम करता है।

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

आपके द्वारा आवंटित की जाने वाली 4GB मेमोरी की संख्या पर आपके पास क्या सीमा है? आप क्या करते हो
जब आप इस सीमा को मारते हैं - पूरी तरह से छोड़ दें, या तत्कालता पर पुन: संकलित करें?

खैर, चूंकि यह asm.js दिनों से है, केवल 1000। तब स्मृति आवंटन बस फेंकता है। हो सकता है कि हमें इसे टक्कर देने की आवश्यकता होगी, लेकिन यहां तक ​​​​कि कई सुपर-मॉड्यूलराइज्ड ऐप्स (प्रत्येक में कई अलग-अलग वॉश मॉड्यूल के साथ) एक ही प्रक्रिया को साझा करते हुए, मैं कल्पना नहीं कर सकता कि हमें बहुत अधिक की आवश्यकता होगी। मुझे लगता है कि Memory सादे पुराने से अलग है ArrayBuffer एस उस ऐप में स्वाभाविक रूप से हजारों बनाना नहीं चाहेंगे।

कल्पना और कार्यान्वयन को कम करने की झुंझलाहट के अलावा, कमियां क्या हैं
एक वादा कार्रवाई में संकलन और तात्कालिकता के संयोजन का?

जैसा कि मैंने ऊपर उल्लेख किया है, एक Promise<Instance> eval(bytecode, importObj) एपीआई जोड़ना ठीक है, लेकिन अब यह डेवलपर को एक कठिन स्थान पर रखता है क्योंकि अब उन्हें अपने संकलित कोड को कैश करने में सक्षम होने के मुकाबले कुछ प्लेटफॉर्म पर एक पूर्ण बूस्ट के बीच चयन करना होगा। सभी प्लेटफॉर्म। ऐसा लगता है कि हमें एक ऐसे समाधान की आवश्यकता है जो कैशिंग के साथ एकीकृत हो और यही मैं ऊपर स्पष्ट Cache API के साथ विचार-मंथन कर रहा था।

नया विचार: क्या होगा यदि हम new Instance का एक एसिंक संस्करण जोड़ते हैं, जैसे WebAssembly.instantiate और, जैसा कि WebAssembly.compile , हम कहते हैं कि सभी को एसिंक संस्करण का उपयोग करना चाहिए? यह कुछ ऐसा है जिस पर मैं _anyway_ पर विचार कर रहा हूं क्योंकि यदि पैचिंग का उपयोग किया जाता है तो इंस्टेंटेशन में कुछ एमएस लग सकते हैं। फिर हम कल्पना में कहते हैं कि इंजन या तो compile या instantiate में महंगा काम कर सकता है (या न ही, अगर कोई इंजन आलसी सत्यापन/संकलन करता है!)

यह अभी भी इस सवाल को छोड़ देता है कि क्या करना है जब compile d Module आईडीबी में संग्रहीत किया जाता है, लेकिन यह एक कठिन प्रश्न है जब कई कोडजन मोड _anyway_ हैं। एक विचार यह है कि Module s जो IDB से संग्रहीत या पुनर्प्राप्त किए जाते हैं, उनकी IDB प्रविष्टि के लिए एक हैंडल पर होते हैं और वे इस प्रविष्टि में नया संकलित कोड जोड़ते हैं। इस तरह, आईडीबी प्रविष्टि अपने मॉड्यूल के एक या अधिक संकलित संस्करणों को आलसी रूप से जमा कर देगी और तत्कालता के दौरान जो भी आवश्यक हो उसे प्रदान करने में सक्षम होगी।

IDB भाग थोड़ा अधिक काम है, लेकिन यह आदर्श, प्रदर्शन-वार के काफी करीब लगता है। डब्ल्यूडीवाईटी?

मुझे लगता है कि async instantiate जोड़ना समझ में आता है, लेकिन मैं Memory पैरामीटर भी compile । यदि instantiate लिए एक अलग मेमोरी पास करें तो आप पुन: संकलित हो सकते हैं, अन्यथा आप संकलन करते समय स्मृति को पहले ही "बाध्य" कर चुके हैं।

मैंने अभी तक पूरी तरह से गठित राय रखने के लिए पर्याप्त कैशिंग के बारे में नहीं सोचा है।

@lukewagner

मैं ASLR का विशेषज्ञ नहीं हूं, लेकिन, iiuc, भले ही हमारे पास एक रूढ़िवादी बाध्यता न हो (अर्थात, यदि हमने आपको mmap विफल होने तक आवंटन जारी रखने की अनुमति दी है, क्योंकि कर्नेल ने अपने नंबर-ऑफ-एड्रेस-रेंज अधिकतम को मारा है) , संपूर्ण 47-बिट एड्रेसेबल स्पेस का केवल एक छोटा सा अंश ही खपत होगा, इसलिए इस 47-बिट स्पेस पर कोड प्लेसमेंट अत्यधिक यादृच्छिक बना रहेगा। IIUC, ASLR कोड प्लेसमेंट या तो पूरी तरह से यादृच्छिक नहीं है; यह भविष्यवाणी करना कठिन बनाने के लिए पर्याप्त है कि कुछ भी कहां होगा।

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

खैर, चूंकि यह asm.js दिनों से है, केवल 1000। तब स्मृति आवंटन बस फेंकता है। हो सकता है कि हमें इसे टक्कर देने की आवश्यकता होगी, लेकिन यहां तक ​​​​कि कई सुपर-मॉड्यूलराइज्ड ऐप्स (प्रत्येक में कई अलग-अलग वॉश मॉड्यूल के साथ) एक ही प्रक्रिया को साझा करते हुए, मैं कल्पना नहीं कर सकता कि हमें बहुत अधिक की आवश्यकता होगी। मुझे लगता है कि मेमोरी सादे पुराने ArrayBuffers से अलग है, उन ऐप्स में स्वाभाविक रूप से हजारों नहीं बनाना चाहते हैं।

1000 एक समझदार सीमा की तरह लगता है। मैं सुरक्षा लोगों के साथ पूछूंगा।

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

सही। मैं कुछ तरीके देख सकता हूं कि इस तरह के एपीआई को काम करने के लिए बनाया जा सकता है। एक घटिया लेकिन व्यावहारिक एपीआई eval को अधिभारित करना होगा:

1. इंस्टेंसप्रोमिस = eval (बाइटकोड, इंपोर्टऑब्ज)
2. इंस्टेंसप्रोमिस = eval (मॉड्यूल, इंपोर्टऑब्ज)

और फिर इंस्टेंस में गेटटर होता है:

मॉड्यूल = उदाहरण। मॉड्यूल

जहां मॉड्यूल संरचना क्लोन करने योग्य है।

आप इस बारे में क्या सोचते है?

नया विचार: क्या होगा यदि हम नए इंस्टेंस का एक एसिंक संस्करण जोड़ते हैं, जैसे WebAssembly.instantiate और, जैसा कि WebAssembly.compile के साथ होता है, हम कहते हैं कि सभी को async संस्करण का उपयोग करना चाहिए? यह ऐसा कुछ है जिस पर मैं वैसे भी विचार कर रहा हूं क्योंकि पैचिंग का उपयोग होने पर तत्कालता में कुछ एमएस लग सकते हैं। फिर हम कल्पना में कहते हैं कि इंजन या तो संकलन या तत्काल में महंगा काम कर सकता है (या न ही, अगर कोई इंजन आलसी सत्यापन/संकलन करता है!)

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

IDB भाग थोड़ा अधिक काम है, लेकिन यह आदर्श, प्रदर्शन-वार के काफी करीब लगता है। डब्ल्यूडीवाईटी?

दिलचस्प। ऊपर मेरे विचार के सापेक्ष:

प्रो: आपका अमूर्त समझने में आसान है जो अवधारणात्मक रूप से अब हम जो कहते हैं उसके समान है।
कॉन: आपका उपयोगकर्ता क्या करता है और इंजन क्या करता है, मेरे प्रस्ताव की अनुमति के बीच उतना तालमेल नहीं होता है।

ऐसे तीन क्षेत्र हैं जहां आपका प्रस्ताव उपयोगकर्ता को मेरे जितना नियंत्रण नहीं देता है:

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

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

यह मुद्दा इस बात पर निर्भर करता है कि विखंडन कितनी बार उपवास का आवंटन करता है
मेमोरी (btw आप 4GB + अधिकतम समर्थित ऑफ़सेट, या 8GB) विफल हो जाएंगे। अगर
शायद 1% से कम है, तो हो सकता है कि यह पूरी तरह से अनुचित न हो
क्या यह एक ओओएम स्थिति है।

उस परिदृश्य में जहां उपयोगकर्ता वेब पर ब्राउज़ कर रहा है और बहुत सारे का उपयोग कर रहा है
त्वरित उत्तराधिकार में छोटे WASM मॉड्यूल, संभवतः वे सभी लाइव नहीं हैं
एक बार। उस स्थिति में, आरक्षित 4GB विखंडू का एक छोटा कैश कम कर देगा
मुद्दा।

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

गुरु, 27 अक्टूबर, 2016 को 9:03 pm पर, pizlonator [email protected]
लिखा था:

@mtrofin https://github.com/mtrofin

मॉड्यूल लेखक को न्यूनतम/अधिकतम मेमोरी के रूप में 4GB की आवश्यकता होनी चाहिए

यह वास्तव में व्यावहारिक नहीं है, क्योंकि कई उपकरणों में 4GB भौतिक नहीं है
याद। इसके अलावा, यह कल्पना करना मुश्किल है।

संकलन का एक प्रकार (कम से कम async, शायद सिंक भी हो सकता है) जो एक उत्पन्न करता है
उदाहरण केवल तेज स्मृति को स्वीकार करना।

मुझे नहीं लगता कि हम डबल कंपाइल चाहते हैं।

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

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

ये सभी बैसाखी हैं जिनका हम उपयोग कर सकते हैं, जैसे कि एनओपी या डबल संकलन, लेकिन बैसाखी भी क्यों?

@jfbastien मुझे नहीं लगता कि PROT_NONE मेमोरी की लागत पृष्ठ तालिका प्रविष्टियाँ हैं; मुझे लगता है कि एक अलग डेटा संरचना है जिसमें मैपिंग होती है जिससे पृष्ठ तालिका आलसी आबादी होती है।

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

हालांकि, मुझे लगता है कि हमें WebAssembly.compile और Module कंस्ट्रक्टर को नहीं लेना चाहिए: मैं उन परिदृश्यों की कल्पना कर रहा हूं जहां आपके पास "कोड सर्वर" है (आईडीबी + postMessage माध्यम से क्रॉस-ओरिजिनल कोड कैशिंग प्रदान करना) new Module माध्यम से), हमें रखने की आवश्यकता होगी new Instance ।

तो अगर उस पर सहमति हो जाती है, तो यह आपके द्वारा उल्लिखित दो WebAssembly.eval ओवरलोड का एक विशुद्ध रूप से योगात्मक प्रस्ताव है। हां?

एक ट्वीक, हालांकि मुझे लगता है कि हम नहीं होना चाहिए एक module गेटर के बाद से इस आवश्यकता होगी Instance के जीवन भर के लिए चारों ओर कुछ आंतरिक डेटा रखने के लिए (अर्थात, बाईटकोड।) Instance ; अभी तत्कालता के तुरंत बाद Module को आमतौर पर GCed किया जा सकता है। यह या तो एक डेटा संपत्ति का सुझाव देगा (जिसे उपयोगकर्ता हटा सकता है, हालांकि वे शायद भूल जाएंगे), या शायद eval का तीसरा संस्करण जो {instance, module} जोड़ी लौटाता है ...

विशिष्ट मोनोलिथिक ऐप के लिए अनुशंसित केस के रूप में एक एसिंक वन स्टेप एपीआई होने से अनुशंसित पैटर्न के रूप में समझ में आता है।

@Lukewagner से सहमत हैं कि नए मॉड्यूल + नए इंस्टेंस द्वारा कवर किए गए सभी सिंक (इनलाइन संकलन) मामले दोनों उपयोगी हैं।
साथ ही सिंक इंस्टेंटिएट के साथ बैकग्राउंड कंपाइल (async) सर्वर भी उपयोगी लगता है।

प्रस्तावित दो eval वेरिएंट को जोड़ना इसे पेश करने का एक अच्छा तरीका है।

हालांकि मुझे नाम पसंद नहीं है, क्योंकि यह (सुरक्षा) लोगों के दिमाग में जेएस eval (जो यह एक तरह से जैसा दिखता है, लेकिन स्कोप कैप्चर के मामले में नहीं) में शामिल हो जाएगा।
WebAssembly.instantiate के बारे में कैसे?

हाह, अच्छा बिंदु, eval में थोड़ा सा प्रतिनिधि है । +1 से WebAssembly.instantiate ।

एसिंक इंस्टेंटिएट का उपयोग करते समय डेवलपर के लिए दिशानिर्देश क्या होगा?

@mtrofin डिफ़ॉल्ट रूप से WebAssembly.instantiate उपयोग करने के लिए जब तक कि उनके पास कुछ विशेष कोड-साझाकरण/लोडिंग योजना न हो जिसके लिए किसी विशेष उपयोग से स्वतंत्र रूप से Module संकलित करने की आवश्यकता हो।

@lukewagner यह उचित लगता है।

हाह, अच्छा बिंदु, eval में थोड़ा सा प्रतिनिधि है। +1 से WebAssembly.instantiate।

माना।

तो अगर उस पर सहमति है, तो यह आपके द्वारा उल्लिखित दो WebAssembly.eval अधिभारों का एक विशुद्ध रूप से योगात्मक प्रस्ताव है। हां?

ऐसा ही लगता है।

मुझे लगता है कि हमारे पास मॉड्यूल गेटर नहीं होना चाहिए क्योंकि इंस्टेंस के जीवनकाल के लिए इंस्टेंस को कुछ आंतरिक डेटा (यानी बाइटकोड) के आसपास रखने की आवश्यकता होगी; अभी तत्कालता के तुरंत बाद मॉड्यूल को जीसीड किया जा सकता है। यह या तो डेटा प्रॉपर्टी का सुझाव देगा (जिसे उपयोगकर्ता हटा सकता है, हालांकि वे शायद भूल जाएंगे), या शायद eval का तीसरा संस्करण जो {instance, मॉड्यूल} जोड़ी देता है ...

निश्चित रूप से ऐसा लगता है कि डेटा प्रॉपर्टी बेहतर है। या WebAssembly.instantiate हमेशा एक उदाहरण, मॉड्यूल जोड़ी लौटाता है।

क्या यह सही है: मान लीजिए कि आप फास्टमेमोरी मॉड्यूल संस्करण प्राप्त करने के लक्ष्य के साथ WebAssembly.instantiate । अब आप मॉड्यूल प्राप्त करते हैं, और इसे संरचना-क्लोन करते हैं। अब, इस मॉड्यूल को फास्टमेमोरी का समर्थन करने वाले Memory -es के साथ तत्काल होने की आवश्यकता है।

@pizlonator हाँ, मैं इसे अपने सिर में कई तरीकों से बाइक कर सकता हूं। मुझे लगता है कि मैं जोड़ी को थोड़ा बेहतर वापस करना पसंद करता हूं क्योंकि इससे शायद कम लोग गलती से अप्रयुक्त Module ।

@mtrofin Recompilation अभी भी आवश्यक हो सकता है जब आप बांधना Module एक बंद instantiate कॉल और instantiate नई आयात के साथ; मुझे लगता है कि इस एपीआई जोड़ का मुद्दा यह है कि यह सामान्य मामला नहीं होगा और यह केवल तभी होगा जब यह मौलिक रूप से आवश्यक हो (यानी, आपके पास दो प्रकार की यादों तक पहुंचने वाला 1 मॉड्यूल है)।

यह धागा लंबा हो रहा है, ऐसा लगता है कि यह अभिसरण कर रहा है लेकिन 100% सुनिश्चित होने के लिए हमें उस कोड को लिखना होगा जिसे हम अलग-अलग उपयोगकर्ताओं से लिखने की अपेक्षा करते हैं:

1. एकल मॉड्यूल का एसिंक्स इंस्टेंटेशन।
2. अन्य मॉड्यूल के साथ मेमोरी शेयरिंग के साथ एक मॉड्यूल का एसिंक्स इंस्टेंटेशन।
3. एकल मॉड्यूल का सिंक्रोनस इंस्टेंटेशन (मुझे नहीं लगता कि सिंक्रोनस मल्टी-मॉड्यूल उपयोगी है?)
4. इन सभी के लिए कैशिंग (दोनों कैश में डालना, साथ ही मेमोरी के साथ पुनर्प्राप्त करना और तत्काल करना)।
5. एक एकल .wasm मॉड्यूल का अद्यतन, और अन्य मॉड्यूल के कैश्ड लोड।

और कुछ? ऐसा लगता है कि @lukewagner के पास आयात के समझता ।

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

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

@mtrofin राइट, Module m , आप WebAssembly.instantiate(m) कॉल करेंगे जो एसिंक है। आप new Instance(m) कॉल कर सकते हैं और यह महंगा हो सकता है, लेकिन यह new Module(m) से अलग नहीं है।

@jfbastien यह मानते हुए कि जब आप "async

1. WebAssembly.instantiate(bytecode, imports)
2. WebAssembly.instantiate(bytecode, imports) , जहां imports में साझा मेमोरी शामिल है
3. new Instance(new Module(bytecode), imports)
4. सभी मामलों में आप Module प्राप्त कर सकते हैं, फिर आप put वह IDBObjectStore । बाद में, आप get a Module m वापस और WebAssembly.instantiate(m, imports) कॉल करें।
5. यहां वास्तव में कुछ खास नहीं है: आप WebAssembly.instantiate बाइटकोड से एक मॉड्यूल और instantiate बाकी Module से आईडीबी से खींचे गए हैं।

यदि आपको लगता है कि आप सिंक कंपाइल का उपयोग कर सकते हैं, और यदि आपको लगता है कि आपको एसिंक्स कंपाइल का उपयोग करना चाहिए, तो क्या हमें सिंक इंस्टेंटिएट का उपयोग करने की सलाह देनी चाहिए?

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

@mtrofin 99% जो डेवलपर्स लिखेंगे (या WebAssembly.instantiate । यदि आप कुछ कोड साझाकरण प्रणाली लिख रहे हैं तो आप केवल विशेष "मैं एक जेआईटी लिख रहा हूं" और WebAssembly.compile लिए सिंक एपीआई का उपयोग करेंगे, इसलिए मुझे लगता है कि "आरंभ करना" ट्यूटोरियल विशेष रूप से WebAssembly.instantiate कवर करेगा

@lukewagner मैंने देखा है कि आपने ऊपर # 3 नए मॉड्यूल() में आयात जोड़ा है। मुझे लगता है कि इसे WebAssembly.compile में जोड़ना एक अच्छा विचार है और संभावनाओं को पूरा करता है।
इस तरह यदि आप संकलन समय पर स्मृति के बारे में संकेत देना चाहते हैं तो आप कर सकते हैं।
यदि आप बाद में अलग-अलग आयातों के साथ फिर से त्वरित करते हैं, विशेष रूप से समकालिक रूप से, तो आपको हिचकी आ सकती है।

तो परिवर्तनों का सारांश (बस इतना मैं स्पष्ट हूँ):

• Add WebAssembly.instantiate(bytes, imports) रिटर्न का वादा {instance:, मॉड्यूल:}
• Add WebAssembly.instantiate(module, imports) रिटर्न का वादा {instance:, मॉड्यूल:}
• नए मॉड्यूल में बदलें (बाइट्स , आयात ) रिटर्न मॉड्यूल
• WebAssembly.compile में बदलें (बाइट्स , आयात ) उदाहरण का वादा लौटाता है

कहीं उम्मीद है कि संकलन मैच से आयात तत्काल होने पर तत्काल तेज हो जाएगा।

डब्ल्यूडीवाईटी?

ओह ओह, मेरा मतलब आयात को Instance एक तर्क के रूप में रखना था। मुझे विश्वास नहीं है कि यह Module या compile । [संपादित करें: क्योंकि अगर आपके पास वे थे, तो आप बस instantiate कॉल करेंगे]

तो इसका मतलब यह होगा कि एंड-टू-एंड एसिंक केस के लिए, आप जान सकते हैं कि आप 4GB हैक मेमोरी के लिए बाध्यकारी होंगे, लेकिन JITed फ़िल्टर कर्नेल या पृष्ठभूमि संकलित आइटम के लिए नहीं (जब तक कि आप थ्रो- दूर उदाहरण)?

+1 संकलन और तत्काल की एसिंक जोड़ी पर मार्गदर्शन पर ध्यान केंद्रित करने पर - संदेश को सरल बनाता है और डेवलपर से निर्णय समस्या की जटिलताओं को छुपाता है।

हाँ, मुझे लगता है कि हम सभी इस बात से सहमत हैं कि हम लोगों को यहाँ इंगित करेंगे:
पहली बार:
WebAssembly.instantiate(बाइट्स, आयात) -> {मॉड्यूल, इंस्टेंस} का वादा (कैश मॉड्यूल से indexeddb)
दूसरी बार:
WebAssembly.instantiate(मॉड्यूल, आयात) -> {मॉड्यूल, उदाहरण} का वादा

मुख्य पैटर्न होने पर कोई आपत्ति?

मैं संकलन/नए मॉड्यूल के लिए आयात पर फटा हुआ हूं। ऐसा लगता है कि यह एक उपयोगी संकेत हो सकता है।
हालांकि, मैं इसे एक संभावना के रूप में उल्लेख करने और पोस्ट-एमवीपी में उस तर्क (यह वैकल्पिक हो सकता है) को जोड़ने के लिए तैयार हूं।

विचार?

@mtrofin (ठीक है, तकनीकी रूप से, बस instantiate ।)

@lukewagner (मुझे लगता है कि @mtrofin का मतलब यही है)

@lukewagner , @flagxor ठीक है, लेकिन हम async संकलन API रख रहे हैं, है ना?

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

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

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

हां, संकलन के लिए Memory पास करना संभव (यहां तक ​​​​कि प्रोत्साहित) होना चाहिए।

@mtrofin राइट, compile उन्नत उपयोगों के लिए। मुझे लगता है कि प्लगइन उदाहरण एक वैध मामला है जहां आप _compile_, _and_ चाहते हैं, आपके पास Memory , लेकिन आप तत्काल (अभी तक) नहीं चाहते हैं।

@pizlonator Btw, मेरा मतलब पहले पूछना था, "थ्रो अगर प्रति प्रक्रिया 1000 से अधिक 4 instantiate एपीआई निश्चित रूप से हमारे द्वारा बताए गए अन्य कारणों से जोड़ने के लिए उपयोगी प्रतीत होते हैं।)

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

बफर-एट-जीरो ऑप्टिमाइज़ेशन भी है जिसका कुछ रनटाइम लाभ उठाना चाहते हैं, और प्रति प्रक्रिया केवल एक ऐसा बफर होने वाला है।

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

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

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

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

@lukewagner मुझे ऐसा लगता है, क्योंकि अगर हम 1000 मॉड्यूल तक सीमित हैं, तो मुझे चिंता होगी कि सहनशीलता काफी बड़ी नहीं है।

• मुझे एक हमले के सामने आने की चिंता होगी जिसके लिए इस छत को नीचे जाने की आवश्यकता थी।
• मैं स्टैक में कहीं और अनुकूलन के बारे में चिंता करता हूं जो हमारे लिए उपलब्ध वर्चुअल एड्रेस स्पेस की मात्रा को कम करता है, जिसके बाद हमें यह पुनर्मूल्यांकन करने की आवश्यकता होगी कि क्या छत काफी कम है।
• मैं प्रोग्रामिंग शैलियों को रोकने के बारे में चिंता करता हूं जो जानबूझकर हजारों मॉड्यूल बनाते हैं। उदाहरण के लिए, मुझे पता है कि अधिकांश जावास्क्रिप्टकोर फ्रेमवर्क क्लाइंट वीएम बनाते हैं, थोड़ा सा काम करते हैं, और फिर इसे नष्ट कर देते हैं। यदि WebAssembly का उपयोग JS से उसी तरह किया जाता है जैसे JSC ऑब्जेक्टिव-सी से होता है, तो इसे 64-बिट सिस्टम पर काम करने के लिए GC को यह जानना होगा कि यदि आप 1000 मेमोरी आवंटित करते हैं - भले ही प्रत्येक छोटी थी - तो आपको करना होगा जीसी यदि अगला आवंटन इस आधार पर सफल होना चाहिए कि वे 1000 यादें अब पहुंच योग्य नहीं हैं। गैर-4GB-हैक यादों को आवंटित करने की क्षमता के बाद, कहते हैं, 10 4GB-हैक यादें लाइव हैं, इसका मतलब यह होगा कि GC को अपने अनुमानों को बहुत अधिक नहीं बदलना होगा। जब आप अपने तत्काल-> रन-> डाई लूप में 1001 वां मॉड्यूल आवंटित करते हैं तो इसे जीसी नहीं करना पड़ेगा। यह उन पैटर्नों के लिए एक लाभ होगा जो एक छोटी मेमोरी का उपयोग करते हैं। 1 एमबी से कम कुछ भी, और उनमें से 1000 होने का कोई मतलब नहीं है। मैं कल्पना कर सकता हूं कि लोग 64KB में उपयोगी चीजें कर रहे हैं।
• मुझे चिंता है कि यह अन्य जावास्क्रिप्ट संदर्भों के लिए कम उपयोगी होगा। मैं JSC C API और Objective-C API क्लाइंट के लिए अपने JS कोड से WebAssembly API तक पहुंच के लिए दरवाजा खुला छोड़ना चाहता हूं। वे ग्राहक शायद हमारे द्वारा आवंटित 4GB मेमोरी की संख्या पर एक छोटी सी सीमा पसंद करेंगे। ऐसे संदर्भ में उस कोटा को विन्यास योग्य बनाना भी आकर्षक है।

मुझे यह पसंद है कि बेहतर एपीआई यादों की संख्या, या पुन: संकलित करने की आवश्यकता, या अन्य अवांछित चीजों पर कृत्रिम छत की आवश्यकता को हटा देता है। मुझे कृत्रिम छत पसंद नहीं है जब तक कि सहनशीलता बहुत बड़ी न हो, और मुझे नहीं लगता कि यहां ऐसा है।

@pizlonator मेला पर्याप्त है, और यह एक क्लीनर/सरल एपीआई है, इसलिए मुझे लगता है कि इसे जोड़ना ठीक है।

इस बारे में कि मुझे उन वस्तुओं से कोई सरोकार क्यों नहीं है जिनका आपने उल्लेख किया है (इस समय):

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

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

मुझे लगता है कि जेएस एपीआई (विशेष रूप से आर्किटेक्चर/प्लेटफॉर्म विशिष्ट विवरण) में बहुत अधिक कार्यान्वयन विवरण को सतह पर लाने का प्रयास करना एक बुरा विचार है। मुझे लगता है कि कार्यान्वयन के लिए तेज स्मृति के लिए अपनी आंतरिक सीमाएं रखने के लिए पर्याप्त होना चाहिए।

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

शुक्र, अक्टूबर 28, 2016 को 2:15 AM पर, जेएफ Bastien [email protected]
लिखा था:

हां, मेमोरी को पास करना संभव (यहां तक ​​​​कि प्रोत्साहित) होना चाहिए
संकलन

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

-

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

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

तो इस मुद्दे को हल करने के लिए क्या करना बाकी है? एक बात http://webassembly.org/getting-started/js-api को अपडेट करना होगा, जो मैं कर सकता हूं। दूसरा बाइनरीन के लिए डिफ़ॉल्ट रूप से इसे उत्सर्जित करने के लिए होगा (ध्वनि अच्छा @kripken?) @titzer कैनरी लागू करता है WebAssembly.instantiate ?

और कुछ?

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

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

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

@kripken मुझे यकीन नहीं है कि मैं समझता हूं: वर्तमान दृष्टिकोण कोई एसिंक एपीआई का उपयोग नहीं करना है?

हाँ । async सामान जोड़ने के लिए यह समस्या देखें।

@kripken नोड में काम करने के वादे होंगे, मुझे लगता है। यहां तक ​​​​कि गोले के पास वादा कतार को स्पष्ट रूप से निकालने का एक तरीका है (और इस प्रकार सभी प्रस्तावों को समकालिक रूप से निष्पादित करें); SM में यह drainJobQueue() और V8 में मैंने सुना है कि एक %RunMicroTasks() । ऐसा लगता है कि आप केवल परीक्षण WebAssembly.instantiate सुविधा दे सकते हैं और डिफ़ॉल्ट रूप से उपस्थित होने पर इसका उपयोग कर सकते हैं।

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

उन दोनों के परिणामस्वरूप, जैसा कि पहले उल्लेख किया गया है, हम HTML उत्सर्जित करते समय Promise API का उपयोग कर सकते हैं (तब आप निश्चित रूप से शेल में नहीं हैं, और लोडिंग पर नियंत्रण रखते हैं), लेकिन JS उत्सर्जित करते समय नहीं। वहां हम केवल इसे दस्तावेज कर सकते हैं।

क्या नोड में ऐसे संस्करण हैं जो WebAssembly का समर्थन करते हैं लेकिन वादा नहीं करते हैं? क्या नोड लोग इन संस्करणों की परवाह करते हैं?

मैं स्ट्रेटलाइन JS चीज़ को नहीं समझता। यदि आप हमेशा एक वादा वापस करते हैं, तो क्या वह काम नहीं करेगा (कोड के उपयोगकर्ताओं को वादे का उपभोग करने की आवश्यकता है)?

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

स्ट्रेटलाइन इश्यू के बारे में: emcc JS को उत्सर्जित करता है जो रनटाइम सेट करता है और संकलित कोड से जुड़ता है। स्क्रिप्ट टैग में कुछ JS इसके ठीक बाद उस संकलित कोड में कॉल कर सकते हैं, उदाहरण के लिए ccall का उपयोग

WebAssembly के साथ IMO नोड लेकिन वादों के बिना एक डिज़ाइन बाधा नहीं है जिसके बारे में हमें चिंता करनी चाहिए। उस संदर्भ में WebAssembly के लिए एक पॉलीफ़िल बहुत मूर्खतापूर्ण है।

आप वर्णन कर रहे हैं कि कोड आज क्या करता है। मैं इसे पूरी तरह से नहीं समझता, लेकिन मैं बैक अप लेना चाहता हूं: मैं चाहता हूं कि वेब पेजों पर कोड प्रॉमिस एपीआई का उपयोग करे। एम्सस्क्रिप्टन ऐसे कोड का निर्माता है। मुझे समझ में नहीं आता कि वादों का उपयोग करने वाले कोड को उत्सर्जित करने से क्या रोक रहा है। मैं पूरी तरह से ठीक हूँ यदि आप कहते हैं "यह महत्वपूर्ण काम है क्योंकि आज यह काम नहीं करता है, लेकिन हम इसे प्राप्त करेंगे"। लेकिन हमारी चर्चा से मुझे यकीन नहीं है कि आप यही कह रहे हैं।

क्या आप केवल कैशिंग के लिए async API का उपयोग करने के बारे में बताते हैं? यह एक शुरुआत है जो मुझे लगता है, लेकिन मैं जिस एंडस्टेट को प्राप्त करना चाहता हूं वह वह जगह है जहां पहले लोड पर भी एसिंक एपीआई का उपयोग किया जाता है।

वासम के लिए पॉलीफिल नोड पर मूर्खतापूर्ण क्यों है? अभी भी उस संदर्भ में उपयोगी लगता है, भले ही अन्य मामलों की तुलना में कम हो :)

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

क्या यह आपकी चिंताओं को दूर करता है?

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

````

````

doSomething Module.my_func को अस्तित्व में रहने के लिए output.js सिर्फ एक वादा लौटाया है, तो यह अभी तक मौजूद नहीं है। तो यह एक तोड़ने वाला बदलाव होगा।

क्या यह अब समझ में आता है?

वासम के लिए पॉलीफिल नोड पर मूर्खतापूर्ण क्यों है? अभी भी उस संदर्भ में उपयोगी लगता है, भले ही अन्य मामलों की तुलना में कम हो :)

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

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

क्या यह आपकी चिंताओं को दूर करता है?

ठीक है ये अच्छा है! जब तक अधिकांश वेब पेज प्रॉमिस एपीआई का उपयोग करते हैं, मुझे खुशी है।

[स्निप]

क्या यह अब समझ में आता है?

हां। समझाने के लिए धन्यवाद।

हालांकि मेरे पीओवी से, एम्सस्क्रिप्टन सिर्फ जेएस उत्सर्जित करने के व्यवसाय में नहीं है! आपका उदाहरण ये ओल्डन कोड के लिए समझ में आता है, लेकिन नई सामग्री को आईएमओ के वादे मानना ​​​​चाहिए।

बीटीडब्ल्यू, मैंने instantiate का उपयोग करने के लिए webassembly.org/demo स्विच करने पर ध्यान दिया और यह थोड़ा मुश्किल बी/सी वर्तमान सिंक्रोनस new Instance एक ऐसे संदर्भ में होता है जो एक सिंक्रोनस परिणाम चाहता है। इसलिए एक बार जब हम बाइनरीन को डिफ़ॉल्ट रूप से instantiate उत्सर्जित करने के लिए अपडेट कर लेते हैं, तो एंग्रीबॉट्स डेमो को स्क्रैच से फिर से बनाना अच्छा होगा।

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

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

WebAssembly.instantiate API का उपयोग न करने की संभावित कमियों को देखते हुए, मुझे लगता है कि उन्हें इसका उपयोग करने पर विचार करने के लिए कहना उचित है।

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

मैंने अभी इस लंबे मुद्दे को स्वयं स्किम किया है, और मैं अभी तक डाउनसाइड्स पर स्पष्ट नहीं हूं, इसलिए मैं इसे भी पढ़ना चाहता हूं :)

@kripken वर्तमान कोड के साथ चुनौती यह है कि बाइनरीन/एमस्क्रिप्टन केवल आवश्यक आयात प्रदान करता है ( instantiate लिए तर्क के रूप में आवश्यक) उसी समय जब निर्यात समकालिक रूप से आवश्यक होते हैं। यदि आयात को "अप फ्रंट" उपलब्ध कराया जा सकता है, तो एसिंक एक्सएचआर की पूंछ के लिए WebAssembly.instantiate से निपटने के लिए यह काफी छोटा है (जैसा कि मैंने वर्तमान डेमो में एसिंक compile )। इसलिए मुझे नहीं लगता कि इसके लिए एकता की ओर से अधिक काम करने की आवश्यकता होगी। इसके अलावा, जो मैंने देखा है , उससे हमारा वर्तमान एंग्रीबॉट्स वासम बिल्ड सबऑप्टिमल है और इसे वैसे भी ताज़ा करने की आवश्यकता है।

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

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

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

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

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

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

निर्यात-उपयोग कोड को कॉलबैक में डालने के बारे में, दुख की बात है कि यह केवल पहले बताए गए कारणों के लिए काम नहीं करेगा, लेकिन हम कुछ नए संकलन मोड को जोड़कर उन मापों के हिस्से के रूप में जांच कर सकते हैं।

instantiate का हस्ताक्षर WebAssembly.instantiate(bytes, importObj) , इसलिए एसिंक्स कंपाइल+इंस्टेंट को बंद करने के लिए, आपको importObj ।

ऑफ़लाइन बात करते हुए,

1. संकलन करते समय मेमोरी प्रदान करना।
2. संकलन करते समय सभी आयात प्रदान करना (पिछले का सुपरसेट)।
3. यह सब अतुल्यकालिक रूप से करना।

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

लेकिन कुछ अन्य विकल्पों का उपयोग करना बहुत आसान है:

• 1 + 3 के लिए instantiate(bytes, Memory) -> Promise जैसे नए API की आवश्यकता होगी। इसका उपयोग करना आसान होने का कारण यह है कि मेमोरी को किसी भी तरह जल्दी बनाया जा सकता है (जबकि लगभग सभी अन्य आयात जेएस फ़ंक्शन हैं, जिन्हें हम जल्दी नहीं कर सकते हैं)।
• 2 अपने आप में, 3 के बिना, यानी new Instance(bytes, imports) । यानी बाइनरी डेटा + इंपोर्ट पर सिंक्रोनस कंपाइलेशन। इसका उपयोग करना आसान होने का कारण यह है कि हमारा वर्तमान कोड यह करता है: instance = new WebAssembly.Instance(new WebAssembly.Module(getBinary()), imports) इसलिए हम इसे केवल 1 API कॉल में बदल देंगे।

मुझे लगता है कि अंतिम विकल्प समझ में आता है। इसका मूल रूप से अर्थ है नए एपीआई का एक सिंक संस्करण जोड़ना, हमारे मौजूदा सिंक्रोनस संकलन विकल्प के साथ चीजों को और अधिक सममित बनाना। और मुझे एसिंक्रोनस संकलन के लिए संकलन समय पर मेमोरी को जानने के नए अनुकूलन को जोड़ने का कोई कारण नहीं दिख रहा है? (async बहुत अच्छा है, लेकिन एक अलग मुद्दा है?)

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

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

यह कुछ ऐसा सुझाव दिया जा रहा है जो कई साल पहले इस परियोजना की शुरुआत के आसपास आवश्यक था!

@kripken जबकि सिंक एपीआई हैं, मेरा मानना ​​​​है कि तकनीकी रूप से जरूरी है, वे निश्चित रूप से अनुशंसित पथ नहीं होना चाहिए अन्यथा हम अनावश्यक मुख्य-थ्रेड जंक, एएसएम की तुलना में एक रिग्रेशन पेश करेंगे। जेएस +

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

आइए ज़ूम आउट करें और एक सेकंड के लिए उपयोगकर्ता अनुभव के बारे में बात करें।

यहां एंग्रीबॉट्स डेमो को एसिंक्रोनस (asm.js के माध्यम से), बाएं, और सिंक्रोनस (V8 में WebAssembly के माध्यम से), दाएं लोड करने के बीच तुलना की गई है।

सिंक्रोनस संकलन एक भयानक उपयोगकर्ता अनुभव प्रदान करता है और प्रगति सलाखों या एप्लिकेशन लोडिंग के किसी अन्य दृश्य संकेत को तोड़ता है।

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

हमें WebAssembly.compile और WebAssembly.instantiate को स्पष्ट रूप से प्रोत्साहित करने और new WebAssembly.Module और new WebAssembly.Instance हतोत्साहित करने की आवश्यकता है।

आइए थोड़ा गहराई से देखें और देखें कि WebAssembly के लिए दाईं ओर प्रगति पट्टी कितनी खराब है।

DevTools प्रदर्शन पैनल के साथ कैप्चर किया गया एक ट्रेस यहां दिया गया है:

मेरे मैकबुक एयर पर किसी भी प्रगति पट्टी को दिखाने में 30 सेकंड लगते हैं।

उस समय क्या लगता है? जब मुख्य धागा पूरी तरह से बंद हो जाता है, तो wasm मॉड्यूल डाउनलोड होने के बाद ~ २० में ज़ूम करें:

संकलन ~ 20s ले रहा है और तत्कालता ~ 2s ले रही है।

ध्यान दें कि इस मामले में, यूनिटी लोडर पहले से ही एसिंक्रोनस WebAssembly.compile कॉल कर रहा है यदि यह समर्थित है, तो 20s इसलिए है क्योंकि V8 अभी भी हुड के नीचे एक सिंक्रोनस संकलन करता है। cc @titzer @flagxor यह कुछ ऐसा है जिसे V8 को वास्तव में ठीक करने की आवश्यकता है।

2s इंस्टेंटेशन जंक एकता लोडर कोड को सिंक्रोनस कॉल करने के कारण है new WebAssembly.Instance । यह वही है जो हमें वास्तव में एकता कोड और एम्सस्क्रिप्टन दोनों में ठीक करने की आवश्यकता है।

मुझे लगता है कि यह भी ध्यान देने योग्य है कि यह _merely_ एक डेवलपर के पैर में खुद को गोली मारने का जोखिम नहीं है या नहीं। औसत वेब पेज में दर्जनों तृतीय पक्ष स्क्रिप्ट शामिल हैं: उन सभी लिपियों में शीर्ष-दस्तावेज़-जंकिंग WebAssembly को शामिल करने की क्षमता है।

(यदि आप ट्रेस को अधिक विस्तार से देखना चाहते हैं तो आप यहां पूरी टाइमलाइन देख सकते हैं: https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://www.dropbox.com/s/ noqjwql0pq6c1wy/wasm?dl=0)

मैं 100% सहमत हूं कि एसिंक बहुत अच्छा है :) लेकिन मैं कह रहा हूं कि यह मॉड्यूल को संकलित करने के साथ ही मेमोरी प्राप्त करने के अनुकूलन के लिए ऑर्थोगोनल है। और यह कि हम तुच्छ रूप से async + उस अनुकूलन को प्राप्त नहीं कर सकते हैं - हम उस कॉम्बो को प्राप्त कर सकते हैं, लेकिन या तो कुछ ओवरहेड की कीमत पर, या समय के लिए यदि हम इसके लिए एक नया ध्वज पेश करते हैं और इसे डिफ़ॉल्ट होने के लिए चरणबद्ध करने का एक तरीका ढूंढते हैं .

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

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

@kripken मुझे लगता है कि आप I, @lukewagner और @ s3ththompson की तुलना में अलग निष्कर्षों पर आते हैं क्योंकि आपके लिए सबसे महत्वपूर्ण हिस्सा मौजूदा डेवलपर्स के लिए asm.js से एक सहज संक्रमण की पेशकश करना है।

क्या यह सही है?

मैं सहमत हूं कि यह एक वैध चिंता है। मैं इसे कम करता हूं क्योंकि IMO WebAssembly के साथ हम asm.js की तुलना में अधिक डेवलपर्स ला रहे हैं। मैं जल्दी अपनाने वालों को जलाने से बचना चाहता हूं, लेकिन आईआईयूसी के मौजूदा डेवलपर्स काफी लचीले हैं और एसिंक्रोनस संकलन चाहते हैं ।

अगर हम मानते हैं कि वे एसिंक्रोनस संकलन चाहते हैं, और इसे प्राप्त करने के लिए कुछ को दोबारा करने के इच्छुक हैं, तो जो कुछ बचा है वह संकलन समय पर स्मृति है, जो कि यह एपीआई प्रदान करता है। यह अत्यधिक वांछनीय है क्योंकि यह एक नुकसान से बचता है।

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

FWIW, Unity 5.6 WebAssembly.instantiate का उपयोग करेगा।

जोनास

28 दिसंबर 2016 को रात 11:42 बजे सेठ थॉम्पसन ने नोटिफिकेशन @github.com पर लिखा:

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

आइए ज़ूम आउट करें और एक सेकंड के लिए उपयोगकर्ता अनुभव के बारे में बात करें।

यहां एसिंक्रोनस कॉल (asm.js के माध्यम से), लेफ्ट और सिंक्रोनस कॉल्स (वर्तमान WebAssembly कार्यान्वयन) के साथ एंग्रीबॉट्स डेमो लोड करने के बीच तुलना की गई है।

सिंक्रोनस संकलन एक भयानक उपयोगकर्ता अनुभव प्रदान करता है और प्रगति सलाखों या एप्लिकेशन लोडिंग के किसी अन्य दृश्य संकेत को तोड़ता है।

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

हमें स्पष्ट रूप से WebAssembly.compile और WebAssembly.instance को प्रोत्साहित करने और नए WebAssembly.Module और नए WebAssembly.Instance को हतोत्साहित करने की आवश्यकता है।

आइए थोड़ा गहराई से देखें और देखें कि WebAssembly के लिए दाईं ओर प्रगति पट्टी कितनी खराब है।

DevTools प्रदर्शन पैनल के साथ कैप्चर किया गया एक ट्रेस यहां दिया गया है:

मेरे मैकबुक एयर पर किसी भी प्रगति पट्टी को दिखाने में 30 सेकंड लगते हैं।

उस समय क्या लगता है? जब मुख्य धागा पूरी तरह से बंद हो जाता है, तो wasm मॉड्यूल डाउनलोड होने के बाद ~ २० में ज़ूम करें:

संकलन ~ 20s ले रहा है और तत्कालता ~ 2s ले रही है।

ध्यान दें कि इस मामले में, यूनिटी लोडर पहले से ही एसिंक्रोनस WebAssembly.compile को कॉल कर रहा है, अगर यह समर्थित है, तो 20s इसलिए है क्योंकि V8 अभी भी हुड के नीचे एक सिंक्रोनस कंपाइल करता है। cc @titzer @flagxor यह कुछ ऐसा है जिसे V8 को वास्तव में ठीक करने की आवश्यकता है।

2s इंस्टेंटेशन जंक सिंक्रोनस नए WebAssembly.Instance को कॉल करने वाले यूनिटी लोडर कोड के कारण है। यह वही है जो हमें वास्तव में एकता कोड और एम्सस्क्रिप्टन दोनों में ठीक करने की आवश्यकता है।

मुझे लगता है कि यह भी ध्यान देने योग्य है कि यह केवल एक डेवलपर के पैर में खुद को गोली मारने का जोखिम नहीं है या नहीं। औसत वेब पेज में दर्जनों तृतीय पक्ष स्क्रिप्ट शामिल हैं: उन सभी लिपियों में शीर्ष-दस्तावेज़-जंकिंग WebAssembly को शामिल करने की क्षमता है।

(यदि आप ट्रेस को अधिक विस्तार से देखना चाहते हैं तो आप यहां पूरी टाइमलाइन देख सकते हैं: https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://www.dropbox.com/s/ noqjwql0pq6c1wy/wasm?dl=0)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@jfbastien शायद मुझे समझ में नहीं आता कि "निष्कर्ष" से आपका क्या मतलब है। मैं ज्यादातर यहां सिर्फ विकल्प पेश कर रहा हूं। मेरा खुद कोई निष्कर्ष नहीं है।

अगर हम अभी मेमोरी-एट-कंपाइल-टाइम ऑप्ट चाहते हैं, तो मैंने कुछ विकल्प प्रस्तावित किए हैं जो हमें इसे ASAP दे सकते हैं, हमारे वर्तमान सिंक संकलन को मामूली रूप से संशोधित कर सकते हैं।

या अगर हम चाहते हैं कि अब एक एसिंक तरीके से ऑप्ट करें, तो मैंने एक विकल्प ("1 + 3", यानी, संकलन समय पर सभी आयात प्राप्त नहीं करना, केवल मेमोरी) प्रस्तावित किया जो हमें इसे ASAP भी दे सकता है।

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

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

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

यह सुनिश्चित करने के लिए कि मैं समझता हूं:

1. ओवरहेड्स क्या हैं?
   
   
   
   • क्या ये ओवरहेड्स Async + मेमोरी-एट-कंपाइल-टाइम में निहित हैं, या क्या वे कार्यान्वयन बाधाएं हैं जिन्हें बाद में ठीक किया जा सकता है? आईएमओ अगर वे ए + एम के निहित हैं तो हमें एपीआई एएसएपी को ठीक करना चाहिए।
   
   
   • IIUC ओवरहेड्स या तो आयात या निर्यात पर एक अस्थायी चीज है, और A+M में निहित नहीं है, क्या यह सही है? क्या आप इसे थोड़ा और विस्तार से बता सकते हैं?
   
   
2. हम किन उपयोगकर्ताओं को तोड़ने की बात कर रहे हैं? asm.js उपयोगकर्ता जो समान कोड को भी wasm को लक्षित करना चाहते हैं?

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

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

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

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

यह आकस्मिक लगता है और ऐसा कुछ नहीं है जिसे हमें हमेशा के लिए एपीआई के साथ सेंकना चाहिए। इसके अलावा, कारणों के लिए @ s3ththompson ने समझाया, यहां तक ​​​​कि स्मृति-पर-संकलन-समय के मुद्दे को अनदेखा करते हुए, हमें वैसे भी एसिंक होने के लिए @jfbastien से सहमत

उपयोगकर्ताओं को तोड़ने के बारे में: यदि हम एक सरल माइग्रेशन पथ (जैसे "ऑनलोड" ईवेंट/वादा) प्रदान करते हैं, तो उपयोगकर्ताओं के लिए माइग्रेट करना आसान होना चाहिए, गाजर सभी प्रमुख पूर्ण जीत हैं। मुझे नहीं लगता कि हमारे पास कोई सबूत है कि सटीक asm.js स्रोत backcompat डिफ़ॉल्ट कॉन्फ़िगरेशन के लिए एक कठिन आवश्यकता है; हमारे पास बिल्कुल विपरीत के कई उदाहरण हैं: उपयोगकर्ता जो कुछ भी करने को तैयार हैं, वह है, निश्चित रूप से, संपूर्ण बिंदु।

@lukewagner ऑफ़लाइन से बात करते

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

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

@jfbastien : ज़रूर। मैं अभी तक स्पष्ट नहीं हूं कि आप आरेख में क्या खोज रहे हैं, लेकिन हाँ, शायद कोई अन्य स्थान बेहतर है। एमस्क्रिप्टन में इसे लागू करने के लिए पहले उल्लेख किया गया मुद्दा है, https://github.com/kripken/emscripten/issues/4711 , अगर आप जो चाहते हैं उसे कवर नहीं करते हैं तो एक और खोलने के लिए स्वतंत्र महसूस करें।

IIUC Emscripten अब डिफ़ॉल्ट रूप से इसका उपयोग करता है। समापन।

@s3ththompson टिप्पणी पर अनुवर्ती कार्रवाई के लिए, ध्यान दें कि तुल्यकालिक संकलन और तात्कालिकता उपयोगी है। विशेष रूप से, मैं हाल ही में एक ऐसी स्थिति में आया था जहाँ मैं Node.js ( v7.7.2 ) में एक WebAssembly मॉड्यूल को सिंक्रोनस रूप से लोड और संकलित करना चाहता था। अगर केवल एपीआई जो वादे लौटाते हैं, उपलब्ध हैं, तो इसका मतलब है कि मैं एक सिंक्रोनस निर्यात प्रदान करने में असमर्थ हूं।

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

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

@ s3ththompson स्पष्टीकरण के लिए धन्यवाद।