डाइनैमिक एक्ज़ीक्यूशन की सुविधा बेज़ल की है. यह वर्शन 0.21 के बाद के वर्शन में है. इसमें एक ही कार्रवाई को लोकल और रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा एक साथ शुरू की जाती है. ऐसा करने के लिए, खत्म होने वाली पहली ब्रांच के आउटपुट का इस्तेमाल किया जाता है और दूसरी ब्रांच को रद्द किया जाता है. यह रिमोट बिल्ड सिस्टम की एक्ज़ीक्यूशन पावर और/या शेयर की गई कैश मेमोरी के साथ-साथ, लोकल नेटवर्क पर एक्ज़ीक्यूशन करने में लगने वाले समय को कम करता है. इससे, दोनों तरह के बेहतरीन बिल्ड मिलते हैं और ये दोनों काम एक जैसे तरीकों से किए जा सकते हैं.
इस पेज पर डाइनैमिक एक्ज़ीक्यूशन को चालू करने, ट्यून करने, और डीबग करने का तरीका बताया गया है. अगर आपने लोकल और रिमोट, दोनों तरह के एक्ज़ीक्यूशन सेट अप किए हैं और बेहतर परफ़ॉर्मेंस के लिए, Basel की सेटिंग में बदलाव करना है, तो यह पेज आपके लिए है. अगर आपने पहले से रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा को सेट अप नहीं किया है, तो सबसे पहले 'बेज़ल' रिमोट एक्ज़िक्यूशन की खास जानकारी पर जाएं.
डाइनैमिक एक्ज़ीक्यूशन चालू हो रहा है?
डाइनैमिक एक्ज़ीक्यूशन मॉड्यूल बेज़ल का हिस्सा है, लेकिन डाइनैमिक एक्ज़ीक्यूशन का इस्तेमाल करने के लिए, आपको एक ही बेज़ल सेटअप से, लोकल और रिमोट, दोनों तरीकों से कंपाइल करने की सुविधा पहले से ही मिलनी चाहिए.
डाइनैमिक एक्ज़ीक्यूशन मॉड्यूल को चालू करने के लिए, --internal_spawn_scheduler
फ़्लैग को Bagel को पास करें. ऐसा करने पर, प्लान लागू करने की नई रणनीति जुड़ जाती है, जिसका नाम dynamic है. अब इसका इस्तेमाल उन चीज़ों के लिए रणनीति के तौर पर किया जा सकता है जिन्हें आपको डाइनैमिक तरीके से चलाना है, जैसे कि --strategy=Javac=dynamic. अगले सेक्शन में जाकर यह चुनने का तरीका जानें कि
यादगार चीज़ों के लिए, डाइनैमिक तरीके से एक्ज़ीक्यूट करने की सुविधा चालू करनी है.
डाइनैमिक रणनीति का इस्तेमाल करने वाली किसी भी याद के लिए, रिमोट तरीके से लागू करने की रणनीतियों को --dynamic_remote_strategy फ़्लैग से और स्थानीय रणनीतियों को --dynamic_local_strategy फ़्लैग से लिया जाता है. पासिंग --dynamic_local_strategy=worker,sandboxed, डाइनैमिक एक्ज़ीक्यूशन की लोकल ब्रांच के लिए डिफ़ॉल्ट तौर पर सेट हो जाती है, ताकि उस ऑर्डर में वर्कर या सैंडबॉक्स की गई एक्ज़ीक्यूशन के साथ कोशिश की जा सके. --dynamic_local_strategy=Javac=worker को पास करना, सिर्फ़ Javac मेनेमोनिक के लिए डिफ़ॉल्ट सेटिंग को ओवरराइड करता है. रिमोट वर्शन इसी तरह से काम करता है. दोनों फ़्लैग एक से ज़्यादा बार तय किए जा सकते हैं. अगर किसी कार्रवाई को स्थानीय तौर पर लागू नहीं किया जा सकता है, तो उसे रिमोट तरीके से सामान्य तरीके से और दूसरी जगह से लागू किया जाता है.
अगर आपके रिमोट सिस्टम में कोई कैश मेमोरी है, तो --local_execution_delay फ़्लैग, लोकल एक्ज़ीक्यूशन में मिलीसेकंड में देरी जोड़ता है. ऐसा तब होता है, जब रिमोट सिस्टम के कैश हिट होने का संकेत मिलता है. इससे, ज़्यादा कैश हिट
होने की संभावना होने पर लोकल एक्ज़ीक्यूशन नहीं चलता. डिफ़ॉल्ट वैल्यू 1000 मि॰से॰ है. हालांकि, इसे इस तरह से मैनेज करना चाहिए कि आम तौर पर कैश मेमोरी में लगने वाले हिट से कुछ ज़्यादा समय लगे. सही समय, रिमोट सिस्टम और दोतरफ़ा यात्रा, दोनों पर निर्भर करता है. आम तौर पर, किसी रिमोट सिस्टम का इस्तेमाल करने वाले सभी लोगों के लिए
वैल्यू एक ही रहेगी. हालांकि, ऐसा तब तक होगा, जब तक उनमें से कुछ उपयोगकर्ता, दोतरफ़ा यात्रा का समय
जोड़ने के लिए काफ़ी न हों. बेज़ल प्रोफ़ाइलिंग की सुविधाओं का इस्तेमाल करके, यह देखा जा सकता है कि आम तौर पर कैश मेमोरी में सेव होने वाले हिट में कितना समय लगता है.
डाइनैमिक एक्ज़ीक्यूशन का इस्तेमाल, लोकल सैंडबॉक्स वाली रणनीति के साथ-साथ परसिस्टेंट वर्कर के साथ भी किया जा सकता है. डाइनैमिक एक्ज़ीक्यूशन के साथ इस्तेमाल किए जाने पर, स्थायी वर्कर अपने-आप सैंडबॉक्स की सुविधा के साथ चलेंगे और मल्टीप्लेक्स वर्कर का इस्तेमाल नहीं कर पाएंगे. डार्विन और Windows सिस्टम पर,
सैंडबॉक्स की गई रणनीति धीमी हो सकती है. इन सिस्टम पर सैंडबॉक्स बनाने के काम को कम करने के लिए, --reuse_sandbox_directories को पास किया जा सकता है.
डाइनैमिक एक्ज़ीक्यूशन को standalone रणनीति के साथ भी चलाया जा सकता है. हालांकि, एक्ज़ीक्यूट करने पर standalone रणनीति को आउटपुट लॉक लेना चाहिए, इसलिए यह रिमोट रणनीति को पहले पूरा होने से असरदार तरीके से ब्लॉक करता है. --experimental_local_lockfree_output फ़्लैग, लोकल एक्ज़ीक्यूशन को सीधे आउटपुट पर लिखने की अनुमति देकर, इस समस्या को हल करने का तरीका बताता है. हालांकि, अगर यह पहले पूरा होता है, तो रिमोट तरीके से एक्ज़ीक्यूट किया जा सकता है.
अगर डाइनैमिक एक्ज़ीक्यूशन की कोई एक ब्रांच पहले पूरी हो जाती है, लेकिन वह पूरी नहीं हो पाती है, तो पूरी कार्रवाई नहीं हो पाती. यह फ़ैसला सोच-समझकर लिया गया है, ताकि लोकल और ऑफ़िस से दूर रहकर काम करने की सुविधा के बीच के अंतर को किसी की नज़र न आए.
डाइनैमिक एक्ज़ीक्यूशन और लॉक करने की सुविधा के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, जूलियो मेरिनो की शानदार ब्लॉग पोस्ट देखें
मुझे डाइनैमिक एक्ज़ीक्यूशन का इस्तेमाल कब करना चाहिए?
डाइनैमिक एक्ज़ीक्यूशन के लिए, रिमोट एक्ज़ीक्यूशन सिस्टम के किसी फ़ॉर्म की ज़रूरत होती है. फ़िलहाल, सिर्फ़ कैश मेमोरी वाले रिमोट सिस्टम का इस्तेमाल नहीं किया जा सकता, क्योंकि कैश मेमोरी में सेव न होने पर, इसे फ़ेल माना जाएगा.
रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, सभी तरह की कार्रवाइयां सही नहीं होती हैं. सबसे अच्छे उम्मीदवार वे होते हैं जो स्थानीय तौर पर ज़्यादा तेज़ी से काम करते हैं. उदाहरण के लिए, स्थायी कर्मचारियों का इस्तेमाल करना. इसके अलावा, वे ऐसे कैंडिडेट होते हैं जो इतने तेज़ी से काम करते हैं कि प्रोग्राम चलाने के दौरान, रिमोट एक्ज़ीक्यूशन के समय को प्राथमिकता दी जाए. स्थानीय तौर पर लागू की जाने वाली हर कार्रवाई, कुछ सीपीयू और मेमोरी रिसॉर्स को लॉक करती है. इसलिए, जो कार्रवाइयां उन कैटगरी में नहीं आती हैं उन्हें चलाने में सिर्फ़ देरी होती है.
5.0.0-pre.20210708.4 रिलीज़ के बाद से, परफ़ॉर्मेंस प्रोफ़ाइलिंग में कर्मचारियों के काम को पूरा करने से जुड़ा डेटा शामिल होता है. इसमें, डाइनैमिक एक्ज़ीक्यूशन की दौड़ में हारने के बाद, काम का अनुरोध पूरा करने में लगने वाला समय भी शामिल होता है. अगर आपको डाइनैमिक एक्ज़ीक्यूशन
वर्जन के ऐसे थ्रेड दिखते हैं जो संसाधन हासिल करने में ज़्यादा समय बिता रहे हैं या
async-worker-finish में बहुत ज़्यादा समय
हो सकता है, तो हो सकता है कि कुछ लोकल ऐक्शन की वजह से वर्कर थ्रेड को
देरी हो रही हो.
ऊपर दी गई प्रोफ़ाइल में, जो 8 Javac वर्कर का इस्तेमाल करती है, हमने देखा है कि कई Javac वर्कर ने async-worker-finish थ्रेड पर अपनी रेस हार गई हैं और अपना काम पूरा किया है. ऐसा इसलिए हुआ, क्योंकि काम न करने वाले लोगों को याद करने के लिए ज़रूरी संसाधन
ले जाने थे और काम करने में देरी हुई.
जब सिर्फ़ Javac को डाइनैमिक एक्ज़ीक्यूशन के साथ चलाया जाता है, तो काम शुरू करने के बाद सिर्फ़ आधे कर्मचारी ही रेस में हारते हैं.
पहले सुझाए गए --experimental_spawn_scheduler फ़्लैग का इस्तेमाल नहीं किया जा सकता.
यह डाइनैमिक एक्ज़ीक्यूशन को चालू करता है और dynamic को याद रखने की चीज़ों के लिए डिफ़ॉल्ट रणनीति के तौर पर सेट करता है. इससे इस तरह की समस्याएं अक्सर पैदा होती हैं.
समस्या हल करना
डाइनैमिक एक्ज़ीक्यूशन से जुड़ी समस्याएं छोटी और डीबग करने में मुश्किल हो सकती हैं, क्योंकि ये
लोकल और रिमोट एक्ज़ीक्यूशन के कुछ ही खास कॉम्बिनेशन के तहत आ सकती हैं.
--debug_spawn_scheduler, डाइनैमिक एक्ज़ीक्यूशन सिस्टम से अतिरिक्त आउटपुट जोड़ता है. इससे इन समस्याओं को डीबग करने में मदद मिल सकती है. समस्याओं को आसानी से समझने के लिए, --local_execution_delay फ़्लैग और रिमोट जॉब की संख्या बनाम लोकल जॉब की संख्या में भी बदलाव किया जा सकता है.
अगर आपको standalone रणनीति का इस्तेमाल करके डाइनैमिक एक्ज़ीक्यूशन में समस्याएं आ रही हैं, तो --experimental_local_lockfree_output के बिना दौड़ने की कोशिश करें या सैंडबॉक्स की गई अपनी लोकल ऐक्शन को चलाएं. यह आपके बिल्ड को धीमा कर सकता है (ऊपर देखें कि क्या आप Mac या Windows पर हैं), लेकिन इसके विफल होने की कुछ संभावित वजहें भी हट जाती हैं.