OpenXLA में योगदान देना

OpenXLA में कोई भी योगदान दे सकता है. हम सभी के योगदान की कद्र करते हैं. योगदान करने के कई तरीके हैं. जैसे:

• OpenXLA के डिसकशन फ़ोरम (openxla-discuss) पर सवालों के जवाब देना

• OpenXLA के दस्तावेज़ों को बेहतर बनाना या उनमें ज़्यादा जानकारी जोड़ना

• OpenXLA के कोड-बेस में योगदान देना

• OpenXLA पर बनी लाइब्रेरी के बड़े नेटवर्क में, ऊपर बताए गए किसी भी तरीके से योगदान देना

OpenXLA प्रोजेक्ट, Google के ओपन सोर्स कम्यूनिटी दिशा-निर्देशों का पालन करता है.

शुरू करने से पहले

Contributor के लाइसेंस से जुड़े कानूनी समझौते पर हस्ताक्षर करना

इस प्रोजेक्ट में योगदान देने के लिए, योगदान देने वाले का लाइसेंस समझौता (सीएलए) होना ज़रूरी है. आपके पास (या आपको नौकरी देने वाली कंपनी के पास) आपके योगदान का कॉपीराइट रहता है. इससे हमें सिर्फ़ इस बात की अनुमति मिलती है कि हम आपके योगदान का इस्तेमाल कर सकें और उन्हें प्रोजेक्ट के हिस्से के तौर पर फिर से डिस्ट्रिब्यूट कर सकें.

अगर आपने या आपकी मौजूदा कंपनी ने पहले ही Google CLA पर हस्ताक्षर कर दिए हैं, तो आपको शायद इसे फिर से साइन करने की ज़रूरत नहीं है. भले ही, यह किसी दूसरे प्रोजेक्ट के लिए किया गया हो.

अपने मौजूदा समझौते देखने या नया समझौता साइन करने के लिए, <https://cla.developers.google.com/> पर जाएं.

आचार संहिता पढ़ें

यह प्रोजेक्ट, Tensorflow की आचार संहिता का पालन करता है.

योगदान देने की प्रोसेस

डेवलपर गाइड

OpenXLA के लिए डेवलपमेंट एनवायरमेंट सेट अप करने के तरीके के बारे में जानने के लिए, कृपया डेवलपर गाइड देखें. इसमें कोड पाने, उसे बनाने, टेस्ट चलाने, और बदलाव सबमिट करने के बारे में जानकारी शामिल है.

योगदान करने से जुड़ी गाइड

कंपाइलर के आर्किटेक्चर में ये कॉम्पोनेंट शामिल होते हैं.

ऑप्टिमाइज़ेशन पास

ऑप्टिमाइज़ेशन पास, कंप्यूटेशनल क्षमता को बेहतर बनाने के लिए, एचएलओ पर ट्रांसफ़ॉर्मेशन लागू करते हैं. ये बदलाव, आर्किटेक्चर से जुड़े नहीं होते. साथ ही, ये हाई-लेवल के सुधार होते हैं. इनमें हार्डवेयर के हिसाब से किए गए बदलाव भी शामिल होते हैं. जैसे, NVIDIA GPU के लिए किए गए बदलाव.

आम तौर पर, हम ये स्वीकार करते हैं:

• ऐसे पास जो कई वर्कलोड पर लागू होते हैं और परफ़ॉर्मेंस बेंचमार्क पर साफ़ तौर पर और काफ़ी हद तक पॉज़िटिव असर डालते हैं.

हम आम तौर पर इन चीज़ों को अस्वीकार करते हैं:

• यह पास, खास मॉडल को टारगेट करने वाले यूनीक ऑप्टिमाइज़ेशन करता है.

फ़्यूज़न पास

फ़्यूज़न एक अहम ऑप्टिमाइज़ेशन है. यह मेमोरी I/O और कर्नल लॉन्च के ओवरहेड को कम करने के लिए, कई HLO ऑपरेशनों को एक कर्नल में जोड़ता है.

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

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

हॉरिज़ॉन्टल स्केलिंग

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

हम ऐसे बदलावों को प्राथमिकता देते हैं जिनमें कम से कम जोखिम हो.

आम तौर पर, हम ये स्वीकार करते हैं:

• इंटर-जीपीयू या इंटरहोस्ट कम्यूनिकेशन को मैनेज करने वाली लाइब्रेरी में अपडेट.

• नए प्लैटफ़ॉर्म के लिए, परफ़ॉर्मेंस टेबल से जुड़े अपडेट.

हम आम तौर पर इन चीज़ों को अस्वीकार करते हैं:

• किसी मॉडल के हिसाब से, एचएलओ को फिर से लिखना या रनटाइम में बदलाव करना.

• इन्फ़्रास्ट्रक्चर में ऐसे बदलाव जिनसे नए फ़्लैग, तकनीकी कमियां या रिग्रेशन (सॉफ़्टवेयर में कोई नई समस्या आना) हो सकते हैं.

बैकएंड और ऑटो ट्यूनिंग

अननेस्टेड ऑपरेशंस, जैसे कि कस्टम कॉल और फ़्यूज़न के लिए बैकएंड को CodegenBackend इंटरफ़ेस लागू करना चाहिए.

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

// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
  GetSupportedConfigs(const HloInstruction& instr);

// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
  const HloInstruction& instr);

रनटाइम

XLA कंपाइलेशन पाइपलाइन का आखिरी नतीजा, थंक सीक्वेंस होता है. इसे क्रम से लगाया जा सकता है.

सभी नए थंक टाइप को क्रम से लगाया जा सकता है. इसका मतलब है कि GpuCompiler या CpuCompiler को प्रोग्राम को कंपाइल और क्रम से लगाने की सुविधा मिलनी चाहिए, ताकि बाद में XLA रनर प्रोग्राम को लोड और एक्ज़ीक्यूट कर सके. इसका मतलब है कि HloInstruction या कंपाइलर के अन्य हिस्सों या StreamExecutor के लिए कोई पॉइंटर नहीं होना चाहिए.

कोड स्टैंडर्ड

• कोडिंग स्टाइल: हम Google की कोड स्टाइल गाइड का पालन करते हैं. खास तौर पर, C/C++ और Python गाइड देखें. सबमिट किया गया हर कोड, इन स्टाइल गाइड के मुताबिक होना चाहिए.

• छोटे बदलाव: हम Google के इंजीनियरिंग के तरीकों का पालन करते हैं. खास तौर पर, कृपया बदलावों के बारे में कम शब्दों में जानकारी देने से जुड़ी गाइड देखें. ऐसा करने से, कोड को तेज़ी से मर्ज किया जा सकेगा. इसकी वजह यह है कि कोड की समीक्षा करना आसान हो जाएगा. साथ ही, बदलावों के अनचाहे साइड इफ़ेक्ट होने की संभावना कम हो जाएगी. अगर आपको कोई बड़ा बदलाव करना है, तो उसे छोटे-छोटे बदलावों में बांटने के लिए कई रणनीतियां उपलब्ध हैं.

• टेस्ट कवरेज: सभी बदलावों में, सही यूनिट टेस्ट शामिल होने चाहिए. यूनिट टेस्ट, किसी खास हार्डवेयर (सीपीयू, जीपीयू वगैरह) की टाइमिंग पर निर्भर नहीं होने चाहिए. साथ ही, टेस्ट को तय किए गए तरीके से और फ़ोकस के साथ करने के लिए, मॉक और फ़ेक का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए. मौजूदा कोड को बढ़ाने के लिए किए गए बदलावों की जांच करना मुश्किल होता है. इसलिए, जांच करने की सुविधा को बेहतर बनाने के लिए, ज़रूरी बदलाव किए जाने चाहिए.

  सभी बदलावों में, बदलाव के टाइटल में बेंचमार्क के सही नतीजे भी शामिल होने चाहिए, ताकि फ़ायदों के बारे में साफ़ तौर पर पता चल सके.

• अगर आपको कोड में इस्तेमाल किए गए नियमों के बारे में कोई शक है, तो पहले से मौजूद कोड की जांच करना हमेशा एक अच्छा विकल्प होता है. साथ ही, OpenXLA में पहले से मौजूद पैटर्न को फ़ॉलो करने की कोशिश करें.

समीक्षा करने की प्रोसेस

सभी सबमिशन की समीक्षा की जाती है. इनमें प्रोजेक्ट के सदस्यों के सबमिशन भी शामिल हैं. हम इस काम के लिए, GitHub पुल अनुरोधों का इस्तेमाल करते हैं. पुल अनुरोधों का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, GitHub सहायता केंद्र पर जाएं.

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

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

• समीक्षा की प्रोसेस के दौरान, स्कोप क्रीप से बचें. यह सबमिट करने वाले और समीक्षक, दोनों की ज़िम्मेदारी है. अगर कोई बदलाव बहुत बड़ा हो जाता है, तो उसे कई बदलावों में बांट दें.

• बदलाव को मर्ज करने से पहले, उसकी इंटरनल टेस्टिंग की जाएगी. इसके लिए, Google और अन्य हार्डवेयर वेंडर के इंटरनल कोड का इस्तेमाल किया जाएगा. अगर इंटरनल टेस्ट में ऐसी गड़बड़ियां मिलती हैं जिन्हें हमारा सार्वजनिक सीआई नहीं पकड़ पाता है, तो इससे समीक्षा की प्रक्रिया में अतिरिक्त चरण जुड़ सकते हैं. आपके बदलाव की समीक्षा करने वाला Googler, इंटरनल टेस्ट के फ़ेल होने की जानकारी देगा. साथ ही, यह भी बताएगा कि क्या ठीक करना है.

अक्सर पूछे जाने वाले सवाल

"बुनियादी ढांचे में हुए इस बदलाव का असर मेरे पीआर पर नहीं पड़ेगा. मुझे ऐसा क्यों करना चाहिए?"

XLA टीम के पास कोई इंफ़्रास्ट्रक्चर टीम नहीं है. इसलिए, हेल्पर लाइब्रेरी बनाने और तकनीकी समस्याओं से बचने की ज़िम्मेदारी हम सभी की है. हम इसे XLA में बदलाव करने की प्रक्रिया का एक सामान्य हिस्सा मानते हैं. साथ ही, हम उम्मीद करते हैं कि सभी लोग इसमें हिस्सा लेंगे. आम तौर पर, हम कोड लिखते समय ज़रूरत के हिसाब से इंफ़्रास्ट्रक्चर बनाते हैं.

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

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

"क्या हम आने वाले समय में पीआर के ज़रिए आपकी टिप्पणी का जवाब दे सकते हैं?"

पीआर में बुनियादी ढांचे से जुड़े अनुरोधों (या अन्य बड़े अनुरोधों) के बारे में अक्सर यह सवाल पूछा जाता है कि क्या बदलाव मूल पीआर में किया जाना चाहिए या क्या इसे आने वाले समय में फ़ॉलो-अप के तौर पर पीआर में किया जा सकता है.

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

XLA इस तरीके का इस्तेमाल कुछ वजहों से करता है.

• भरोसा: समीक्षक का भरोसा जीतना एक अहम हिस्सा है. ओपन-सोर्स प्रोजेक्ट में, योगदान देने वाले लोग अपनी मर्ज़ी से दिख सकते हैं या गायब हो सकते हैं. किसी पीआर को मंज़ूरी देने के बाद, समीक्षकों के पास यह पक्का करने का कोई तरीका नहीं होता कि वादा किए गए फ़ॉलो-अप वाकई में किए गए हैं.

• अन्य डेवलपर पर असर: अगर आपने XLA के किसी हिस्से में बदलाव करने के लिए पीआर भेजा है, तो इस बात की पूरी संभावना है कि अन्य लोग भी उसी हिस्से में बदलाव करने के लिए पीआर भेज रहे हों. अगर हम आपके पीआर में तकनीकी कर्ज़ को स्वीकार करते हैं, तो इस फ़ाइल को देखने वाले सभी लोगों पर इस कर्ज़ का असर पड़ेगा. ऐसा तब तक होगा, जब तक फ़ॉलो-अप सबमिट नहीं किया जाता.

• समीक्षक की बैंडविड्थ: बदलाव को फ़ॉलो-अप के लिए टालने से, पहले से ही ज़्यादा काम कर रहे समीक्षकों पर कई तरह के शुल्क लगते हैं. समीक्षकों को शायद यह याद न रहे कि पहला पीआर किस बारे में था. ऐसा इसलिए, क्योंकि वे फ़ॉलो-अप का इंतज़ार कर रहे थे. इससे अगली समीक्षा करना ज़्यादा मुश्किल हो जाता है. इसके अलावा, समीक्षकों को फ़ॉलो-अप की उम्मीदों पर भी नज़र रखनी होगी. साथ ही, यह पक्का करना होगा कि वे वाकई में हो रहे हैं. अगर बदलाव इस तरह से किया जा सकता है कि वह ओरिजनल पीआर से पूरी तरह से अलग हो, ताकि कोई दूसरा समीक्षक इसकी समीक्षा कर सके, तो बैंडविथ की समस्या कम होगी. हमारे अनुभव के हिसाब से, ऐसा बहुत कम होता है.