अच्छा मल्टीथ्रेड डिजाइन समयपूर्व अनुकूलन है?

Question

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

लेकिन दूसरी तरफ आमतौर पर सभी प्रणालियों में कुछ प्रदर्शन की ज़रूरत होती है और इसे बाद में बहुसंख्यक सुरक्षित संचालन में पुन: सक्रिय करना मुश्किल होता है या यहां तक ​​कि आर्थिक रूप से संभव नहीं है क्योंकि यह एक और एल्गोरिदम के साथ एक पूर्ण पुनर्लेखन होगा।

अनुकूलन और चीजों को पूरा करने के बीच संतुलन रखने का आपका तरीका क्या है?

Answer 1

मेरा मानना ​​है कि थ्रेडिंग ऑप्टिमाइज़ेशन के नियमों का भी पालन करता है।
यही है, अपने समय को त्वरित संचालन समानांतर बनाने में बर्बाद न करें।
इसके बजाय, कार्यों को थ्रेड लागू करें जो निष्पादित करने में लंबा समय लगे।

बेशक, यदि सिस्टम 1000+ कोर होने लगते हैं, तो यह उत्तर अप्रचलित हो सकता है और संशोधित करने की आवश्यकता है। लेकिन फिर, यदि आप "काम करने के लिए" जा रहे हैं, तो आप निश्चित रूप से पहले अपने उत्पाद को शिप करना चाहते हैं।

Answer 2

थ्रेडिंग का परिचय स्वचालित रूप से प्रदर्शन में वृद्धि नहीं करता है।

Answer 3

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

Answer 4

हो सकता है कि अच्छी बात डिजाइन प्रणालियों कुछ विशेषताओं अगर आप multithreading लागू करने के लिए चाहते हैं आप इसे शान से कर सकता है तो साथ ।

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

इस तरह की चीजें मुझे महत्वपूर्ण लगती हैं।

यदि यह मल्टीथ्रेडिंग के लिए डिज़ाइन कर रहा है ... तो यह एक समयपूर्व दृष्टिकोण महत्वपूर्ण है।

यह बस कुछ विशेषताओं है कि भविष्य में स्केलिंग या बहु सूत्रण अनुमति देते हैं यह सुनिश्चित हो जाती है: तो यह इतना महत्वपूर्ण नहीं है :)

संपादित उफ़, मैं इसे फिर से पढ़ें: समय से पहले अनुकूलन?

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

Answer 5

आप पाइपलाइन और मानचित्र-कम डिजाइन पैटर्न का पालन करते हैं, तो वह पर्याप्त होना चाहिए।
चीजों को विघटित करें ताकि आप ओएस-स्तरीय बहु-प्रोसेसिंग पाइपलाइन में चला सकें।

आप वास्तव में वास्तविक पाइपलाइन में चला सकते हैं। कोई अतिरिक्त काम नहीं ओएस सबकुछ संभालता है। विशाल गति अवसर।

आप थ्रेड पर भी स्विच कर सकते हैं। थोड़ा काम ओएस इसके कुछ हिस्सों को संभालता है, थ्रेड पुस्तकालय बाकी को संभालते हैं। हालांकि, चूंकि आप डिज़ाइन समय पर "प्रक्रिया" सोच रहे थे, इसलिए आपके धागे में कोई भ्रमित डेटा साझाकरण समस्या नहीं है। थोड़ी सोच के लिए बड़ी जीत।

Answer 6

वे कहते हैं कि कोडिंग के दिन डिज़ाइन के घंटों को बचा सकते हैं।

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

और बहु-थ्रेडेड/बहु-संसाधित होने पर समांतरता का एक ही तरीका है। आप उदाहरण के लिए, एसिंक्रोनस आईओ का भी उपयोग कर सकते हैं।

मेरे अनुभव में, एकल धागे से एसिंक्रोनस जाने से बहु-थ्रेडेड जाने से कहीं अधिक स्वीकार्य होता है। लेकिन फिर, जो प्रोग्राम मैं लिखता हूं, वे अलग-अलग समस्याएं हल करते हैं, ठीक है, बाकी सब कुछ।

Answer 7

मैं सट्टा प्रदर्शन विचारों के लिए पूरी तरह से एक आवेदन में मल्टीथ्रेडिंग के लिए डिजाइन करने पर विचार नहीं करता। ऐसा इसलिए है क्योंकि कुछ तकनीकों के साथ जो किसी भी एप्लिकेशन के लिए अच्छे हैं, बाद में ऑपरेशन को बहु-थ्रेड किया जाना आसान है। techniues मैं सोच रहा हूँ कर रहे हैं:

• हार्ड स्थिरांक अनुबंध
  • C++ में, आप स्थिरांक के रूप में एक विधि चिह्नित कर सकते हैं, जिसका अर्थ यह एक उदाहरण चर के मूल्य नहीं बदलता है। आप किसी इनपुट पैरामीटर को कॉन्स्ट के रूप में विधि में भी चिह्नित कर सकते हैं, जिसका अर्थ है कि उस पैरामीटर पर केवल कॉन्स्ट विधियों को ही कहा जा सकता है। इन दो तकनीकों के साथ (और इन संकलक प्रवर्तनों को प्राप्त करने के लिए "चाल" का उपयोग न करके), आप उन परिचालनों को कम कर सकते हैं जिन्हें बहु-थ्रेडिंग जागरूक होने की आवश्यकता है।
• निर्भरता उलट
  • यह एक सामान्य तकनीक जहां किसी भी बाहरी एक वस्तु की जरूरत की वस्तुओं के निर्माण/प्रारंभ समय में या विशेष विधि हस्ताक्षर विधि के हिस्से के रूप में यह करने के लिए पारित कर रहे हैं है। इस तकनीक के साथ, यह 100% स्पष्ट है कि ऑब्जेक्ट्स को संभवतः एक ऑपरेशन (गैर-कॉन्स इंस्टेंस वेरिएबल्स और ऑपरेशन के लिए गैर-कॉन्स पैरामीटर) द्वारा बदला जा सकता है।) यह जानकर कि आप गैर-कार्यात्मक पहलुओं का दायरा जानते हैं एक ऑपरेशन और आप म्यूटेक्स इत्यादि को ऑब्जेक्ट्स में जोड़ सकते हैं जिन्हें समानांतर संचालन के बीच साझा किया जा सकता है। फिर आप अपने समांतरता को सही और कुशल होने के लिए डिज़ाइन कर सकते हैं।
• फ़ेवर प्रक्रियात्मक
  • विडंबना यह है कि अधिक कार्यात्मक, इसका मतलब है, समय से पहले अनुकूलन नहीं है। मूल्य वस्तुओं अपरिवर्तनीय बनाओ। उदाहरण के लिए, सी # में, स्ट्रिंग्स अपरिवर्तनीय हैं, जिसका अर्थ है कि उन पर कोई भी ऑपरेशन स्ट्रिंग ऑब्जेक्ट्स के नए उदाहरण लौटाता है, मौजूदा स्ट्रिंग के संशोधित उदाहरण नहीं। एकमात्र वस्तुएं जो अपरिवर्तनीय नहीं होनी चाहिए वे असंबद्ध सरणी या ऑब्जेक्ट्स हैं जिनमें असंबद्ध सरणी होती है, यदि उन सरणीओं को अक्सर संशोधित करने की संभावना है। मैं तर्क दूंगा कि अपरिवर्तनीय वस्तुओं को समझना आसान है। कई प्रोग्रामर प्रक्रियात्मक तकनीकों को पढ़ाते थे, इसलिए यह हमारे लिए कुछ हद तक विदेशी है, लेकिन जब आप अपरिवर्तनीय शर्तों में सोचना शुरू करते हैं, तो पूर्ववर्ती प्रोग्रामिंग के भयानक पहलुओं जैसे ऑपरेशन निर्भरता और साइड इफेक्ट्स का आदेश दूर हो जाता है। बहु-थ्रेडेड प्रोग्रामिंग में उन पहलुओं को और भी भयानक है, इसलिए कक्षा डिजाइन में एक कार्यात्मक शैली का उपयोग कई तरीकों से मदद करता है।जैसे-जैसे मशीन तेजी से बढ़ती हैं, अपरिवर्तनीय वस्तुओं की उच्च लागत औचित्य को आसान और आसान हो जाती है। आज, यह एक संतुलन है।

Answer 8

धागे कार्यक्रम के लिए आसान कई एजेंटों के रोजगार बनाने के लिए मौजूद हैं।

• यदि एजेंट उपयोगकर्ता हैं, जैसे कि आपके पास थ्रेड-प्रति-उपयोगकर्ता है, तो वे प्रोग्राम लिखना आसान बनाते हैं। यह एक प्रदर्शन मुद्दा नहीं है, यह एक आसानी से लिखने का मुद्दा है।

• यदि एजेंट I/O डिवाइस हैं, तो वे एक प्रोग्राम लिखना आसान बनाते हैं जो समानांतर में I/O करता है। यह प्रदर्शन के लिए किया जा सकता है या नहीं किया जा सकता है।

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

दूसरे शब्दों में, यदि आपको थ्रेड == समांतरता == प्रदर्शन लगता है, तो यह केवल थ्रेड के उपयोगों में से एक को मार रहा है।

Answer 9

तीन बुनियादी डिजाइन विकल्प हैं: सिंक, असिंक, या सिंक + बहु थ्रेडेड। यदि आपका पागल पागल हो तो एक या एक से अधिक चुनें।

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

सिंक ग्राहक आवश्यकताओं को पूरा नहीं करता है:

सीपीयू सीमित सिस्टम बहु धागा/प्रक्रिया

आईओ सीमित सिस्टम (सबसे सामान्य) के चयन की आवश्यकता होती है अक्सर या तो Async या मीट्रिक टन जा सकते हैं।

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

Answer 10

अनुकूलन के बीच संतुलन रखने और प्राप्त करने का आपका तरीका क्या है?

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

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

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

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

इस बीच यह सब से बचा जा सकता था अगर सॉफ़्टवेयर ने IImage जैसे कोसर स्तर पर अपने अवशोषणों को आसानी से डिजाइन किया था, और शेष सिस्टम में व्यक्तिगत पिक्सेल ऑब्जेक्ट्स को उजागर करने से बचा था। एक छवि प्रभावी रूप से संग्रह पिक्सल (अक्सर लाखों पिक्सेल) है और यह एक समय में कई पिक्सल को संसाधित करने वाले संचालन प्रदान कर सकती है। अब प्रोसेसिंग पिक्सेल से जुड़े प्रसंस्करण और मेमोरी ओवरहेड को एक लाख-पिक्सेल छवि के लिए 1/1,000,000 वें स्थान पर घटा दिया गया है, जिस बिंदु पर यह छोटा हो जाता है। यह छवि संचालन को सांस लेने के कमरे को छोड़ देता है जैसे कि समानांतर में प्रक्रिया पिक्सेल और केंद्रीय स्तर पर वेक्टरिज्ड अब कोड की महाकाव्य राशि को दोबारा लिखने के बिना, क्लाइंट कोड व्यक्तिगत रूप से एक पिक्सेल को एक समय में संसाधित नहीं कर रहा है बल्कि इसके बजाय पूरी तरह से अनुरोध कर रहा है छवि संचालन किया जाना है।

हालांकि यह छवि प्रसंस्करण के साथ नो-ब्रेनर जैसा प्रतीत हो सकता है जो मूल रूप से एक बहुत ही प्रदर्शन-महत्वपूर्ण क्षेत्र है, अन्य डोमेन में ऐसा करने के लिए बहुत सारे कमरे हैं। अपने क्लासिक विरासत उदाहरण के साथ, आपको DogMammal प्राप्त करने की आवश्यकता नहीं है। आप DogsMammals प्राप्त कर सकते हैं।

तो चीजों को पूरा करने के लिए वापस, मैं डेटा-उन्मुख मानसिकता के साथ शुरू करता हूं ताकि सबसे कुशल कैश-अनुकूल, शर्मनाक समानांतर, थ्रेड-सुरक्षित, सिम-फ्रेंडली डेटा प्रस्तुतियों और अत्याधुनिक डेटा संरचनाओं और एल्गोरिदम नहीं मिल सकें पहली कोशिश पर। अन्यथा मैं पूरे सप्ताह व्यतीत कर सकता हूं कि वीटीयूएन के साथ चीजों को ट्यून करना जबकि बेंचमार्क तेजी से और तेज हो जाते हैं (मुझे यह करना अच्छा लगता है लेकिन यह निश्चित रूप से हर जगह और आगे काम करने के लिए उत्पादक नहीं है)। मैंने केवल चीजों को डिजाइन करने के लिए उपयोग की जाने वाली ग्रैन्युलरिटी के उपयुक्त स्तर को निर्धारित करने के लिए पर्याप्त विचार किया है: "क्या मुझे सिस्टम को Dog या Dogs पर निर्भर करना चाहिए?", इस तरह की चीज। और यह भी इतना विचार की आवश्यकता नहीं है। ओओपी के लिए यह पसंद है, "क्या सिस्टम हर एक फ्रेम में सौ हजार कुत्तों को संसाधित करता है? हाँ/नहीं?" यदि "हां", केंद्रीय Dog इंटरफ़ेस डिज़ाइन न करें और केंद्रीय IMammal इंटरफ़ेस को डिज़ाइन न करें। DogsIMammals का उत्तराधिकारी होने के लिए, जैसा कि हम एक समय में लाखों पिक्सल को संसाधित करने जा रहे हैं, जैसा कि हम ऊपर समान छवि प्रसंस्करण परिदृश्य में IPixel इंटरफ़ेस से बचते हैं।

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

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

गैर-सजातीय प्रसंस्करण करने वाले सिस्टम में अलग-अलग चीजों के एक बोतलबंद द्वारा एक किशोर चीज पर निर्भर करता है, ऐसा कोई कमरा नहीं है। वहां आप उपयोग करने के लिए केवल 10 मीटर सड़क के साथ एनालॉगिकल रेस कार के परिदृश्य के साथ समाप्त हो सकते हैं। एक भारी चीज जो किशोरों की चीजों के बोतलबंद को संसाधित करती है, जो एक साथ स्टोर करती है, बाद में अनुकूलित करने के लिए अंतहीन कमरे छोड़ देती है।