क्या बड़े अनुप्रयोगों में एसटीएल से बचा जाना चाहिए?

Question

यह एक अजीब सवाल लग सकता है, लेकिन मेरे विभाग में हमें निम्न स्थिति से परेशानी हो रही है:

हम यहां एक सर्वर एप्लिकेशन पर काम कर रहे हैं, जो बड़े और बड़े हो रहे हैं, यहां तक ​​कि इस बिंदु पर कि हम इसे अलग-अलग हिस्सों (डीएलएल फाइलों) में विभाजित करने पर विचार कर रहे हैं, जरूरत पड़ने पर गतिशील रूप से लोड हो रहा है और बाद में उतारने में सक्षम होना चाहिए। प्रदर्शन के मुद्दे।

लेकिन: हम जिन कार्यों का उपयोग कर रहे हैं, वे एसटीएल ऑब्जेक्ट्स के रूप में इनपुट और आउटपुट पैरामीटर पारित कर रहे हैं, और जैसा कि स्टैक ओवरफ्लो उत्तर में उल्लेख किया गया है , यह एक बहुत बुरा विचार है। (पोस्ट में कुछ and समाधान और हैक्स शामिल हैं, लेकिन यह सब बहुत ठोस नहीं दिखता है।)

जाहिर है कि हम इनपुट / आउटपुट मापदंडों को मानक C ++ प्रकारों द्वारा प्रतिस्थापित कर सकते हैं और फ़ंक्शन के अंदर एक बार एसटीएल ऑब्जेक्ट बना सकते हैं, लेकिन इससे प्रदर्शन ड्रॉप हो सकता है।

क्या यह निष्कर्ष निकालना ठीक है कि, यदि आप किसी एप्लिकेशन का निर्माण करने पर विचार कर रहे हैं, जो कि इतना बड़ा हो सकता है कि एक सिंगल पीसी इसे अब और नहीं संभाल सकता है, तो आपको एसटीएल को एक तकनीक के रूप में उपयोग नहीं करना चाहिए?

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

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1 आवेदन का उदाहरण है, मशीन 1 पर स्थापित है, जबकि App_Inst2 उसी एप्लिकेशन का उदाहरण है, जो मशीन 2 पर स्थापित है।
DLL1.x एक DLL है, जो मशीन 1 पर स्थापित है, जबकि DLL2.x एक DLL है, जो मशीन 2 पर स्थापित है।
DLLx.1 निर्यात किए गए फ़ंक्शन 1 को शामिल करता है।
DLLx.2 निर्यात किए गए फ़ंक्शन 2 को कवर करता है।

अब Machine1 पर मैं function1 और function2 निष्पादित करना चाहता हूं। मुझे पता है कि यह मशीन 1 को अधिभारित कर देगा, इसलिए मैं App_Inst2 को एक संदेश भेजना चाहूंगा, जिससे उस एप्लिकेशन को फ़ंक्शन 2 का प्रदर्शन करने के लिए कहा जा सके।

Function1 और function2 के इनपुट / आउटपुट पैरामीटर STL (C ++ Standard Type Library) ऑब्जेक्ट हैं, और नियमित रूप से मैं ग्राहक से App_Inst1, App_Inst2, DLLx.y के अपडेट करने की उम्मीद कर सकता हूं (लेकिन उनमें से सभी नहीं, ग्राहक मशीन 1 को अपग्रेड कर सकते हैं लेकिन मशीन 2 नहीं, या केवल अनुप्रयोगों को अपग्रेड करें लेकिन डीएलएल या इसके विपरीत नहीं, ...)। स्पष्ट रूप से यदि इंटरफ़ेस (इनपुट / आउटपुट पैरामीटर) बदलता है, तो ग्राहक को पूर्ण अपग्रेड करने के लिए मजबूर किया जाता है।

हालाँकि, जैसा कि संदर्भित StackOverflow URL में उल्लेख किया गया है, App_Inst1 या DLL में से एक का पुन: संकलन पूरा सिस्टम अलग हो सकता है, इसलिए इस पोस्ट का मेरा मूल शीर्षक, STL (C ++ Standard Template) के उपयोग की सलाह देना पुस्तकालय) बड़े अनुप्रयोगों के लिए।

मुझे आशा है कि इसके द्वारा मैंने कुछ प्रश्नों / शंकाओं को दूर कर दिया है।

Comments

क्या आप सुनिश्चित हैं कि आपके निष्पादन योग्य आकार के कारण आपके पास प्रदर्शन के मुद्दे हैं ? क्या आप इस बारे में कुछ विवरण जोड़ सकते हैं कि क्या यह मान लेना यथार्थवादी है कि आपका सारा सॉफ्टवेयर एक ही कंपाइलर (उदाहरण के लिए बिल्ड सर्वर पर एक में जाना जाता है) या यदि आप वास्तव में स्वतंत्र टीमों में विभाजित करना चाहते हैं?

— nvoigt

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

— rwong

लिंक किए गए प्रश्न में स्वीकृत उत्तर बताता है कि समस्या सामान्य रूप से C ++ कॉल के साथ है। तो "सी ++ लेकिन एसटीएल नहीं" मदद नहीं करता है, आपको सुरक्षित पक्ष पर होने के लिए नंगे सी के साथ जाने की आवश्यकता है (लेकिन जवाब भी देखें, क्रमांकन एक बेहतर समाधान है)।

— फ्रैक्स

जरूरत पड़ने पर गतिशील रूप से लोड करना और बाद में उतारना, प्रदर्शन के मुद्दों को संभालने में सक्षम होने के लिए क्या "प्रदर्शन के मुद्दे"? मैं बहुत अधिक मेमोरी का उपयोग करने के अलावा किसी भी मुद्दे के बारे में नहीं जानता, जो मेमोरी से डीएलएल जैसी चीजों को लोड करके तय किया जा सकता है - और अगर समस्या सबसे आसान फिक्स है तो बस अधिक रैम खरीदना है। आपके पास प्रोफाइल आपके आवेदन वास्तविक प्रदर्शन बाधाओं की पहचान के लिए? क्योंकि यह एक XY समस्या की तरह लगता है - आपने अनिर्दिष्ट "प्रदर्शन मुद्दों" और किसी ने पहले से ही समाधान पर फैसला किया है।

— एंड्रयू हेनले

@MaxBarraclough "द एसटीएल" को अस्थायी रूप से कंटेनरों और फ़ंक्शंस के लिए वैकल्पिक नाम के रूप में पूरी तरह से स्वीकार किया जाता है जिन्हें सी ++ स्टैंडर्ड लाइब्रेरी में रखा गया है। वास्तव में C ++ कोर दिशानिर्देश, बज़र्न स्ट्रॉस्ट्रप और हर्ब सटर द्वारा लिखित, बार-बार "एसटीएल" का संदर्भ देते हैं जब इन पर बात करते हैं। आपको इससे अधिक आधिकारिक स्रोत नहीं मिल सकता है।

— सीन बर्टन

Answer 1

यह एक पत्थर की ठंडी क्लासिक XY समस्या है।

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

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

जब आपको डेटा मिल जाता है, तो आप समस्या से निपटने के लिए कैसे काम कर सकते हैं, और फिर आप यह काम कर सकते हैं कि कहां अनुकूलन करना है।

Comments

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

— जूल्स

@Jules अद्यतन देखें - उन्होंने स्पष्ट किया है कि DLL केवल अलग मशीनों पर मौजूद हैं, इसलिए मैं शायद इस समाधान को काम करते हुए देख सकता हूं। अब संचार ओवरहेड है, हालांकि इतना सुनिश्चित होना मुश्किल है।

— इज़्काता

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

— जूल्स

Answer 2

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

यदि आपको किसी एप्लिकेशन को साझा लाइब्रेरी (DLL) में विभाजित करना है (प्रदर्शन कारणों से करने से पहले, आपको वास्तव में यह सुनिश्चित करना चाहिए कि यह वास्तव में आपकी प्रदर्शन समस्याओं को हल कर देगा) STL ऑब्जेक्ट को पास करना एक समस्या हो सकती है, लेकिन होना नहीं है। जैसा कि आपके द्वारा पहले से उपलब्ध कराए गए लिंक के अनुसार, एसटीएल ऑब्जेक्ट्स पास करना काम करता है यदि आप उसी कंपाइलर और समान कंपाइलर सेटिंग्स का उपयोग करते हैं। यदि उपयोगकर्ता DLL प्रदान करते हैं, तो आप इस पर आसानी से भरोसा नहीं कर सकते। यदि आप सभी DLL प्रदान करते हैं और सब कुछ एक साथ संकलित करते हैं, तो आप इस पर भरोसा कर सकते हैं और DLL सीमाओं के पार STL वस्तुओं का उपयोग करना बहुत संभव हो जाता है। आपको अभी भी अपने संकलक सेटिंग्स के लिए बाहर देखना होगा ताकि आप ऑब्जेक्ट स्वामित्व प्राप्त करने पर कई अलग-अलग ढेर न पाएं, हालांकि यह एसटीएल विशिष्ट समस्या नहीं है।

Comments

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

— दाविदबक

अगर मुझे इस तरह से एक एप्लिकेशन को विभाजित करना था, तो मैं शायद COM का उपयोग करूंगा, लेकिन यह आमतौर पर कोड का आकार बढ़ाता है क्योंकि हर घटक अपने स्वयं के सी और सी ++ लाइब्रेरी लाता है (जो कि जब वे समान होते हैं तो साझा किए जा सकते हैं, लेकिन आवश्यक होने पर विचलन कर सकते हैं, उदाहरणों के दौरान। मुझे यकीन नहीं है कि यह ओपी की समस्या के लिए कार्रवाई का उपयुक्त पाठ्यक्रम है, हालांकि।

— साइमन रिक्टर

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

— बिंदुओं

Answer 3

हम यहां एक सर्वर एप्लिकेशन पर काम कर रहे हैं, जो कि बड़े और बड़े हो रहे हैं, यहां तक ​​कि इस बिंदु पर कि हम इसे अलग-अलग हिस्सों (डीएलएल) में विभाजित करने पर विचार कर रहे हैं, जरूरत पड़ने पर गतिशील रूप से लोड हो रहा है और बाद में उतारने में सक्षम होना चाहिए। प्रदर्शन के कारण

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

कैश अधिक महंगा है, लेकिन यह केवल उस कोड को प्रभावित करता है जो हाल ही में सक्रिय है, न कि कोड जो स्मृति में अनुपयोगी बैठा है।

सामान्य कार्यक्रमों में डेटा साइज़ या सीपीयू समय के कारण अपने कंप्यूटर को उखाड़ फेंकते हैं, कोड आकार को नहीं। यदि आपके कोड का आकार इतना बड़ा हो रहा है कि यह बड़ी समस्या पैदा कर रहा है तो आप संभावित रूप से यह देखना चाहते हैं कि पहली जगह में क्यों हो रहा है।

लेकिन: जो फ़ंक्शन हम उपयोग कर रहे हैं, वे एसटीएल ऑब्जेक्ट्स के रूप में इनपुट और आउटपुट पैरामीटर पारित कर रहे हैं, और जैसा कि इस StackOverflow URL में बताया गया है, यह एक बहुत बुरा विचार है।

यह ठीक होना चाहिए जब तक कि dll और निष्पादन योग्य सभी एक ही संकलक के साथ बनाए जाते हैं और गतिशील रूप से समान C ++ रनटाइम लाइब्रेरी के खिलाफ लिंक किए जाते हैं। यह इस प्रकार है कि यदि एप्लिकेशन और यह संबंधित डीएलएस एक ही इकाई के रूप में निर्मित और तैनात किए जाते हैं तो यह समस्या नहीं होनी चाहिए।

जहां यह एक समस्या बन सकती है जब पुस्तकालयों का निर्माण अलग-अलग लोगों द्वारा किया जाता है या उन्हें अलग से अपडेट किया जा सकता है।

क्या यह निष्कर्ष निकालना ठीक है कि, यदि आप किसी एप्लिकेशन का निर्माण करने पर विचार कर रहे हैं, जो कि इतना बड़ा हो सकता है कि एक सिंगल पीसी इसे अब और नहीं संभाल सकता है, तो आपको एसटीएल को एक तकनीक के रूप में उपयोग नहीं करना चाहिए?

ज़रुरी नहीं।

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

Comments

निष्क्रिय कोड की संभावना पहली बार में रैम में लोड नहीं होती है। यदि वे वास्तव में आवश्यक हैं, तो अधिकांश ऑपरेटिंग सिस्टम केवल निष्पादनयोग्य से पृष्ठ लोड करते हैं।

— जूल्स

@ जूल्स: यदि डेड कोड को लाइव कोड (पेज-साइज = 4k ग्रैन्युलैरिटी के साथ) के साथ मिलाया जाता है, तो इसे m + लोड किया जाएगा। कैश बहुत महीन (64B) ग्रैन्युलैरिटी पर काम करता है, इसलिए यह अभी भी ज्यादातर सच है कि अप्रयुक्त फ़ंक्शन बहुत चोट नहीं पहुंचाते हैं। प्रत्येक पृष्ठ को एक TLB प्रविष्टि की आवश्यकता होती है, हालांकि, और (RAM के विपरीत) एक दुर्लभ रनटाइम संसाधन है। (फ़ाइल-समर्थित मैपिंग आमतौर पर विशालकाय का उपयोग नहीं करते हैं, कम से कम लिनक्स पर नहीं; एक बहुत बड़ा पेज 2 एम 2 बी x86-64 पर है, इसलिए आप बहुत अधिक कोड या डेटा को बिना किसी टीएलबी के भारी-भरकम छूट के बिना कवर कर सकते हैं।

— पीटर

@PeterCordes नोट क्या है: इसलिए, अपनी बिल्ड-फॉर-रिलीज़ प्रक्रिया के भाग के रूप में "PGO" का उपयोग करना सुनिश्चित करें!

— JDługosz

Answer 4

नहीं, मुझे नहीं लगता कि निष्कर्ष इस प्रकार है। यहां तक ​​कि अगर आपके कार्यक्रम को कई मशीनों में वितरित किया जाता है, तो कोई कारण नहीं है कि एसटीएल आंतरिक रूप से उपयोग करके आपको अंतर-मॉड्यूल / प्रक्रिया संचार में इसका उपयोग करने के लिए मजबूर करता है।

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

Answer 5

आपको उस प्रश्न का बिंदु याद आ रहा है।

मूल रूप से DLL के दो प्रकार हैं। अपना, और किसी और का। "एसटीएल समस्या" यह है कि आप और वे एक ही संकलक का उपयोग नहीं कर रहे हैं। जाहिर है, यह आपके अपने DLL के लिए कोई समस्या नहीं है।

Answer 6

यदि आप एक ही संकलक के साथ एक ही स्रोत के पेड़ से DLL बनाते हैं और विकल्प बनाते हैं, तो यह ठीक काम करेगा।

हालाँकि "विंडोज फ्लेवर्ड" एप्लिकेशन को कई टुकड़ों में विभाजित करने का तरीका है जिनमें से कुछ फिर से उपयोग करने योग्य है COM घटक । ये छोटे हो सकते हैं (व्यक्तिगत नियंत्रण या कोडेक्स) या बड़े (IE एक COM नियंत्रण के रूप में उपलब्ध है, mshtml.dll में)।

जरूरत पड़ने पर लोडिंग और बाद में उतराई

एक सर्वर अनुप्रयोग के लिए, यह संभवतः भयानक दक्षता रखने वाला है; जब आपके पास एक ऐसा अनुप्रयोग होता है जो केवल कई चरणों में चलता है, तो यह वास्तव में व्यवहार्य होता है ताकि आपको पता चले कि जब कुछ फिर से आवश्यक नहीं है। यह मुझे ओवरले तंत्र का उपयोग करके डीओएस गेम की याद दिलाता है।

इसके अलावा, यदि आपका वर्चुअल मेमोरी सिस्टम ठीक से काम कर रहा है, तो यह अप्रयुक्त कोड पृष्ठों को पेजिंग करके आपके लिए संभाल लेगा।

वह बड़ा हो सकता है कि एक एकल पीसी अब इसे संभाल नहीं सकता है

एक बड़ा पीसी खरीदें।

मत भूलो कि सही अनुकूलन के साथ एक लैपटॉप एक हडूप क्लस्टर को बेहतर बना सकता है।

यदि आपको वास्तव में कई प्रणालियों की आवश्यकता है, तो आपको उन दोनों के बीच की सीमा के बारे में बहुत सावधानी से सोचना होगा, क्योंकि यही क्रमिक लागत है। यहीं पर आपको MPI जैसे फ्रेमवर्क को देखना शुरू करना चाहिए।

Comments

"यह वास्तव में व्यवहार्य है जब आपके पास एक ऐसा एप्लिकेशन होता है जो कई चरणों में एक लंबी अवधि के दौरान चलता है ताकि आप जान सकें कि जब कुछ फिर से जरूरी नहीं होने जा रहा है" - तब भी यह बहुत मदद करने की संभावना नहीं है, क्योंकि ओएस होगा DLL फ़ाइलों को कैश करें, जो संभवतः आपके बेस एक्जीक्यूटेबल में सीधे फ़ंक्शंस को शामिल करने से अधिक मेमोरी लेने की संभावना होगी। वर्चुअल मेमोरी के बिना सिस्टम में ओवरले केवल उपयोगी होते हैं, या जब वर्चुअल एड्रेस स्पेस सीमित कारक होता है (मुझे लगता है कि यह एप्लिकेशन 64-बिट है, 32 नहीं ...)।

— जूल्स

"एक बड़ा पीसी खरीदें" +1। अब आप कई टेराबाइट रैम वाले सिस्टम का अधिग्रहण कर सकते हैं । आप एक डेवलपर की प्रति घंटा की दर से कम के लिए अमेज़ॅन से एक किराया कर सकते हैं। मेमोरी उपयोग को कम करने के लिए आप अपने कोड को अनुकूलित करने में कितना डेवलपर समय बिता रहे हैं?

— जूल्स

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

— MSalters

COM घटक? शायद 1990 के दशक में, लेकिन अब?

— पीटर मोर्टेंसन

@MSalters - सही ... किसी भी सवाल के साथ किसी ने भी एक पीसी पर कितने पैमाने पर स्केल किया जा सकता है, इसके लिए अमेज़ॅन EC2 X1e.32xlarge उदाहरण प्रकार के लिए चश्मा देखना चाहिए - 72 भौतिक प्रोसेसर कोर मशीन में कुल 128 वर्चुअल कोर प्रदान करते हैं 2.3GHz (3.1GHz के लिए), संभवतः 340GB / s मेमोरी बैंडविड्थ (किस प्रकार की मेमोरी स्थापित है, जो कल्पना में वर्णित नहीं है) और 3.9TiB RAM पर निर्भर करता है। यह मुख्य कैश को छूने के बिना अधिकांश अनुप्रयोगों को चलाने के लिए पर्याप्त कैश है। यहां तक ​​कि एक GPU के बिना यह 2000 से 500-नोड सुपर कंप्यूटर क्लस्टर के रूप में शक्तिशाली है।

— जूल्स

Answer 7

हम यहां एक सर्वर एप्लिकेशन पर काम कर रहे हैं, जो बड़े और बड़े हो रहे हैं, यहां तक ​​कि इस बिंदु पर कि हम इसे अलग-अलग हिस्सों (डीएलएल फाइलों) में विभाजित करने पर विचार कर रहे हैं, जरूरत पड़ने पर गतिशील रूप से लोड हो रहा है और बाद में उतारने में सक्षम होना चाहिए। प्रदर्शन के मुद्दे।

पहला भाग समझ में आता है (प्रदर्शन कारणों से विभिन्न मशीनों के लिए विभाजन)।

दूसरा भाग (लोडिंग और अनलोडिंग लाइब्रेरी) का कोई मतलब नहीं है, क्योंकि यह बनाने के लिए अतिरिक्त प्रयास है, और यह (वास्तव में) चीजों में सुधार नहीं करेगा।

आप जिस समस्या का वर्णन कर रहे हैं, वह समर्पित संगणना मशीनों के साथ बेहतर हल है, लेकिन इन्हें उसी (मुख्य) अनुप्रयोग के साथ काम नहीं करना चाहिए।

क्लासिक समाधान इस तरह दिखता है:

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

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

यह किसी भी तरह से डीएलएल के अतिरिक्त लोडिंग / अनलोडिंग का अर्थ नहीं है, न ही एसटीएल के साथ कुछ भी करने के लिए।

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

यह आपके द्वारा प्रदान की गई सीमित जानकारी के साथ है, यह क्लासिक xy समस्या जैसा दिखता है (जैसा @Graham ने कहा)।