Libdispatch का प्रभावी उपयोग

( नोट: मूल सामग्री के लेखक, गिथब और ट्विटर के एक उपयोगकर्ता थॉमस @ क्लेमेंटलदेव हैं। लेखक द्वारा उपयोग किया गया पहला व्यक्ति नीचे दिए गए अनुवाद में सहेजा गया है। )

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

• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/date.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/date.html

उन्होंने इस विषय पर कई ट्वीट भी किए:

• twitter.com/pedantcoder

मेरे द्वारा बनाया गया:

• कार्यक्रम में वैश्विक पूल ( धागे - लगभग प्रति ) का उपयोग करके बहुत कम कतारें होनी चाहिए। यदि ये सभी कतारें एक साथ सक्रिय हैं, तो आपको एक ही संख्या में एक साथ चलने वाले धागे प्राप्त होंगे। इन कतारों को कार्यक्रम (जीयूआई, भंडारण, पृष्ठभूमि में काम, ...) के रूप में निष्पादन संदर्भों के रूप में माना जाना चाहिए जो समवर्ती निष्पादन से लाभान्वित होते हैं।
• अनुक्रमिक निष्पादन के साथ शुरू करें। जब आपको प्रदर्शन समस्या का पता चलता है, तो इसका कारण जानने के लिए माप लें। और अगर समानांतर निष्पादन मदद करता है, तो इसे सावधानी से उपयोग करें। हमेशा पुष्टि करें कि समानांतर कोड सिस्टम के दबाव में काम कर रहा है। डिफ़ॉल्ट रूप से, कतारों का पुन: उपयोग करें। जब यह औसत दर्जे का लाभ लाता है तो लाइनें जोड़ें। अधिकांश अनुप्रयोगों को तीन से चार कतारों से अधिक का उपयोग नहीं करना चाहिए।
• ऐसी कतारें जो लक्ष्य के रूप में एक और कतार निर्धारित करती हैं, अच्छी तरह से और पैमाने पर काम करती हैं।
  ( नोट पेरेव।: दूसरी कतार के लिए लक्ष्य के रूप में एक पंक्ति निर्धारित करने के बारे में, उदाहरण के लिए, यहां पढ़ा जा सकता है । )
• Dispatch_get_global_queue () का उपयोग न करें। यह सेवा की गुणवत्ता और प्राथमिकताओं के अनुकूल नहीं है और इससे प्रवाह की संख्या में विस्फोटक वृद्धि हो सकती है। इसके बजाय, अपने कोड को अपने निष्पादन संदर्भों में चलाएं।
• dispatch_async () छोटे निष्पादन योग्य ब्लॉकों (<1 ms) के लिए संसाधनों की बर्बादी है, क्योंकि इस कॉल में libdispatch के अत्यधिक उत्साह के कारण नए धागे के निर्माण की आवश्यकता होगी। साझा राज्य की सुरक्षा के लिए निष्पादन के संदर्भ को बदलने के बजाय, एक ही समय में साझा राज्य तक पहुंचने के लिए लॉक तंत्र का उपयोग करें।
• कुछ वर्गों / पुस्तकालयों को अच्छी तरह से डिज़ाइन किया गया है कि वे निष्पादन के संदर्भ का पुन: उपयोग करते हैं कि कॉलिंग कोड उनके पास जाता है। यह धागा सुरक्षा सुनिश्चित करने के लिए पारंपरिक लॉकिंग के उपयोग की अनुमति देता है। os_unfair_lock आमतौर पर सिस्टम में सबसे तेज़ लॉकिंग तंत्र है: यह प्राथमिकताओं के साथ बेहतर काम करता है और कम संदर्भ स्विच का कारण बनता है।
• समानांतर निष्पादन के मामले में, आपके कार्यों को आपस में संघर्ष नहीं करना चाहिए, अन्यथा उत्पादकता तेजी से गिरती है। लड़ना कई रूप लेता है। स्पष्ट मामला: ताला को पकड़ने के लिए संघर्ष। लेकिन वास्तव में, इस तरह की लड़ाई का मतलब एक साझा संसाधन का उपयोग करने से ज्यादा कुछ नहीं है, जो एक अड़चन बन जाता है: आईपीसी (इंटरप्रोसेस संचार) / ओएस डेमोंस, मैलाक (अवरुद्ध), साझा मेमोरी, आई / ओ।
• धागे की संख्या में विस्फोटक वृद्धि से बचने के लिए आपको अतुल्यकालिक रूप से निष्पादित करने के लिए सभी कोड की आवश्यकता नहीं है। सीमित संख्या में कम कतारों का उपयोग करना और डिस्पैच_गेट_ग्लोबल_क्यू () का उपयोग करने से मना करना बेहतर है।
  ( नोट perev। 1: जाहिरा तौर पर, यह एक ऐसा मामला है जब थ्रेड की संख्या में विस्फोटक वृद्धि तब होती है जब बड़ी संख्या में समानांतर कार्यों को सिंक्रनाइज़ किया जाता है "यदि मेरे पास बहुत सारे ब्लॉक हैं और वे सभी इंतजार करना चाहते हैं, तो हम वह प्राप्त कर सकते हैं जिसे हम थ्रेड कहते हैं विस्फोट। " )
  ( नोट पृष्ठ 2: चर्चा से यह समझा जा सकता है कि पियरे हबज़िट का मतलब उन कतारों से है जो "कर्नेल के बारे में जानते हैं जब उनके पास काम होता है" निचली कतारों के तहत। यहाँ हम ओएस के कर्नेल के बारे में बात कर रहे हैं। )
• हमें उस जटिलता और कीड़े के बारे में नहीं भूलना चाहिए जो अतुल्यकालिक निष्पादन और कॉलबैक से भरी वास्तुकला में उत्पन्न होते हैं। क्रमिक रूप से निष्पादन योग्य कोड पढ़ना, लिखना और बनाए रखना बहुत आसान है।
• अनुक्रमिक वाले की तुलना में प्रतिस्पर्धी कतारें कम अनुकूलित हैं। यदि आप प्रदर्शन लाभ को माप रहे हैं, तो उनका उपयोग करें, अन्यथा यह समयपूर्व अनुकूलन है।
• यदि आपको एसिंक्रोनस रूप से और सिंक्रोनस दोनों में एक कतार में कार्य भेजने की आवश्यकता है, तो इसके बजाय dispatch_sync () का उपयोग करें डिस्पैच_सुंक_आंड_वाइट () का उपयोग करें। dispatch_async_and_wait () उस थ्रेड पर निष्पादन की गारंटी नहीं देता है जिससे कॉल उत्पन्न हुई, जो लक्ष्य पंक्ति के सक्रिय होने पर संदर्भ स्विचिंग को कम कर देता है।
  ( नोट अनुवाद। 1: वास्तव में डिस्पैच_sync () भी गारंटी नहीं देता है, इसके बारे में प्रलेखन केवल यह बताता है कि "वर्तमान थ्रेड पर एक ब्लॉक निष्पादित करता है, जब भी संभव हो। एक अपवाद के साथ: मुख्य कतार में भेजे गए ब्लॉक को हमेशा मुख्य थ्रेड पर निष्पादित किया जाता है। " )
  ( नोट अनुवाद। 2: प्रेषण के बारे में_ प्रलेखन में और स्रोत कोड में )
• सही ढंग से 3-4 कोर का उपयोग करना इतना आसान नहीं है। वास्तव में कोशिश करने वालों में से अधिकांश उत्पादकता में मामूली वृद्धि के लिए स्केलिंग और अपशिष्ट ऊर्जा का सामना नहीं कर सकते हैं। प्रोसेसर ओवरहीटिंग के साथ कैसे काम करते हैं, यह मदद नहीं करेगा। उदाहरण के लिए, इंटेल टर्बो-बूस्ट को अक्षम कर देगा यदि पर्याप्त कोर का उपयोग किया जाता है।
• वास्तविक दुनिया में अपने उत्पाद के प्रदर्शन को मापें, यह सुनिश्चित करने के लिए कि आप इसे तेज़ बना रहे हैं, धीमा नहीं। सूक्ष्म प्रदर्शन परीक्षणों से सावधान रहें - वे कैश के प्रभाव को छिपाते हैं और थ्रेड पूल को गर्म रखते हैं। यह जांचने के लिए कि आप क्या कर रहे हैं, आपके पास हमेशा एक मैक्रो टेस्ट होना चाहिए।
• कामवासना प्रभावी है, लेकिन चमत्कार नहीं हैं। संसाधन अनंत नहीं हैं। आप ओएस और हार्डवेयर की वास्तविकता को अनदेखा नहीं कर सकते हैं जिस पर कोड निष्पादित किया गया है। इसके अलावा, प्रत्येक कोड अच्छी तरह से समानांतर नहीं है।

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

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

मैंने इन दिशानिर्देशों का पालन करने से व्यक्तिगत रूप से भारी सुधार देखा।
(अत्यधिक लोड किए गए कार्यक्रमों में)। यह एक नया दृष्टिकोण है, लेकिन इसके लायक है।

अधिक लिंक

कार्यक्रम में वैश्विक पूल का उपयोग करते हुए बहुत कम कतारें होनी चाहिए

• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039368.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039405.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039410.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039420.html

( नोट perev।: अंतिम लिंक को पढ़कर, क्रिस लट्टनर के साथ पियरे हबुज़िट के पत्राचार के बीच से एक टुकड़ा को रोक नहीं सका और स्थानांतरित कर दिया। नीचे 039420.html में पियरे हबुज़िट के उत्तरों में से एक है।

<...>
मैं समझता हूं कि मेरे लिए अपनी बात मनवाना कठिन है, क्योंकि मैं भाषा वास्तुकला में एक आदमी नहीं हूं, मैं सिस्टम आर्किटेक्चर में एक लड़का हूं। और मैं निश्चित रूप से अभिनेताओं को यह समझने के लिए पर्याप्त नहीं हूं कि उन्हें ओएस में कैसे एकीकृत किया जाए। लेकिन मेरे लिए, डेटाबेस उदाहरण पर लौटते हुए, अभिनेता-डेटाबेस-डेटा, या पहले के पत्राचार से अभिनेता-नेटवर्क-इंटरफ़ेस, इस SQL ​​क्वेरी या इस नेटवर्क क्वेरी से अलग हैं। पहले ऐसी इकाइयाँ हैं जिनके बारे में OS को कर्नेल में जानना चाहिए। जबकि SQL क्वेरी या नेटवर्क क्वेरी सिर्फ पहले स्थान पर निष्पादन के लिए कतारबद्ध अभिनेता हैं। दूसरे शब्दों में, ये शीर्ष स्तर के अभिनेता अलग-अलग हैं क्योंकि वे शीर्ष-स्तर हैं, सीधे कर्नेल / निम्न-स्तरीय रनटाइम के शीर्ष पर। और यही वह सार है जिसके बारे में कोर को तर्क करने में सक्षम होना चाहिए। यह उन्हें महान बनाता है।

प्रेषण पुस्तकालय में 2 प्रकार की कतारें और इसी एपीआई स्तर हैं:

• वैश्विक कतारें जो दूसरों की तरह कतार नहीं हैं। और वास्तव में, वे केवल थ्रेड पूल पर एक अमूर्त हैं।
• अन्य सभी कतारें जो आप चाहते हैं के रूप में एक दूसरे के लिए लक्ष्य निर्धारित कर सकते हैं।

आज यह स्पष्ट हो गया है कि यह एक गलती थी और इसमें 3 प्रकार की कतारें होनी चाहिए:

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

प्रेषण विकास समूह में, हम हर गुजरते दिन पछताते हैं कि दूसरे और तीसरे समूह की कतारों के बीच का अंतर शुरू में एपीआई में स्पष्ट नहीं किया गया था।

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

• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039429.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039461.html

अनुक्रमिक निष्पादन के साथ शुरू करें।

• twitter.com/pedantcoder/status/1081658384577835009
• twitter.com/pedantcoder/status/1081659784841969665
• twitter.com/pedantcoder/status/904839926180569089
• twitter.com/pedantcoder/status/904840156330344449

वैश्विक कतारों का उपयोग न करें

• twitter.com/pedantcoder/status/773903697474486273
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039368.html

प्रतिस्पर्धी लाइनों से सावधान रहें

• twitter.com/pedantcoder/status/960915209584914432
• twitter.com/pedantcoder/status/960916427833163776

साझा स्थिति की सुरक्षा के लिए एसिंक्स कॉल का उपयोग न करें

• twitter.com/pedantcoder/status/820473404440489984
• twitter.com/pedantcoder/status/820473580819337219
• twitter.com/pedantcoder/status/820740434645221376
• twitter.com/pedantcoder/status/904467942208823296
• twitter.com/pedantcoder/status/904468363149099008
• twitter.com/pedantcoder/status/820473711606124544
• twitter.com/pedantcoder/status/820473923527589888

छोटे कार्यों के लिए एसिंक्स कॉल का उपयोग न करें

• twitter.com/pedantcoder/status/1081657739451891713
• twitter.com/pedantcoder/status/1081642189048840192
• twitter.com/pedantcoder/status/1081642631732457472
• twitter.com/pedantcoder/status/1081648778975707136

कुछ वर्गों / पुस्तकालयों को केवल समकालिक होना चाहिए

• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039461.html

आपस में समानांतर कार्यों का संघर्ष उत्पादकता का हत्यारा है

• twitter.com/pedantcoder/status/1081657739451891713
• twitter.com/pedantcoder/status/1081658172610293760

गतिरोध से बचने के लिए, जब आप एक साझा स्थिति की रक्षा करने की आवश्यकता हो तो लॉकिंग तंत्र का उपयोग करें

• twitter.com/pedantcoder/status/744269824079998977
• twitter.com/pedantcoder/status/744269947723866112

एक अतुल्यकालिक कार्य की प्रतीक्षा करने के लिए सेमाफोर का उपयोग न करें

• twitter.com/pedantcoder/status/1175062243806863360

NSOperation API में कुछ गंभीर नुकसान होते हैं जो प्रदर्शन में गिरावट ला सकते हैं।

• twitter.com/pedantcoder/status/1082097847653154817
• twitter.com/pedantcoder/status/1082111968700289026
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039415.html

माइक्रो परफॉर्मेंस टेस्ट से बचें

• twitter.com/pedantcoder/status/1081660679054999552
• twitter.com/Catfish_Man/status/1081673457182490624

संसाधन असीमित नहीं हैं

• twitter.com/pedantcoder/status/1081661310771712001
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039410.html
• lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039429.html

Dispatch_async_and_wait () के बारे में

• twitter.com/pedantcoder/status/1135938715098857477

3-4 कोर का उपयोग करना आसान नहीं है

• twitter.com/pedantcoder/status/1140041360868704256

IOS 12 में कई प्रदर्शन सुधार एकल-थ्रेडेड डेमॉन के साथ प्राप्त किए गए हैं

• twitter.com/Catfish_Man/status/1081673457182490624