Design: क्या कोई JS -> WASM कंपाइलर होगा?

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

wasm कोड से GC तक पहुंच जोड़ने जैसी चीजों को जोड़ने के लिए एक कार्य पोस्ट MVP है ताकि स्क्रिप्टिंग भाषाओं को wasm के लिए लागू किया जा सके।

JS → wasm वास्तव में केवल तभी समझ में आएगा जब wasm GC का समर्थन करता है, और सबसे अधिक संभावना JIT संकलन भी है, जो अभी भी काफी दूर है। यह मूल रूप से JS इंजन को wasm में लागू करने के बराबर होगा! मैंने हाल ही में इसका उल्लेख किया और @BrendanEich ने मुझ पर हॉर्स_जेएस द्वारा कब्जा करने का आरोप लगाया।

स्पष्ट होने के लिए, wasm का लक्ष्य _replace_ JavaScript नहीं है, यह इसे पूरक करना है। इसलिए JS → wasm का समर्थन करना इस समय वास्तव में एक लक्ष्य नहीं है, लेकिन जिन सुविधाओं को हम लागू करना चाहते हैं, वे इसे संभव बना देंगी। मुझे यकीन नहीं है कि यह डेवलपर के परिप्रेक्ष्य से उपयोगी होगा, हालांकि। आपको कुछ आकार में कमी मिल सकती है, लेकिन यह इसके बारे में है। ब्राउज़र के दृष्टिकोण से, शुद्ध सुरक्षा के दृष्टिकोण से JS इंजन को wasm में लागू करना दिलचस्प हो सकता है।

@jfbastien मैंने आपको 2 सेकंड से हराया;)

लेकिन आपका जवाब बेहतर है। मैं wasm में GC और JIT के लिए उत्साहित हूं। मुझे अपनी भाषाएँ बनाना और उन्हें वेब पर चलाना पसंद है।

और asm.js या टाइपस्क्रिप्ट/ES7 जैसे वेरिएंट को सपोर्ट करने के बारे में क्या? इन
जावास्क्रिप्ट के फ्लेवर कुछ स्तर की गारंटी का वादा करते हैं।

मुझे लगता है कि जेआईटी की आवश्यकता कम होगी, लेकिन जीसी अभी भी बहुत अधिक है
इन भाषाओं के लिए आवश्यक एक {टाइप किया हुआ फ्लेवर JS} होगा -> WASM मेक
यह और अधिक संभव है?

डब्ल्यू: http://bguiz.com

24 जून 2015 को 09:44 बजे, टिम कैसवेल नोटिफिकेशन @github.com ने लिखा:

@jfbastien https://github.com/jfbastien आपने मुझे 2 सेकंड से हरा दिया:P

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456।

हाँ, एक asm.js -> wasm अनुवादक एक उच्च प्राथमिकता है, और ल्यूक ने पहले ही किया था
एक कंप्रेसर पर काम करें जो एक अच्छे शुरुआती बिंदु के रूप में काम कर सके।

बुधवार, 24 जून, 2015 पूर्वाह्न 1:59 बजे, ब्रेंडन ग्रेट्ज़ नोटिफिकेशन @github.com
लिखा था:

और asm.js या टाइपस्क्रिप्ट/ES7 जैसे वेरिएंट को सपोर्ट करने के बारे में क्या? इन
जावास्क्रिप्ट के फ्लेवर कुछ स्तर की गारंटी का वादा करते हैं।

मुझे लगता है कि जेआईटी की आवश्यकता कम होगी, लेकिन जीसी अभी भी बहुत अधिक है
इन भाषाओं के लिए आवश्यक एक {टाइप किया हुआ फ्लेवर JS} होगा -> WASM मेक
यह और अधिक संभव है?

डब्ल्यू: http://bguiz.com

24 जून 2015 को 09:44 बजे, टिम कैसवेल नोटिफिकेशन @github.com ने लिखा:

@jfbastien https://github.com/jfbastien आपने मुझे 2 सेकंड से हरा दिया:P

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789।

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

@bguiz : JS इंजन wasm इंजन है, और यह विकसित JS मानक भाषा का समर्थन करना जारी रखेगा। वहाँ कोई चिंता नहीं है (मुझे यकीन नहीं था कि क्या आपने सोचा था कि यह दूर हो सकता है। किसी भी भविष्य में नहीं जिसे मैं देख सकता हूं)। ओटीओएच, जैसा कि अन्य कहते हैं, जेएस के लिए प्रथम श्रेणी के लक्ष्य होने के लिए, जीसी, जेआईटी समर्थन और अन्य गतिशील भाषा सुविधाओं को विकसित करने के लिए wasm को समय चाहिए। यहां तक ​​​​कि जब यह इन चीजों को विकसित करता है, तो मुझे संदेह है कि JS/wasm इंजन अपने JS सिंटैक्स और बिल्ट-इन्स को JS-in-wasm VMs के पक्ष में छोड़ देंगे। हम देखेंगे!

/होना

एक asm.js-to-WebAssembly अनुवादक भी कुछ ऐसा होगा जिसे हम Emscripten में जोड़ने की योजना बना रहे हैं।

नियमित जेएस के लिए, मुझे लगता है कि दूसरों ने उपरोक्त प्रश्न का उत्तर दिया है।

JS का पूरा बिंदु कोड करना आसान है और अद्भुत चीजें कर सकता है: dhteumeuleu या codepen.io/ge1doot, लेकिन आप स्रोत देख सकते हैं और इसे हैक करना आसान है।

"wasm" Google, Apple a co के लिए अधिक गेम और अन्य ऐप्स बेचने का केवल एक तरीका है। केवल "विकास" यह है कि सीधे बड़े भाई सर्वर से "कोई इंस्टॉल नहीं" के साथ आपको बेहतर तरीके से नियंत्रित करने में सक्षम होंगे ... मुझे आश्चर्य है कि वे अभी तक एक-दूसरे को खाने से डरते नहीं हैं ...

ईसीएमएस्क्रिप्ट को WebAssembly में संकलित करने के लिए कोड विश्लेषण या कोड एनोटेशन के साथ यह संभव है। यह WebAssembly टीम के लिए प्राथमिकता की तरह नहीं लगता है, लेकिन यह एक स्वतंत्र प्रयास के लिए एक महान विचार की तरह लगता है।

मैंने अभी एक खिलौना प्रोग्रामिंग भाषा के साथ प्रयोग करना शुरू किया है जो प्रासंगिक हो सकती है: https://github.com/evanw/thinscript । यह टाइपस्क्रिप्ट-शैली सिंटैक्स का उपयोग करता है और WebAssembly को संकलित करता है। मुझे लगा कि मुझे इसका जिक्र करना चाहिए क्योंकि यह एक दिलचस्प केस स्टडी हो सकती है। इसके अलावा, मुझे सुखद आश्चर्य हुआ कि WebAssembly को उत्पन्न करना कितना आसान था। अच्छा काम सब लोग!

हालांकि, सामान्य तौर पर, मैं लोगों को वासम के ऊपर बहुत पतले रैपर का उपयोग करने के बारे में सावधान करूंगा। एक उदाहरण के रूप में, थिनस्क्रिप्ट कोड के माध्यम से, मुझे लगता है कि एक while स्टेटमेंट है जिसे कम करके loop { if (!condition) break; } , जो कि कई wasm इंजनों पर if (condition) loop { ...; br_if condition } से कम कुशल होगा।

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

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

बहुत अच्छा लगता है! मुझे यह देखने में दिलचस्पी होगी कि यह कहाँ जाता है।

मैं कल्पना कर रहा हूं कि JS-> WASM क्लाइंट की तुलना में सर्वर के लिए अधिक आकर्षक है। मेरे मन में वास्तुकला के एक बहुत ही उच्च स्तरीय अवलोकन के रूप में ...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

इस अवधारणा में, कचरा संग्रहण के लिए WASM से

बस कुछ विचार, कृपया बेझिझक इसे हटा दें यदि यह नकली है!

JS पारिस्थितिकी तंत्र में क्रॉस पर्यावरण अनुकूलता एक गंभीर समस्या है। बैबेल इस समस्या को ES के कुछ और स्वीकृत संस्करण में स्थानांतरित करके हल करने का प्रयास करता है और मुझे लगता है कि हम सभी कह सकते हैं कि यह बहुत सफल है।

हालांकि यहां अभी भी एक मुद्दा है। उदाहरण के लिए, यदि आप संगतता के लिए अपने ES 2016 कोड को ES5 तक ट्रांसपिल कर रहे हैं और आपका कोड ES 2016 समर्थन वाले (आंशिक या पूर्ण) वातावरण पर चलता है, तो आप अपने वातावरण में ES 2016 समर्थन होने के लाभों को याद कर रहे होंगे। .

अगर हर कोई अपने कोड को ES5 तक ट्रांसपाइल कर रहा है, तो सबसे पहले वातावरण में ES 2016 समर्थन होने का क्या लाभ है?

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

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

एकमात्र समाधान जावास्क्रिप्ट के लिए एक नया संकलन लक्ष्य है जो प्रदर्शनकारी है और जेएस इंजन की तुलना में बहुत कम रखरखाव (उम्मीद है कि कोई नहीं) की आवश्यकता है। जब परिवेश (ब्राउज़र, Node.js, आदि) ऐसे लक्ष्य का समर्थन करना शुरू करते हैं, तो नई ES सुविधाओं को लागू करने की जिम्मेदारी कंपाइलर की होनी चाहिए न कि इंजन विक्रेताओं की।

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

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

हाय सब, मैंने अभी-अभी WebAssembly की खोज की है, लेकिन JS -> wasm कंपाइलर के बारे में सोचते हुए, मैंने Angular2 के अहेड-ऑफ-टाइम संकलन की तरह कुछ कल्पना की, जिस तरह से अधिक अनुकूलित (मैं जावास्क्रिप्ट के बजाय मशीनकोड सोच रहा हूं) ... क्या यह कभी संभव हो? क्या यह इस लायक है?

संपादित करें
मैं यह भी सोच रहा हूं, क्या ब्राउज़र के लिए क्लाइंट को ध्वज भेजने की संभावना होगी कि यह wasm का समर्थन करता है, और फिर हम जावास्क्रिप्ट फ़ाइल के बजाय प्रीकंपिल्ड ऐप की सेवा कर सकते हैं?

रिचर्ड

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

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

मुझे लगता है कि हममें से कुछ लोगों के लिए यह अत्यंत महत्वपूर्ण है जो ब्राउज़र और वेबग्ल को गेमिंग के लिए तेज़ होना चाहते हैं। मैं वेबग्ल में एक व्यावसायिक गुणवत्ता वाला गेम लाने का इरादा रखता हूं लेकिन वर्तमान तकनीक इतना कचरा पैदा करती है कि फ्रेम छोड़ देता है।
जेएस गेम इंजन का उपयोग करने वाला ब्राउज़र गेमिंग लगभग विफल हो गया है और एकता ने उड़ान भरी। मुझे लगता है कि C++ => Wasm इन बड़े यूनिटी जैसे फ्रेमवर्क निर्माताओं के लिए एक अनुचित लाभ है जो अपने कोड को WASM में संकलित कर सकते हैं।
लेकिन उन लोगों का क्या जो थ्री JS या बेबीलोन का उपयोग करके हाथ से JS लिखते हैं .. JS/Asm.js => Wasm टूलचेन न होने का मतलब होगा कि Js में बड़े एप्लिकेशन मर जाएंगे और लोग Wasm का उत्पादन करने के लिए C++ और कोड जनरेशन बैकएंड का उपयोग करेंगे। विशेष रूप से खेलों और ऐसे में।
JS डेवलपर्स के लिए अनुचित में JS => Wasm बैकएंड नहीं होना। इसके अलावा ईएमसीसी एक बड़ा ढेर आवंटित करता है जब यह चलता है और उसके कारण गति स्पष्ट होती है, लेकिन जेएस डेवलपर्स जो अच्छे जेएस कोड लिखते हैं, वे अभी भी इस तरह के कोड को लिखने की जटिलता के कारण इतना अधिक प्रदर्शन प्राप्त नहीं कर सके। अधिकांश सामान और जीसी को पहले या इच्छा पर कॉल करने की क्षमता का पुन: उपयोग करने के लिए कुछ तंत्र होना चाहिए। जब GC चलता है तो फ़्रेम छोड़ना एक बड़ी समस्या है और इसे हल करने की आवश्यकता है। कोड जेनरेटर की तुलना में जेएस कोड को बेहतर ढंग से ट्यून करने के लिए कुछ तंत्र होना चाहिए। जैसे हस्तलिखित असेंबली अभी भी बहुत छोटा और अत्यधिक संरेखित कोड उत्पन्न करती है। वेब-असेंबली में यह संभव होना चाहिए।

@metacritical C++ WASM को संकलित कर सकता है क्योंकि बहुत से लोग इस प्रक्रिया में बहुत काम करते हैं। जावास्क्रिप्ट के लिए भी ऐसा ही हो सकता है, लेकिन जहां तक ​​मुझे पता है, वर्तमान में कोई भी इसका प्रयास नहीं कर रहा है। ऐसा करने का कोई कारण नहीं है: प्रदर्शन अपरिवर्तित रहेगा।

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

अल्ट्रा प्रीस्टाइन जावास्क्रिप्ट जो Arrays का पुन: उपयोग करती है और कम कचरा उत्पन्न करती है, लिखना बेहद कठिन है। साथ ही मुझे लगता है कि सादा जेएस को WASM में संकलित नहीं किया जा सकता है। Asm.js या टाइपस्क्रिप्ट क्रमशः टाइप एनोटेशन या प्रकारों की उपलब्धता के कारण WASM को संकलित करना आसान होगा।

@metacritical मुश्किल है, लेकिन असंभव नहीं है। सी ++ इंजन में भी, अधिकांश कोड ऑब्जेक्ट लाइफटाइम मैनेजमेंट के आसपास होता है। हालांकि अपरंपरागत, ऐसा कोई कारण नहीं है कि आप जावास्क्रिप्ट में ऐसा नहीं कर सकते।

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

तुलना करके, ASM.JS को WASM में बदलना आसान होगा। ASM.JS द्वारा अनुमत JS सुविधाओं का सख्त सबसेट भी WASM द्वारा 100% कवर किया गया है। यदि ASM.JS में बड़ी मात्रा में कोड लिखा गया होता, तो यह एक सार्थक प्रयास होता, लेकिन जहाँ तक मुझे पता है सभी प्रमुख ASM.JS फ़ाइलें C++ स्रोत कोड से निर्मित होती हैं, जो पहले से ही सीधे WASM को लक्षित कर सकती हैं।

तुलना करके, ASM.JS को WASM में बदलना आसान होगा।

सही है, और वास्तव में आज हम जिस मुख्य तरीके से C++ को wasm में संकलित करते हैं, वह इसे पहले asm.js में संकलित करना है, फिर उस asm.js को wasm में Binaryen के asm2wasm का उपयोग करके संकलित करना है ।

@kripken asm.js स्पेक्स को देखते हुए हस्तलिखित asm.js लिखना आसान लगता है, जिसका अर्थ है कि js प्रोग्रामर के लिए सब कुछ खो नहीं गया है, हम अभी भी उपरोक्त का उपयोग करके WASM बायनेरिज़ प्राप्त कर सकते हैं।

क्या JS का विकास नहीं होगा यानी सख्ती से टाइप की गई भाषा, इसे JS -> WASM के लिए एक अच्छा उम्मीदवार बना सकती है?
मुझे लगता है कि TC39 में टाइप की गई वस्तु के लिए प्रस्ताव है। हो सकता है कि और अधिक सुविधाएं इसे संभव बना सकें।

@ aruns07 आप लोगों को

@Kardax @aruns07 लोग गतिशील भाषा की सुविधा को पसंद करते हैं। हमें कभी-कभी मजबूत प्रकार की आवश्यकता होती है, हर समय नहीं।

jfbastien ने जून 24, 2015 पर टिप्पणी की
JS → wasm वास्तव में केवल तभी समझ में आएगा जब wasm GC का समर्थन करता है, और सबसे अधिक संभावना JIT संकलन भी है, जो अभी भी काफी दूर है। यह मूल रूप से JS इंजन को wasm में लागू करने के बराबर होगा!

निम्नलिखित लिंक के अनुसार:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
WebAssembly की सहमति और ब्राउज़र पूर्वावलोकन का अंत

अब, आपके पहले उत्तर के 2 साल बाद, WebAssembly अब प्रमुख वेब ब्राउज़रों द्वारा समर्थित है।
तो यह जेएस इंजन को wasm में लागू करने के बराबर नहीं है।
Js -> wasm के लाभ न केवल GC समर्थन है, बल्कि छोटे कोड आकार और तेज़ निष्पादन भी हैं, विशेष रूप से Ionic2 जैसे हाइब्रिड अनुप्रयोग विकास के क्षेत्र में, जो आमतौर पर JS फ़ाइल लगभग 10MB उत्पन्न करता है जिसके कारण एप्लिकेशन लोड समय 5 से अधिक हो जाता है। सेकंड (JS = 1 सेकंड का प्रत्येक 2MB पार्स)

@jfbastien तो कृपया JS -> wasm transpiler के बारे में अपना अद्यतन उत्तर पोस्ट करें?

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

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

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

मैं काफी उत्सुक हूं कि मेरे निष्कर्ष क्या होंगे क्योंकि मैं इस तरह के दृष्टिकोण के पेशेवरों और विपक्षों को देखता हूं। कोई इनपुट हो तो बताएं।

@ Mohsen7s मेरा उत्तर सटीक रहता है: WebAssembly का MVP संस्करण GC और JIT क्षमताओं का समर्थन नहीं करता है जो एक तेज़ जावास्क्रिप्ट वर्चुअल मशीन को लागू करना संभव बनाता है। एक दुभाषिया पूरी तरह से संभव है, चतुर चाल के साथ यह काफी अच्छा हो सकता है, लेकिन उतना नहीं जितना मूल कार्यान्वयन करता है।

यह हमारे "न्यूनतम व्यवहार्य उत्पाद" दृष्टिकोण के लिए अंतर्निहित है: कुछ ऐसा शिप करें जो पहले कुछ उपयोग के मामलों के लिए काम करता है, और फिर अन्य उपयोग मामलों को पूरा करने के लिए सुविधा जोड़ें। कृपया एमवीपी पर इसी तरह की चर्चा के लिए और "भविष्य की विशेषताएं" गायब होने के लिए निम्नलिखित थ्रेड देखें: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

तकनीकी चर्चाओं को छोड़कर कि वर्तमान में क्या लागू किया जा सकता है और क्या नहीं, मुझे आश्चर्य है कि JS -> WASM दार्शनिक रूप से और मार्केटिंग के दृष्टिकोण से नंबर 1 लक्ष्य नहीं है - मैं यह देखने में विफल हूं कि आप कभी भी कैसे प्राप्त करेंगे डेवलपर बाय-इन तब तक करें जब तक यह मामला न हो। यदि वे सभी फ्रंट/बैक-एंड/फुल-स्टैक डेवलपर्स जेएस कौशल के साथ किसी भी मार्केट वर्टिकल में काम करने में सक्षम हैं, तो इसके बजाय अपना समय सी ++ सीखने में बिताना चाहते हैं, जो कि उद्योगों के एक छोटे से सबसेट में उपयोग किया जाता है, तो वे पहले ही कर चुके होंगे। तो - मुझे पता है, मैं एक के रूप में बोलता हूं। मैं मदद नहीं कर सकता लेकिन महसूस करता हूं कि यह पूरी चर्चा एक गूंज कक्ष की तरह है और जो लोग एक कंपाइलर की कमी का बचाव करते हैं, वे पाएंगे कि कोयले के चेहरे पर लोगों से बात करने में उनका समय बेहतर होगा कि वे वास्तव में क्या चाहते हैं।

@ बॉसलेवल

तकनीकी चर्चाओं को छोड़कर कि वर्तमान में क्या लागू किया जा सकता है और क्या नहीं, मुझे आश्चर्य है कि JS -> WASM दार्शनिक रूप से और मार्केटिंग के दृष्टिकोण से नंबर 1 लक्ष्य नहीं है - मैं यह देखने में विफल हूं कि आप कभी भी कैसे प्राप्त करेंगे डेवलपर बाय-इन तब तक करें जब तक यह मामला न हो। यदि वे सभी फ्रंट/बैक-एंड/फुल-स्टैक डेवलपर्स जेएस कौशल के साथ किसी भी मार्केट वर्टिकल में काम करने में सक्षम हैं, तो इसके बजाय अपना समय सी ++ सीखने में बिताना चाहते हैं, जो कि उद्योगों के एक छोटे से सबसेट में उपयोग किया जाता है, तो वे पहले ही कर चुके होंगे। तो - मुझे पता है, मैं एक के रूप में बोलता हूं।

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

यह चर्चा, साथ ही https://github.com/WebAssembly/design/issues/992#issuecomment -281735235, विभिन्न लोगों के लक्ष्यों की विविधता को दर्शाती है। कोई गलत नहीं है! एमवीपी को बस प्राथमिकता देने की जरूरत है कि पहले किसे सेवा दी जाए।

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

W3C कम्युनिटी ग्रुप बनाने का यही पूरा बिंदु था। हमें लगता है कि यह सफल रहा है, जैसा कि हमने कई इच्छुक डेवलपर्स से सुना है। कुछ एमवीपी में रुचि नहीं रखते हैं, लेकिन भविष्य की सुविधाओं में रुचि रखते हैं।

@jfbastien

ब्राउज़र पहले से ही जावास्क्रिप्ट को कुशलता से चला सकते हैं।

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

W3C समुदाय समूह बनाने का यही संपूर्ण बिंदु था

हा फिर से - आप कितने वास्तविक विश्व देवों को जानते हैं जो एक सामुदायिक समूह में शामिल होते हैं? जो देवता करते हैं वे आम तौर पर इंजीलवादी आदि होते हैं जो जानकार होते हैं, लेकिन वास्तविक जीवन के देव के दर्द को कम महसूस करते हैं।

और मुझे खेद है, मैं वास्तव में इस पृष्ठ पर/W3C में शामिल/किसी को भी कमतर नहीं आंकना चाहता। जैसा कि आप कहते हैं, यह एक चर्चा है, और आगे की पंक्तियों से यह मेरा दृष्टिकोण है।

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

ब्राउज़र-आधारित प्रदर्शन को अगले स्तर पर ले जाने के लिए आपको दूसरी भाषा सीखनी होगी; क्या यह स्वीकार्य होगा?

क्योंकि यह मूल रूप से वह प्रश्न है जिसका इस पृष्ठ पर कुछ लोगों द्वारा पहले ही (मेरे दिमाग में, निंदनीय रूप से) उत्तर दिया जा चुका है।

और अंत में (मैं वादा करता हूँ ;-)) @jfbastien , अगर:

इसे खत्म करने के लिए, WebAssembly की गैर-वेब आकांक्षाएं हैं।

इसे "WebAssembly" क्यों कहा जाता है?

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

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

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

हा फिर से - आप कितने वास्तविक विश्व देवों को जानते हैं जो एक सामुदायिक समूह में शामिल होते हैं? जो देवता करते हैं वे आम तौर पर इंजीलवादी आदि होते हैं जो जानकार होते हैं, लेकिन वास्तविक जीवन के देव के दर्द को कम महसूस करते हैं।

और मुझे खेद है, मैं वास्तव में इस पृष्ठ पर/W3C में शामिल/किसी को भी कमतर नहीं आंकना चाहता। जैसा कि आप कहते हैं, यह एक चर्चा है, और आगे की पंक्तियों से यह मेरा दृष्टिकोण है।

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

ब्राउज़र-आधारित प्रदर्शन को अगले स्तर पर ले जाने के लिए आपको दूसरी भाषा सीखनी होगी; क्या यह स्वीकार्य होगा?

क्योंकि यह मूल रूप से वह प्रश्न है जिसका इस पृष्ठ पर कुछ लोगों द्वारा पहले ही (मेरे दिमाग में, निंदनीय रूप से) उत्तर दिया जा चुका है।

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

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

साथ ही, टीसी39 वास्तव में जावास्क्रिप्ट को बेहतर बनाने की कोशिश कर रहा है। मेरा मानना ​​​​है कि हाल के वर्षों में, विशेष रूप से ES6 के साथ।

लेकिन आपकी बात बनी हुई है: हो सकता है कि डेवलपर्स जावास्क्रिप्ट के साथ -साथ C++ या Rust जैसी अधिक "WebAssembly-फ्रेंडली" भाषाओं से

इसे "WebAssembly" क्यों कहा जाता है?

हा! यह एक अद्भुत प्रश्न है। मेरे पास "WebAssembly: न तो वेब और न

तो मैं तुम्हें उस पर लटकाए रखूंगा।

मैं यहाँ दो इच्छाएँ पढ़ रहा हूँ:

1. तेजी से लोड समय के लिए मानक जावास्क्रिप्ट का द्विआधारी प्रतिनिधित्व।
2. मूल रूप से संकलित सी ++ और मानक जावास्क्रिप्ट के बीच प्रदर्शन अंतर को पाटने के लिए कुछ।

आइटम 2 कई कंपनियों द्वारा चल रहे शोध और बड़े पैमाने पर निवेश का विषय है। यदि आप पिछले 15 वर्षों में जावास्क्रिप्ट इंजनों के प्रदर्शन माप को देखें, तो यह भी काम कर रहा है ... अंतर छोटा होता जा रहा है।

जहां तक ​​मैं जानता हूं, आइटम 1 पर किसी के द्वारा काम नहीं किया जा रहा है। यह व्यापक रूप से जटिल है, और कठिन होता जा रहा है क्योंकि जावास्क्रिप्ट तीव्र गति से विकसित हो रहा है। WebAssembly बहुत सख्त और अपेक्षाकृत सरल है, और इसे विकसित होने में अभी भी कई साल लग गए।

@jfbastien - आपके विचार और विचारशील प्रतिक्रिया के लिए बहुत धन्यवाद :)

तो कुछ दृष्टांत बिंदु, किसी विशेष क्रम में नहीं:

१) एक अच्छा उदाहरण मैं इस पूरी चर्चा को देखता हूं और जिस दिशा में आप जा रहे हैं उस पर मेरा विचार, नोडजेएस के साथ है - एक जेएस एपीआई/सी ++ बैक-एंड के लिए फ्रंट-एंड - आपको उपयोग/परिचित आदि में आसानी मिलती है एक ओर गति और दूसरी ओर गति।
2) नोड के साथ चिपके हुए, 2008 में वापस जब मैंने अपनी निजी ओडिसी शुरू की ;-) मैंने मूल रूप से बैक-एंड के लिए PHP और जावा दोनों को देखा (मैं आईटी प्रबंधन के अंधेरे पक्ष पर एक दशक के बाद विकास में वापस आ रहा था) और बिक्री ;-)!) एक व्यक्तिगत कहानी जो मुझे पता है, लेकिन मुझे संदेह है कि मैं अकेला डेवलपर हूं जो इस तरह से महसूस करता है, विशेष रूप से वे जो खुद के लिए काम कर रहे हैं, न कि कंपनी के पैसे पर जब वे भाषा सीखते हैं।
3) मैंने अपना अगला बिंदु बनाने से पहले जानबूझकर संख्याओं को गुगल नहीं किया है (वास्तव में मुझे यकीन नहीं है कि मैं भी कर सकता हूं) लेकिन मैं शर्त लगा सकता हूं कि एएसएम का टेक-अप कम था। मुझे पता है कि जब मैंने प्रारंभिक डेमो देखा तो मैं बहुत उत्साहित हो गया लेकिन यह जानने पर कि कोई कंपाइलर नहीं था, मैंने तुरंत इसे खारिज कर दिया। एक वेब डेवलपर से पूछने के लिए जो ग्रह पर सबसे बड़े देव समुदाय का हिस्सा है (जेएस) एपीआई, पुस्तकालयों, संसाधनों, ट्यूटोरियल, ढांचे आदि की एक विस्तृत श्रृंखला के साथ उससे दूर जाने के लिए ऑनलाइन उपलब्ध है, मेरे दिमाग में बहुत अधिक पूछना है, और संभावित रूप से पहला कदम (यानी एक कंपाइलर) बनाने के साधन के साथ उन्हें प्रदान न करने से आपकी ओर से एक स्पष्ट चाल गुम है। मैं यहां तक ​​कि दांव लगाने के लिए भी जाऊंगा कि शेडिंग लैंगेज (जीएलएसएल) में विकास ने अब एएसएम की तुलना में अधिक वृद्धि देखी है कि आप ए) इसे सीधे पिक्सी.जेएस और थ्री.जेएस जैसे उत्कृष्ट ढांचे में लिख सकते हैं और बी) इसके साथ खेलते हैं सीधे ShaderToy जैसी साइटों पर।
4) आम तौर पर खेल उद्योग/गेमिंग। मैं यहां अनुभव से बात कर सकता हूं क्योंकि ए) मैं पिछले 9 वर्षों से (अभी तक अप्रकाशित!) गेम लिख रहा हूं और बी) मैंने टीआईजीए (यूके के गेम डेवलपर्स के लिए ट्रेड एसोसिएशन) के बोर्ड में 2 साल तक काम किया है। मेरा विश्वास करो, मुझे लगता है कि वेब पर माइग्रेट करने के इच्छुक गेम डेवलपर्स की संख्या शायद एक तरफ गिना जा सकता है - गेम डेवलपर्स पहले से ही उस उद्योग में हैं जो वे प्यार करते हैं और इसके बावजूद पे-हिट/लंबे समय तक काम कर रहे हैं, इसलिए ये WA के लक्षित दर्शक नहीं होने चाहिए। हां, उनके नियोक्ता हमेशा अपने गेम को पोर्ट करने के लिए नए माध्यमों की तलाश में रहते हैं, लेकिन मोबाइल को छोड़कर (जहां मूल कोड दुख की बात है और जिसे मैं WASM ठीक करना चाहता हूं), वेब अभी भी बहुत अधिक है प्रदर्शन और मुद्रीकरण दोनों के मामले में पीसी/कंसोल से खराब संबंध।
5) इसके विपरीत, जबकि बेडरूम कोडर/इंडी दृश्य चरम पर नहीं है, यह कुछ साल पहले था, ऐसे वेब डेवलपर्स की एक बड़ी संख्या है जो अपने खाली समय में वेब गेम बनाना पसंद करते हैं। और जब तक मैं राजनीति में खुलकर नहीं आना चाहता और मैं किसी भी तरह से एकता के लोगों को नहीं मार रहा हूं (मैंने उनमें से कई के साथ व्यवहार किया है और यह एक अच्छा उत्पाद है), व्यक्तिगत रूप से मुझे लगता है कि आपको हितों की देखभाल करनी चाहिए कई छोटे लोगों में से, एक बड़ा आदमी नहीं (यह दार्शनिक और व्यावसायिक दोनों तरह से समझ में आता है)।

मैं आपकी बात @jfbastien को देखने के लिए बहुत उत्सुक

@RyanLamansky - मुझे लगता है कि आप उचित भेद करते हैं। इसके संबंध में:

जहां तक ​​मैं जानता हूं, आइटम 1 पर किसी के द्वारा काम नहीं किया जा रहा है। यह व्यापक रूप से जटिल है, और कठिन होता जा रहा है क्योंकि जावास्क्रिप्ट तीव्र गति से विकसित हो रहा है।

एक पूरी तरह से व्यक्तिगत स्तर पर, जैसा कि कोई व्यक्ति जो 2008 से प्रतिदिन 8 घंटे JS लिख रहा है, मैं JS के विकास को बस थोड़ी देर के लिए रुकते हुए देखना चाहता हूं और बाकी सभी को पकड़ने देना चाहता हूं! मैंने हमेशा सबसे कम आम भाजक के विकास के सिद्धांत पर काम किया है यानी अगर इसमें 100% समर्थन नहीं है तो यह नहीं हो रहा है (आईई 6/7/8/9 एक तरफ ;-))। और इसलिए जब हमें डेस्कटॉप और मोबाइल पर ES5 के लिए 100% ब्राउज़र समर्थन भी नहीं मिला है, तो हम खुद को ट्रेंडी ES6 पैटर्न और कथित उपयोग के मामलों पर ध्यान केंद्रित करने की अजीब स्थिति में पाते हैं। भाषा स्पष्ट रूप से काम करती है (इसके बावजूद इसे स्वीकार किया गया है) जैसा कि इसके बाजार-शेयर द्वारा प्रदर्शित किया गया है, इसलिए हम, डेवलपर्स के एक समुदाय के रूप में, अगले कुछ वर्षों में कुशल, इष्टतम कोड लिखने के लिए सीखने में कैसे खर्च करते हैं, इसके बजाय हमारे पास क्या है फिर से नए हिप्स्टर कोड के साथ पहिया का फिर से आविष्कार करना (क्षमा करें, मैं रेंट क्षेत्र में जा रहा हूं ;-))?

मुझे लगता है कि शायद समय आ गया है कि मुझे अपना कोट मिल जाए ;-)

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

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

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

टिप्पणियों और दस्तावेज़ों का कहना है कि डब्ल्यूएएसएम जेएस के अलावा चलता है और ब्राउज़र के समान जेएस इंजन (अनुकूलित) का उपयोग करता है। https://developer.mozilla.org/en-US/docs/WebAssembly

मैं वास्तव में इस प्रश्न को नहीं समझता।

मूर्खतापूर्ण प्रश्न पूछने और मूर्खतापूर्ण टिप्पणी करने के लिए क्षमा करें: क्या प्रश्न और Webassembly टीम की टिप्पणी का अर्थ यह है कि Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? मुझे केवल व्यक्तिपरक विचार दिखाई देते हैं। क्या कोई इसे समझा सकता है? यदि वेबसेम्बली तेज है तो जावास्क्रिप्ट तो एक ट्रांसपिलर क्यों नहीं प्रदान करता है? यदि जावास्क्रिप्ट संभव नहीं है तो ES7/TS कोड क्यों नहीं? इसके इर्द-गिर्द इतनी गोपनीयता क्यों है?

@ganeshkbhat WASM की प्रारंभिक रिलीज़ asm.js की एक कॉम्पैक्ट बाइनरी एन्कोडिंग से थोड़ी अधिक है, जो जावास्क्रिप्ट का एक बहुत ही सख्त उपसमुच्चय है। जब तक 64-बिट पूर्णांकों का उपयोग नहीं किया जाता है, यह asm.js से तेज नहीं चलता है, क्योंकि इन्हें asm.js में अनुकरण किया जाना है।

WASM में सुविधाओं को जोड़ने के प्रस्ताव हैं जो इसे क्षमता में जावास्क्रिप्ट के करीब लाएंगे (कचरा संग्रह, DOM एकीकरण, थ्रेड्स), लेकिन पूर्ण जावास्क्रिप्ट सुविधा सेट को जोड़ने की कोई योजना नहीं है। तो, यह संभावना है कि JS-> WASM ट्रांसपिलर कभी मौजूद नहीं होगा। इसके बजाय, नए एप्लिकेशन और पुस्तकालय बनाए जाएंगे जो WASM की सीमाओं के भीतर काम करने के लिए डिज़ाइन किए गए हैं। आज, वह सी और सी ++ है, जहां भाषा प्रतिबंध WASM और asm.js के साथ अच्छी तरह से संरेखित हैं।

कोई रहस्य नहीं है और न ही कोई जादू है। Wasm "जावास्क्रिप्ट से तेज़" है क्योंकि यह बहुत सरल भाषा है जो हार्डवेयर के बहुत करीब है। जावास्क्रिप्ट एक जटिल भाषा है जिसे निष्पादन के दौरान कई महंगे काम करने पड़ते हैं। यह सीधे के बजाय वासम के माध्यम से इसे मूल कोड में संकलित करके जादुई रूप से तेज़ नहीं होगा।

@ganeshkbhat वर्तमान में, asm.js / webassembly के अंदर वस्तुओं को आवंटित करना संभव नहीं है। asm.js और webassembly में, सभी JavaScript ऑपरेशंस वहां मानों को स्टोर और लोड करने के लिए एक बड़े टाइपेडरे का उपयोग करेंगे। जावास्क्रिप्ट ऑब्जेक्ट (जैसे var obj = {a: 1, b: 'test'} ) और सरणियाँ (जैसे var a = []; ) बनाना वेब असेंबली के अंदर संभव नहीं है क्योंकि अभी तक कोई ऑब्जेक्ट समर्थन नहीं है। यह सभी प्रमुख ब्राउज़रों में यथाशीघ्र वेब असेंबली समर्थन प्राप्त करने के लिए किए गए न्यूनतम व्यवहार्य उत्पाद का एक डिज़ाइन निर्णय है।

भविष्य के संस्करण में, webassembly के लिए GC समर्थन की योजना बनाई गई है। हम ( LeaningTech.com डेवलपर्स) वेब असेंबली में ऑब्जेक्ट सपोर्ट के प्रस्ताव पर काम कर रहे हैं, लेकिन इसे सभी प्रमुख ब्राउज़र में एक विनिर्देश और कार्यान्वयन के रूप में आने में कुछ समय लगेगा। तब तक, JavaScript (और CoffeeScript, TypeScript, आदि) को webassembly में ट्रांसपाइल करना संभव नहीं है। जब प्रस्ताव स्वीकार कर लिया जाता है, तो जावास्क्रिप्ट के एक सभी सुविधाओं का समर्थन नहीं करेगा जो वर्तमान में उपलब्ध हैं।

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

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

उन सभी के लिए, जो (मेरे रूप में) js -> webassembly को संकलित करने के बारे में उत्साहित हैं, भविष्य में ts2c ट्रांसपिलर प्रोजेक्ट का उपयोग करके js -> c -> webassembly के माध्यम से अप्रत्यक्ष और बहुत ऊबड़-खाबड़ तरीका हो सकता है।

@mauron85 गैर-ब्राउज़र और गैर-जावास्क्रिप्ट रनटाइम वातावरण निश्चित रूप से डिज़ाइन का एक विचार है, यह सिर्फ इतना है कि आज केवल JS API मौजूद है।

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

आईएमओ JavaScript -> WebAssembly संकलन क्षमता का एक लाभ यह है कि जावास्क्रिप्ट पुस्तकालयों और उपकरणों के डेवलपर्स/रखरखाव शायद अपने एपीआई को दो प्रारूपों में जारी करने में सक्षम होंगे:

1. JS में (जैसा कि अभी है) जिसे उपयोगकर्ता ब्राउज़र और नोड के लिए उपयोग कर सकते हैं
2. WASM संकलित पुस्तकालय के रूप में जो अधिक कुशल हो सकता है।

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

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

WASM संकलित पुस्तकालय के रूप में जो अधिक कुशल हो सकता है

क्यों? जावास्क्रिप्ट का एक ब्लॉब वेब असेंबली को ट्रांसपिल्ड क्यों करेगा (सबसे खराब स्थिति परिदृश्य, उस बाइनरी में जावास्क्रिप्ट इंजन के लिए अधिकांश रनटाइम सहित; सर्वोत्तम स्थिति परिदृश्य, जिसमें भविष्य के बिल्टिन वास जीसी के शीर्ष पर बनाई गई परत शामिल है, जो वैसे भी अपना ओवरहेड लेता है ) जावास्क्रिप्ट चलाने के लिए समर्पित एक जिट पर फेंके गए जावास्क्रिप्ट से तेज दौड़ें ... जावास्क्रिप्ट चला रहे हैं?

ठीक है, आपका मतलब है कि अधिक ओवरहेड के साथ और भी धीमा होगा?

शायद कुछ ऐसा है जो मुझे अच्छी तरह समझ में नहीं आया। C/C++/Rust -> WebAssembly संकलित सामग्री वास्तव में कैसे कुशल है और भले ही भविष्य में JS -> WASM समर्थन हो जो ओवरहेड का कारण बने? क्या ऐसा इसलिए है क्योंकि जेएस एक गतिशील भाषा है और सी, सी ++, और जंग नहीं हैं? या ऐसा इसलिए है क्योंकि जेएस स्वभाव से पूरी तरह से संकलित भाषा नहीं है बल्कि ये अन्य भाषाएं हैं?

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

मुझे लगता है कि हम सिर्फ JS के लिए एक बाइनरी एन्कोडिंग को परिभाषित कर सकते हैं, और अभी के लिए लीनियर मेमोरी आदि को अनदेखा कर सकते हैं। यह सरल और पॉलीफिल करने योग्य है।

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

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

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

FWIW इस बारे में एक शानदार स्लाइडडेक है कि कैसे V8 जावास्क्रिप्ट अंकगणित को संभालता है: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr यह सिर्फ _one_ उदाहरण है जहां वास्तविकता उससे कहीं अधिक कठिन है जितना कि यह लग सकता है और व्यवहार में बहुत सार्थक नहीं है क्योंकि मूल VM एक बेहतर, तेज काम कर सकता है (और संभवतः होगा) क्योंकि यह वास्तव में मूल है और इसकी पहुंच है संसाधन और एपीआई कभी नहीं होंगे - और (शायद) सबसे महत्वपूर्ण बात, पुनरावृत्ति के वर्ष।

इसका मतलब यह नहीं है कि JS/टाइपस्क्रिप्ट का _subset_ सफलतापूर्वक प्रसार नहीं कर सका, जैसे ThinScript , TurboScript , आदि। वे पहली नज़र में लगेंगे ।

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

6 अप्रैल 2017 को 00:36 बजे, रयान लैमांस्की नोटिफिकेशन @github.com ने लिखा:

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

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

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

शायद मुझे कुछ नहीं मिल रहा है, लेकिन WebAssembly के विचारों में से एक जेएस के पार्स समय से बचने के लिए सीधे एएसटी लोड करना है, है ना?

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

@agnivade , यह पूरी तरह से अलग, बहुत अधिक निम्न-स्तरीय भाषा के लिए एक एएसटी है।

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

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

@ रॉसबर्ग-क्रोमियम - बहुत बहुत धन्यवाद। यह बहुत कुछ साफ करता है! हालांकि एक शक -

और यह भी ध्यान में नहीं रखा जाता है कि आपको शायद वासम में जेएस वीएम रनटाइम सिस्टम के संपूर्ण कार्यान्वयन को भी शामिल करना होगा, जो आसानी से मेगाबाइट कोड है

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

@agnivade , गतिशील अनुकूलन के बिना जावास्क्रिप्ट धीमा हो जाएगा, और मेरा मतलब है _really_ धीमा, जैसे 100x धीमा, शायद बदतर।

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

और निश्चित रूप से, आपको डीओएम के लिए एक इंटरफ़ेस परत की भी आवश्यकता होगी।

ठीक है, मुझे लगता है कि मैं अब चीजों को थोड़ा बेहतर समझता हूं। मैंने सोचा था कि

कचरा संग्रहकर्ता, वस्तु अभ्यावेदन, आदिम और आधार पुस्तकालय, आदि।

ब्राउज़र से ही इस्तेमाल किया जा सकता है। और मैं ब्राउज़र को एएसटी लोड करने और अपना सामान्य काम करने दे सकता हूं। लेकिन अब मुझे एहसास हुआ कि WASM के अंदर ही सब कुछ पैक करने की जरूरत है।

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

@distransient , तो आप सभी स्क्रिप्टिंग भाषाओं की

जो LLVM का उपयोग करके टाइपस्क्रिप्ट को WebAssembly में संकलित करने में रुचि रखते हैं। इस पहुंच परियोजना को देखें। https://github.com/MichaReiser/speedy.js
लगता है ये चर्चा कभी खत्म नहीं होगी...

@ रॉसबर्ग-क्रोमियम मैंने कहा कि यह "दिलचस्प" होगा, आसान या सुंदर नहीं

एक सार्वभौमिक-ईश स्क्रिप्टिंग भाषा बाइटकोड दिलचस्प होगा ...

जबकि WASM अंततः पायथन जैसे सामान का समर्थन करने के लिए विकसित हो रहा है, हम वेब के लिए स्क्रिप्टिंग भाषाओं को विकसित करने के लिए प्रथम श्रेणी का समर्थन प्राप्त कर सकते हैं, WASM इसे प्रदान कर सकता है, अगर हम एक ही समय में विपरीत छोर से समस्या का सामना करते हैं।

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

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

एक बार बुनियादी समर्थन स्थापित हो जाने के बाद, मूल रूप से केवल नए नोड प्रकार जोड़कर, मानक बीच में WASM को पूरा करने के लिए विकसित हो सकता है। शुरू करने के लिए सरल चीजें हैं, जैसे स्पष्ट add और concat नोड्स, या शायद नए डेटा प्रकार जोड़ना, जैसे DEC64।

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

25 मई 2017 को 02:57 बजे, कार्ल स्मिथ ने नोटिफिकेशन @github.com लिखा:
>

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

केवल आप की तुलना में "अपेक्षाकृत सरल" की अधिक व्यापक परिभाषा के लिए
मन में है... ;)

WASM के सापेक्ष, यह सरल है।

@bguiz उदाहरण के लिए:

• आप JS को मूल रूप से ASM में अनुवाद नहीं कर सकते, क्योंकि इसकी वास्तुकला अलग है।
• आप एएसएम से डीओएम में हेरफेर नहीं कर सकते, क्योंकि आपके पास सीपीयू ग्राउंड लेवल पर इसके संसाधनों तक पहुंच नहीं है।

Google V8 इंजन पूरे रनटाइम कार्य को निष्पादित करने से पहले, पहले से ही जावास्क्रिप्ट को सीधे देशी मशीन कोड में संकलित करता है।

इसलिए क्लाइंट साइड से वैकल्पिक WASM पाइपलाइन रखना पूरी तरह से अनावश्यक होगा।

दूसरी ओर, WASM को मैंडलब्रॉट डेमो के साथ प्रस्तुत किया गया था, फिर इसमें पहले स्थान पर एकता "टैंक" डेमो की सुविधा है, लेकिन मुझे बहुत संदेह है कि ASM-> CPU (यहां तक ​​​​कि SSE डबल परिशुद्धता के साथ) के साथ ड्राइंग पिक्सल कभी भी तेज हो सकते हैं WebGL->GPU की तुलना में, क्योंकि जैसा कि यह समुदाय कहता है कि GPU दायरे में नहीं है। तो क्या हुआ?

@ivanherczeg वाह ! यह समुदाय कहां कहता है कि GPU कल्पना में नहीं है?

@SephReed

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

-फिलो

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

C# रनटाइम को wasm में पोर्ट किया गया था और पूरी तरह कार्यात्मक प्रोटोटाइप JS को पूरी तरह से बदल रहा था। तो इसका मतलब है कि भविष्य में आप ब्राउज़र पर जेएस को बदलने और जावा, सी # या यहां तक ​​​​कि सी ++ में क्लाइंट साइड वेब ऐप लिखने के लिए उभरने वाले रनटाइम की उम्मीद कर सकते हैं, जिसमें एक बयान के साथ "कोड देशी के पास तेजी से चलेगा" , "संकलित कोड वीएम से तेज हैं" या जावास्क्रिप्ट की सहायता के बिना कुछ भी।

मैं जो कहना चाह रहा हूं, कृपया इस वीडियो को देखें।

WebASM को JS को पूरी तरह से नहीं लेने के पूरक के लिए पेश किया गया था, जो प्रथम श्रेणी की भाषा की जगह ले रहा था।

निकट भविष्य में आप मूल रूप से संकलित सर्वर से वितरित वेबपेजों की अपेक्षा कर सकते हैं

https://github.com/ballercat/walt

@Steakeye बहुत अच्छा :) मेरे पास एक नाटक होगा - हाइलाइट करने के लिए बहुत धन्यवाद :)

आप NectarJS का उपयोग करके JS को WebAssembly में संकलित कर सकते हैं। डेमो: http://nectar-lang.com/ ड्रॉपडाउन WebAssembly में से चुनें

दिलचस्प है, NectarJS डेमो emscripten का उपयोग करता है, आप इसे asm.js आउटपुट में देख सकते हैं। ऐसा प्रतीत होता है कि यह स्थिर रूप से जेएस को किसी चीज़ में संकलित करता है - संभावित सी या एलएलवीएम आईआर - और फिर उसे एम्स्क्रिप्टन के माध्यम से चलाता है।

wasm आउटपुट भी emscripten का उपयोग करता है (बाइनरी का निरीक्षण करने से देखा जा सकता है), लेकिन ऐसा लगता है कि यह एक पुराने संस्करण का उपयोग करता है क्योंकि यह 0xd wasm बायनेरिज़ का उत्सर्जन करता है, जो आधुनिक VMs में नहीं चलता है। यह आपको सिर्फ वासम भेजता है, जेएस नहीं, इसलिए यह किसी भी तरह से चलने योग्य नहीं है। किसी भी मामले में, यह बहुत संभव है कि यह asm.js के समान ही कर रहा हो, बस वासम आउटपुट के लिए ध्वज के साथ चल रहा emscripten फ़्लिप हो गया।

डेमो में इनपुट पर 300 बाइट की सीमा होती है, इसलिए यह महसूस करने के लिए कि उनका विश्लेषण कितना शक्तिशाली है, इसे वास्तविक दुनिया के कार्यक्रम में फीड करना कठिन है, जो कि इस तरह के स्थिर दृष्टिकोण के साथ वास्तविक प्रश्न है। सामान्य तौर पर, इस विषय पर अकादमिक शोध संशयवाद का सुझाव देते हैं।

विंडोज़ के लिए उनका संकलित डेमो बस मेरे लिए दुर्घटनाग्रस्त हो गया

मैं यहां @kripken संशयवाद से सहमत हूं। मेरा मानना ​​​​है कि मनमाने ढंग से जेएस को उचित रूप से WebAssembly में परिवर्तित नहीं किया जा सकता है। कोई भी उपकरण जो इसे प्राप्त करने का दावा करता है, वह शायद JS भाषा के कुछ ट्रैक्टेबल सबसेट पर काम कर रहा है, या निष्पादन प्रदर्शन को छोड़ रहा है।

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

var a = {prop1: 1};
func(a);

इसे (छद्म-वास में) परिवर्तित किया जा सकता है

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

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

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

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

क्या "मजबूत मोड" फ्रंट बीटीडब्ल्यू पर कोई खबर है?

@ सिमरन-बी, हमने यहां संक्षेप में कारणों के लिए लंबे समय से मजबूत मोड छोड़ दिया

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

@ सिमरन-बी: "हालांकि मुझे जावास्क्रिप्ट सबसेट का उपयोग करने में कोई फर्क नहीं पड़ता। या शायद एक टाइप किया गया संस्करण"

उस स्थान में कुछ बहुत ही दिलचस्प काम है, जैसे असेंबलीस्क्रिप्ट जो टाइपस्क्रिप्ट का एक सख्त उपसमुच्चय है जो WebAssembly को संकलित करता है, https://github.com/AssemblyScript/assemblyscript

@rossberg : "मुझे जावास्क्रिप्ट या टाइपस्क्रिप्ट की" स्थिर रूप से संकलित "बोली डिजाइन करने के विचार के लिए बहुत उम्मीद नहीं है - यह एक अलग भाषा होगी जो मौजूदा कोड नहीं चला सकती है, इसलिए ज्यादा बिंदु नहीं है।"

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

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

यदि असेंबलीस्क्रिप्ट जावास्क्रिप्ट और असेंबली दोनों को संकलित कर सकता है, तो यह बहुत आदर्श होगा। इन अपडेट का इंतजार है।

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

@SephReed हाँ यह जावास्क्रिप्ट को संकलित कर सकता है, क्योंकि एक WebAssembly -> asm.js कंपाइलर है , जिसे सभी WebAssembly कोड के साथ काम करना चाहिए।

यह भी देखें "क्या WebAssembly को पॉलीफ़िल किया जा सकता है?"

यदि आप इसके बजाय "असेंबलीस्क्रिप्ट के लिए मुहावरेदार जावास्क्रिप्ट कोड को संकलित करना संभव है?", तो मुझे पूछना होगा, आप ऐसा क्यों करना चाहेंगे जब WebAssembly / asm.js मुहावरेदार जावास्क्रिप्ट कोड की तुलना में बहुत तेज हैं?

हालांकि मुझे लगता है कि आपको टाइपस्क्रिप्ट कंपाइलर के माध्यम से असेंबलीस्क्रिप्ट कोड चलाने में सक्षम होना चाहिए। हालांकि आपको कुछ बातों का ध्यान रखना होगा ।

असेंबलीस्क्रिप्ट दस्तावेज़ीकरण का यह अनुभाग भी देखें।

सज्जनों, कृपया WALT , जावास्क्रिप्ट जैसी WebAssembly भाषा।

यूपीडी. नेक्रोपोस्टिंग के लिए क्षमा करें

मैं देखता हूं कि बहुत से लोग इस "जेएस -> डब्ल्यूएएसएम" कंपाइलर को एक अच्छा विचार मानते हैं।

उन लोगों के लिए जो इसे उपयोगी नहीं पाते हैं, जैसे:

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

कृपया, यहां मेरा ठोस उदाहरण है कि यह क्यों महत्वपूर्ण है, और यह क्यों उपयोगी है, और न केवल आप "कुछ आकार में कमी प्राप्त करें, लेकिन यह इसके बारे में है"। WebAssembly के साथ आने वाली सुविधाओं में से एक है:

<=XXX « SaNdBoXeD EnViRoNmEnT » XXX =>

WebAssembly केवल प्रदर्शन के बारे में नहीं है। आप Figma टीम से प्लगइन्स के बारे में एक अच्छा लेख देख सकते हैं।

प्लगइन सिस्टम बनाना काफी चुनौतीपूर्ण है। कस्टम कोड चलाने के लिए आपको कुछ अच्छे तरीके की आवश्यकता है। आपको एक अलग वातावरण चाहिए, एक सुरक्षित वातावरण।

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

लेकिन यहाँ समस्या है, "लगभग समान":

क्या मैं अपने सुरक्षित वातावरण में एनपीएम से जेएस पैकेज का उपयोग कर सकता हूं?

नहीं।

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

क्या मैं अपने सुरक्षित वातावरण में एनपीएम से टीएस पैकेज का उपयोग कर सकता हूं?

नहीं।

असेंबलीस्क्रिप्ट टीएस जैसी भाषा भी है। यदि यह पूरी तरह से प्रकारों से आच्छादित है तो यह TS में लिखी गई किसी चीज़ को संकलित कर सकता है। कोई अपवाद नहीं। कोई any । लेकिन अक्सर लोगों के पास उनके कॉन्फिग पर्याप्त सख्त नहीं होते हैं या उनके पास कुछ @ts-ignore , या इससे भी अधिक बार, - वे js में पैकेज लिखते हैं और .d.ts फाइलों में अलग-अलग प्रकार प्रदान करते हैं - इन सभी मामलों में आप ऐसे पैकेज को WASM में संकलित करने में सक्षम नहीं होगा।

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

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

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

इसके साथ ही, जेएस -> WebAssembly की व्यवहार्यता मेरे लिए स्पष्ट नहीं है।

@ जेरीग्रीन फिगमा का दृष्टिकोण बहुत विशिष्ट मामला है और मुझे लगता है कि अधिकांश परियोजनाओं के लिए आईफ्रेम या क्षेत्र तीसरे पक्ष के जावास्क्रिप्ट अलगाव के लिए काफी सुंदर हैं। विशेष मामलों के लिए जहां अलगाव अधिक नियंत्रित होना चाहिए और प्रदर्शन, आकार और लोड समय इतना महत्वपूर्ण नहीं है, आप हमेशा QuickJS या JavaScriptCore को WebAssembly में संकलित कर सकते हैं।

आप वेब वर्कर्स का भी उपयोग कर सकते हैं, और अपने अविश्वसनीय कोड से पहले कोड चला सकते हैं जो किसी भी एपीआई को हटा देता है जिसे आप नहीं चाहते कि अविश्वसनीय कोड तक पहुंच हो। इस मामले में WASM की कोई आवश्यकता नहीं है @JerryGreen!

फ्रैमरेट एक वास्तविक चीज़ में तीन जेएस में गिरता है, मुझे यकीन नहीं है कि क्या वासम मदद कर सकता है लेकिन यह कम से कम सतह पर ऐसा लगता है।

JS को wasm में संकलित करने का कोई कारण नहीं है क्योंकि आपको एक संपूर्ण जावास्क्रिप्ट vm भी शामिल करना होगा। परिणामी कोड मूल रूप से प्रदान किए गए JS VM की तुलना में बहुत बड़ा और धीमा होगा।

क्या हम JS VMs द्वारा प्रोफाइल-गाइडेड ऑप्टिमाइज़ेशन के माध्यम से किए गए सभी मोनोमोर्फिज़ेशन आदि नहीं कर सकते थे? हम बहुत कुछ वैसा ही करेंगे जैसा कि जेएस वीएम रनटाइम पर करते हैं, लेकिन समय से पहले।

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

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

पीजीओ को आपके कार्यक्रम के लिए बेहतरीन परीक्षण कवरेज की आवश्यकता थी। यह हमेशा संभव नहीं होता है। लेकिन आप v8 में निष्पादन के दौरान कुछ प्रकार की जानकारी का पता लगा सकते हैं। यह दस्तावेज़ देखें: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

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

प्रकार की आवश्यकता नहीं है

क्या QuickJS को वास्तव में WASM में संकलित किया जा सकता है?

हाँ, Figma उदाहरण के लिए अपने प्लगइन सिस्टम के लिए QuickJS का उपयोग करता है

और इसका उपयोग http://numcalc.com/ में भी किया जाता है।