बाइनरी संगतता: अभी या कभी नहीं

वर्किंग ग्रुप 21 (WG21) में टाइटस विंटर्स के प्रकाशन का अनुवाद - सी ++ भाषा मानकीकरण समिति। लेखक एक महत्वपूर्ण मुद्दे पर चर्चा करता है: बैकवर्ड बाइनरी संगतता या एबीआई (एप्लीकेशन बाइनरी इंटरफ़ेस) के लिए समर्थन।

WG21 में पिछले वर्षों में, मैंने सक्रिय रूप से प्रचार किया है कि प्रगति पिछड़ी संगतता की तुलना में अधिक महत्वपूर्ण है। लेकिन मैं खुद अब इस पर विश्वास नहीं करता, विशेष रूप से द्विआधारी संगतता (एबीआई) को बनाए रखने के संबंध में। पिछले तीन रिलीज (C ++ 14, C ++ 17 और C ++ 20) में ABI उतना ही स्थिर था जितना हम कर पाए थे। भले ही WG21 C ++ 23 में ABI पिछड़ी संगतता को तोड़ने का फैसला करता है, हम 10 से अधिक वर्षों से कई प्लेटफार्मों पर द्विआधारी संगतता प्रदान कर रहे हैं। मेरी राय में, सॉफ्टवेयर सिस्टम के बड़े पैमाने पर फेरबदल में हीरम का कानून हावी है। अब आप यह नहीं बता सकते हैं कि कितने उपयोगकर्ताओं के पास एबीआई मानक पुस्तकालय की स्थिरता की धारणा है (कोई फर्क नहीं पड़ता कि कितना बुद्धिमान या कितना स्पष्ट या निहित है) दृढ़ता से "सबकोर्टेक्स में सिलना" है, शायद दुनिया में सी ++ डेवलपर्स के आधे।

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

अधिक महत्वपूर्ण बात, ABI सीमाओं के कारण, हम महत्वपूर्ण प्रदर्शन हानि को समाप्त नहीं कर सकते हैं। हम अनूठे_ptr को पास करने की महत्वपूर्ण लागत से छुटकारा नहीं पा सकते हैं [CppCon 2019 पर चांडलर की बात बाद में प्रकाशित की जाएगी], हम हर जगह सब कुछ फिर से इकट्ठा करने के लिए मजबूर किए बिना unDeded_map के लिए मेमोरी में std :: hash या वर्ग के प्लेसमेंट को नहीं बदल सकते। वर्षों से हैश के प्रदर्शन का बड़े पैमाने पर अध्ययन किया गया है और, तालिका में खोजों के अनुकूलन को ध्यान में रखते हुए और हैशिंग उचित है, हमें विश्वास है कि हम एक unordered_map / std :: हैश कार्यान्वयन प्रदान कर सकते हैं जो एपीआई संगत है और 200-300% प्रदर्शन को बढ़ावा देता है । लेकिन एबीआई प्रतिबंध इस बात की अनुमति नहीं देता है। SSO को std :: string के लिए अनुकूलन और ट्यूनिंग पर अतिरिक्त अध्ययन प्रदर्शन में गैर-तुच्छ वृद्धि का सुझाव देते हैं (माइक्रोबेनचर्च और स्केलिंग में 1%) - एपीआई प्रभावित नहीं है, लेकिन एबीआई प्रतिबंध इसे अनुमति नहीं देते हैं।

एबीआई द्वारा विशेष रूप से अवरुद्ध उत्पादकता का कुल नुकसान कई प्रतिशत अंक तक पहुंच जाता है - संभवतः 5-10% तक। यह कुछ ऐसा नहीं है जो पारिस्थितिकी तंत्र के रूप में एक पूरे के बिना नहीं कर सकता है, लेकिन यह कुछ संगठनों (उनके बीच Google) के लिए स्वीकार्य नहीं हो सकता है। यह, निश्चित रूप से, C ++ के लिए स्वीकार्य एक बड़ा प्रदर्शन नुकसान है: याद रखें कि यह एक ऐसी भाषा है जो दावा करती है कि यह अधिक उत्पादक प्रतियोगी के लिए कोई जगह नहीं छोड़ती है। अधिकांश उपयोगकर्ता इस प्रदर्शन में गिरावट के बारे में चिंतित नहीं दिखते हैं: निरपेक्ष प्रदर्शन के बारे में चिंतित लोगों के लिए अन्य हैश तालिका कार्यान्वयन हैं। मूल्य में unique_ptr पास करने और ABI भाषा की अन्य समस्याओं से संबंधित सामान्य अक्षमता बहुत कम कार्यों में सामने आती है। गैर-मानक पुस्तकालयों और गैर-मानक कॉन्फ़िगरेशन टूल का उपयोग करके संगठन जिन्हें अधिकतम उत्पादकता की आवश्यकता होती है, वे अपने तरीके से (और ऐसा कर सकते हैं) जा सकते हैं। यह स्वाभाविक है और इसे स्पष्ट रूप से समझा जाना चाहिए।

ABI में बदलाव से उपयोगकर्ताओं की अपेक्षाकृत बड़ी संख्या प्रभावित होगी। मुझे इन उपयोगकर्ताओं के एक महत्वपूर्ण अनुपात पर संदेह नहीं है कि एबीआई पर उनकी निर्भरता कितनी मजबूत है। Google के सर्वरों के पारिस्थितिक तंत्र में, लगभग सब कुछ स्रोत से एकत्र किया जाता है, कुछ बाहरी निर्भरताएं होती हैं और बड़े पैमाने पर रीफैक्टरिंग करने के लिए औसत अवसर से बेहतर होता है। लेकिन हमारे लिए भी, हाल ही में एबीआई-ब्रेकिंग में मानक पुस्तकालय की लागत 5-10 इंजीनियरिंग वर्ष में बदल गई।

संपूर्ण C ++ पारिस्थितिकी तंत्र के लिए ABI पिछड़ी संगतता को तोड़ने की कुल लागत को " मिलेनियम इंजीनियर " में अनुमानित रूप से अनुमानित किया जा सकता है: दुनिया में प्लग-इन, .so या dll के प्रत्येक प्रदाता के लिए पुनर्निर्माण का समन्वय करने के लिए भारी मानव संसाधनों की आवश्यकता होगी। C ++ 20 मॉड्यूल के कारण पारिस्थितिक तंत्र के पृथक्करण के साथ, C ++ 23 के विकास और कार्यान्वयन के समय में ABI को बदलने से पारिस्थितिक तंत्र का एक कठिन अलगाव हो सकता है।

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

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

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

संक्षेप में, WG21 के लिए तीन संभावनाएँ हैं:

1. यह तय करना कि ABI को किस रिलीज़ में बदला जाएगा C ++ 23 या C ++ 26 में कोई फर्क नहीं पड़ता। लोगों को चेतावनी दें और तुरंत उन स्थानों की पहचान करने में मदद करने के लिए उपकरण और निदान विकसित करें जो टूट जाएंगे। भविष्य के एबीआई परिवर्तनों का समर्थन करने के लिए अधिक सुसंगत प्रथाओं और उपकरणों पर ध्यान केंद्रित करता है। एबीआई को बदलने के परिणामों के लिए अपने उपयोगकर्ताओं को उजागर करने के लिए यह किसी विशेष कार्यान्वयनकर्ता के हित में नहीं है, यदि अन्य कार्यान्वयन नहीं करते हैं, तो एबीआई को बदलना भविष्य के उपयोगकर्ताओं के लाभ के लिए एक समन्वित गतिविधि होनी चाहिए। आदर्श रूप से, आपको सब कुछ तोड़ने की ज़रूरत है - यह स्पष्ट करने के लिए कि C ++ 23 मोड में संकलित कोड पिछले मोड में संकलित कोड के साथ असंगत है। यदि कोई पुनर्निर्माण के बिना कर सकता है, और दूसरों को लेआउट में या रन समय में त्रुटियां होंगी - यह केवल गलतफहमी और निराशा को बढ़ाएगा।
2. तय करें कि हम आज के अभ्यास को औपचारिक रूप देकर एबीआई स्थिरता के लिए प्रयास करते हैं। यह कई वर्षों से है जब मानक कार्यान्वयनकर्ताओं को एबीआई परिवर्तनों को तोड़ने का अधिकार था - हम पहले से ही डिजाइन शुद्धता और प्रदर्शन के ऊपर एबीआई पिछड़े संगतता सेट करते हैं। यदि हम इसे पहचानते हैं और उपयोगकर्ताओं को स्पष्ट रूप से बताते हैं, तो पारिस्थितिकी तंत्र बेहतर होगा। अतिरिक्त पुस्तकालयों का मूल्य उन लोगों के लिए बढ़ेगा जिन्हें प्रदर्शन की अंतिम बूंदों को निचोड़ने की आवश्यकता है, लेकिन मानक द्वारा प्रदान की गई स्थिरता की आवश्यकता नहीं है। अन्य प्रदर्शन-उन्मुख भाषाएँ भविष्य में हमारी स्थिति को चुनौती दे सकती हैं।
3. एक दिशा चुनने और यथास्थिति को बचाने में सक्षम नहीं हो रहा है। मेरे लिए यह सबसे खराब स्थिति है: हम एबीआई पिछड़ी अनुकूलता पर अधिक ध्यान देना चाहते हैं। हम कहते हैं "प्रदर्शन" और वोट "बाइनरी संगतता"। इस तरह की असहमति पारिस्थितिकी तंत्र को परेशान करती है और इसका मतलब है कि भाषा की प्राथमिकताओं पर समझौते की कमी। मुझे पूरी उम्मीद है कि कार्यान्वयनकर्ताओं और महानिदेशकों के प्रयासों के माध्यम से, हम आवश्यक आम सहमति तक पहुंचेंगे।

मेरा मानना ​​है कि विकल्प नंबर 1 उन उपयोगकर्ताओं के लिए बेहतर है, जिन्हें अधिकतम प्रदर्शन की आवश्यकता है, लेकिन इसकी पारिस्थितिकी तंत्र के लिए अविश्वसनीय लागत है और इससे भविष्य में भाषा का विखंडन हो सकता है। विकल्प संख्या 2 एक उबाऊ, जिम्मेदार और योग्य विकल्प है: यह स्वीकार करना दुखद है कि हमने खुद को कमरे के कोने में चित्रित किया और इससे जुड़े नुकसानों को कम करने का प्रयास किया। विकल्प # 3 को चुनने का मतलब प्रबंधन नहीं है, और मैं प्रार्थना करता हूं कि इससे बचा जाएगा: कोई भी स्पष्ट विकल्प मौजूदा असंगति और दीर्घकालिक लक्ष्यों की पसंद पर समझौते तक पहुंचने में असमर्थता से बेहतर है।

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