मैं this article पढ़ रहा था, और यह लड़का ओओपी के साथ डेटा उन्मुख डिजाइन में मिश्रण से कैसे लाभ उठा सकता है इस बारे में बात कर रहा है। हालांकि, वह कोई कोड नमूने नहीं दिखाता है।डेटा उन्मुख डिजाइन क्या है?
मैंने इसे गुमराह किया और यह कोई वास्तविक जानकारी नहीं मिली कि यह क्या है, किसी भी कोड नमूने को अकेले छोड़ दें। क्या कोई इस शब्द से परिचित है और एक उदाहरण प्रदान कर सकता है? क्या यह शायद किसी और चीज़ के लिए एक अलग शब्द है?
सबसे पहले डेटा संचालित डिज़ाइन के साथ इसे भ्रमित न करें।
डेटा ओरिएंटेड डिज़ाइन की मेरी समझ यह है कि यह आपके डेटा को कुशल प्रसंस्करण के लिए व्यवस्थित करने के बारे में है। विशेष रूप से कैश मिस आदि के संबंध में। दूसरी ओर डेटा संचालित डिजाइन डेटा प्रोग्राम को आपके बहुत से प्रोग्राम व्यवहार को नियंत्रित करने के बारे में है (Andrew Keith's answer द्वारा बहुत अच्छी तरह वर्णित)।
:आप इस तरह के रंग, त्रिज्या, bounciness, स्थिति आदि
ऑब्जेक्ट ओरिएंटेड दृष्टिकोण
OOP में आप इस तरह आप गेंदों का वर्णन होगा के रूप में गुणों के साथ अपने आवेदन में गेंद वस्तुओं है कहो
class Ball {
Point position;
Color color;
double radius;
void draw();
};
और फिर आप इस तरह गेंदों का एक संग्रह बनाने होगा:
vector<Ball> balls;
डाटा उन्मुखी दृष्टिकोण
डाटा उन्मुखी डिजाइन में हालांकि आप और अधिक इस तरह कोड लिखने की संभावना है:
class Balls {
vector<Point> position;
vector<Color> color;
vector<double> radius;
void draw();
};
आप देख सकते हैं कोई एक इकाई अब और एक गेंद का प्रतिनिधित्व नहीं है। बॉल ऑब्जेक्ट्स केवल निहित मौजूद हैं।
इसमें कई फायदे प्रदर्शन के अनुसार हो सकते हैं। आम तौर पर हम एक ही समय में कई गेंदों पर संचालन करना चाहते हैं। हार्डवेयर आमतौर पर स्मृति के बड़े निरंतर भाग कुशलतापूर्वक संचालित करने के लिए चाहता है।
दूसरा आप ऑपरेशन कर सकते हैं जो गेंदों के गुणों के केवल एक हिस्से को प्रभावित करता है। जैसे यदि आप सभी गेंदों के रंगों को विभिन्न तरीकों से जोड़ते हैं, तो आप चाहते हैं कि आपके कैश में केवल रंग की जानकारी हो। हालांकि जब सभी गेंद गुण एक इकाई में संग्रहीत होते हैं तो आप गेंद के सभी अन्य गुणों को भी खींचेंगे। भले ही आपको उनकी आवश्यकता नहीं है।
कैश प्रयोग उदाहरण
एक गेंद प्रत्येक गेंद 64 बाइट्स लेता है और एक प्वाइंट 4 बाइट लेता है कहो। एक कैश स्लॉट 64 बाइट्स भी कहते हैं। अगर मैं 10 गेंदों की स्थिति को अपडेट करना चाहता हूं तो मुझे कैश में 10 * 64 = 640 मेमोरी बाइट्स को खींचना होगा और 10 कैश मिस प्राप्त करना होगा। यदि मैं गेंदों की स्थिति अलग इकाइयों के रूप में काम कर सकता हूं, तो इसमें केवल 4 * 10 = 40 बाइट्स लगेगा। यह एक कैश लाने में फिट बैठता है। इस प्रकार हम सभी 10 गेंदों को अपडेट करने के लिए केवल 1 कैश मिस प्राप्त करते हैं। ये संख्या मनमानी हैं मुझे लगता है कि एक कैश ब्लॉक बड़ा है।
लेकिन यह दिखाता है कि कैसे स्मृति लेआउट गंभीर प्रभाव कैश हिट और इस प्रकार प्रदर्शन कर सकता है। यह केवल महत्व में वृद्धि करेगा क्योंकि सीपीयू और रैम की गति के बीच का अंतर बढ़ता है।
स्मृति
लेआउट कैसे मेरी गेंद उदाहरण में मैं इस मुद्दे एक बहुत आसान बनाया है, क्योंकि आम तौर पर आप की संभावना कई चर एक साथ उपयोग करेंगे किसी भी सामान्य एप्लिकेशन के लिए। जैसे स्थिति और त्रिज्या का उपयोग अक्सर एक साथ किया जाएगा। फिर अपने संरचना होना चाहिए:
class Body {
Point position;
double radius;
};
class Balls {
vector<Body> bodies;
vector<Color> color;
void draw();
};
कारण आप इस करना चाहिए एक साथ इस्तेमाल किया डेटा अलग सरणियों में रखा जाता है, तो, वहाँ एक जोखिम है कि वे कैश में एक ही स्लॉट के लिए प्रतिस्पर्धा करेंगे है। इस प्रकार एक लोडिंग दूसरे को फेंक देगा।
तो ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की तुलना में आप जो कक्षाएं बनाते हैं, वे समस्या के आपके मानसिक मॉडल में इकाइयों से संबंधित नहीं हैं। चूंकि डेटा डेटा उपयोग के आधार पर डेटा को एक साथ लाया जाता है, इसलिए आपके डेटा को ओरिएंटेड डिज़ाइन में अपनी कक्षाएं देने के लिए हमेशा समझदार नाम नहीं होंगे। रिलेशनल डेटाबेस
पीछे डाटा उन्मुखी डिजाइन सोच को
रिलेशन बहुत आप रिलेशनल डेटाबेस के बारे में कैसे सोचते हैं के समान है। एक रिलेशनल डेटाबेस को अनुकूलित करने से कैश का अधिक कुशलता भी शामिल हो सकता है, हालांकि इस मामले में, कैश सीपीयू कैश को स्मृति में पृष्ठों को नहीं डालता है। एक अच्छा डेटा बेस डिजाइनर भी बड़ी संख्या में कॉलम के साथ एक टेबल बनाने के बजाय अक्सर अलग-अलग एक्सेस डेटा को अलग तालिका में विभाजित कर सकता है, केवल कॉलम का उपयोग किया जाता है। वह कुछ तालिकाओं को denormalize भी चुन सकता है ताकि डेटा डिस्क पर कई स्थानों से पहुंचा जा सके। डेटा ओरिएंटेड डिज़ाइन की तरह ही इन विकल्पों को देखकर किया जाता है कि डेटा एक्सेस पैटर्न क्या हैं और जहां प्रदर्शन बाधा है।
इसके लिए धन्यवाद, आपने इसे बहुत अच्छी तरह से समझाया। – ryeguy
अच्छी तरह से कहा; हालांकि मुझे केवल एक सवाल मिला है। मान लें कि हमारे पास संरचना 'स्ट्रक्चर बॉल {वेक्टर
यह हो सकता है। लेकिन याद रखें कि पूरे पॉज़ सरणी को एक समय में नहीं खींचा जाएगा। बस एक कैश लाइन, और कुछ prefetching संभव है। इसी प्रकार वेग के साथ। तो उनके लिए एक दूसरे को कचरा करने के लिए पॉज़ और वेक्टर के प्रत्येक संबंधित हिस्से को उसी कैशलाइन पर मैप करना होगा। यह निश्चित रूप से हो सकता है, यही कारण है कि एक संरचना में एक साथ उपयोग किए जाने वाले चर डालने की सिफारिश है। तो उदा। वेग और pos एक वेक्टर में होगा जबकि रंग एक और वेक्टर में होगा। –
डेटा उन्मुख डिज़ाइन एक ऐसा डिज़ाइन है जिसमें एप्लिकेशन का तर्क प्रक्रियात्मक एल्गोरिदम की बजाय डेटा सेट से बनाया गया है। उदाहरण के लिए
प्रक्रियात्मक दृष्टिकोण।
int animation; // this value is the animation index
if(animation == 0)
PerformMoveForward();
else if(animation == 1)
PerformMoveBack();
.... // etc
डेटा डिजाइन दृष्टिकोण इस तरह
typedef struct
{
int Index;
void (*Perform)();
}AnimationIndice;
// build my animation dictionary
AnimationIndice AnimationIndices[] =
{
{ 0,PerformMoveForward }
{ 1,PerformMoveBack }
}
// when its time to run, i use my dictionary to find my logic
int animation; // this value is the animation index
AnimationIndices[animation].Perform();
डाटा डिजाइन डेटा के उपयोग को बढ़ावा देने के आवेदन के तर्क का निर्माण। विशेष रूप से वीडियो गेम में प्रबंधित करना आसान है जिसमें एनीमेशन या किसी अन्य कारक के आधार पर हजारों तर्क पथ हो सकते हैं।
यह वास्तव में सही नहीं है। आप डेटा संचालित डिजाइन के साथ डेटा उन्मुख डिजाइन भ्रमित कर रहे हैं। मैंने तब तक वही किया जब तक कि मैंने नोएल के लेख को नहीं पढ़ा और महसूस किया कि वह पूरी तरह से कुछ अलग बात कर रहा था। –
इसके अलावा, इंडिस एक शब्द नहीं है। "इंडेक्स" और "इंडेक्स" और कुछ भी "इंडेक्स" को कंडोन करते हैं, लेकिन "इंडिस" कभी सही नहीं होता है। – Baxissimo
मैं सिर्फ यह इंगित करना चाहता हूं कि नोएल विशेष रूप से खेल विकास में सामना करने वाली कुछ विशिष्ट आवश्यकताओं के बारे में बात कर रहा है। मुझे लगता है कि रीयल-टाइम सॉफ्ट सिमुलेशन कर रहे अन्य क्षेत्रों से इसका फायदा होगा, लेकिन यह ऐसी तकनीक होने की संभावना नहीं है जो सामान्य व्यावसायिक अनुप्रयोगों में उल्लेखनीय सुधार दिखाएगा। यह सेट अप सुनिश्चित करने के लिए है कि प्रदर्शन के हर अंतिम बिट अंतर्निहित हार्डवेयर से निचोड़ा हुआ है।
सहमत हुए। कुछ अन्य क्षेत्रों जहां डेटा उन्मुख डिजाइन महत्वपूर्ण है: उच्च बैंडविड्थ उपकरणों (जैसे नेटवर्किंग या स्टोरेज) के लिए हार्डवेयर और फर्मवेयर; बड़े पैमाने पर वैज्ञानिक कंप्यूटिंग (जैसे मौसम सिमुलेशन, प्रोटीन फोल्डिंग), सिग्नल प्रोसेसिंग (जैसे ऑडियो, छवि, वीडियो), डेटा संपीड़न। ये "कम्प्यूटेशनल साइंस एंड इंजीनियरिंग" के अंतर्गत आते हैं जिन्हें कभी-कभी अधिक विशिष्ट कंप्यूटर विज्ञान से अलग प्रमुख के रूप में पेश किया जाता है। – rwong
माइक एक्टन के बारे में Data oriented design हाल ही में एक सार्वजनिक भाषण दिया:
इसके बारे में मेरे बुनियादी सारांश होगा: यदि आप प्रदर्शन चाहते हैं, तो डाटा प्रवाह के बारे में सोचना है कि ज्यादातर तुम्हारे साथ पेंच की संभावना है भंडारण परत खोजने के लिए और इसके लिए अनुकूलन हार्ड। माइक एल 2 कैश मिस पर ध्यान केंद्रित कर रहा है, क्योंकि वह रीयलटाइम कर रहा है, लेकिन मुझे लगता है कि वही बात डेटाबेस पर लागू होती है (डिस्क पढ़ती है) और यहां तक कि वेब (HTTP अनुरोध) भी। यह प्रोग्रामिंग करने का एक उपयोगी तरीका है, मुझे लगता है।
ध्यान दें कि यह आपको एल्गोरिदम और समय जटिलता के बारे में सोचने से मुक्त नहीं करता है, यह आपके महंगे सीएस कौशल के साथ लक्षित करने के लिए सबसे महंगी ऑपरेशन प्रकार को समझने पर आपका ध्यान केंद्रित करता है।
गेम डेवलपर में यह आलेख अब ब्लॉग फॉर्म में पढ़ने में आसान है: http://gamesfromwithin.com/data-oriented-design – Edmundito
क्या आपने कभी कुछ लोगों को गुगल किया है, एक अच्छा लक्षित SO प्रश्न मिला है, और फिर एहसास हुआ क्या तुमने इसे साल पहले पूछा था? – ryeguy
यहां एक [डीओडी सामग्री का कुल] है (http://www.asawicki.info/news_1422_data-oriented_design_-_links_and_thoughts.html) वेब – legends2k