'अनुकूलन कोड' == 'संरचित डेटा' कब होता है?

Question

योकोम्बिनेटर का एक हालिया लेख एक महान प्रोग्रामर के सिद्धांतों के साथ एक टिप्पणी को सूचीबद्ध करता है।

#7. अच्छा प्रोग्रामर: मैं कोड का अनुकूलन करता हूं। बेहतर प्रोग्रामर: मैं डेटा संरचना करता हूं। बेस्ट प्रोग्रामर: क्या अंतर है?

व्यक्तिपरक और विवादास्पद अवधारणाओं को स्वीकार करते हुए - क्या इसका कोई मतलब है? मैं करता हूं, लेकिन मैं इस सवाल को बाद में अपने विचारों के साथ संपादित करना चाहता हूं, ताकि जवाबों का अनुमान न लगाया जा सके।

Comments

आपके संदर्भ की सूची में शांत वस्तुओं का एक समूह है। धन्यवाद।

— DeveloperDon

इस प्रश्न (जो मैंने पूछा था) के पास एक उत्तर है जो इस उद्धरण का भी उल्लेख करता है: programmers.stackexchange.com/q/168013/15028

— TCSGrad

Answer 1

दस में से नौ बार, जब आप अपने कोड / मॉडल को अच्छी तरह से संरचना करते हैं, तो अनुकूलन स्पष्ट हो जाएगा। आपने कितनी बार एक सींग वाले घोंसले को देखा है और इसे पूरी तरह से उप-रूपी माना है, जहां इसे पुनर्गठन करने पर, बहुत सारे अतिरेक बेहद स्पष्ट हैं।

एक डिजाइनर जानता है कि उसने पूर्णता तब हासिल की है जब जोड़ने के लिए कुछ भी नहीं बचा है, लेकिन जब कुछ भी नहीं बचा है तो उसे लेने के लिए नहीं है। - ओंत्वान डे सेंट - एक्सुपरी

एक अच्छी तरह से संरचित प्रणाली प्रकृति में कम से कम होगी, और इसकी न्यूनतम प्रकृति के कारण इसे अनुकूलित किया जाएगा क्योंकि यह कितना कम है इसका सीधा संबंध यह है कि यह लक्ष्य पूरा करने के लिए कितना कम है।

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

उस ने कहा, एक पूरी तरह से अलग संभावना है जिसे यहां से हटा दिया जा रहा है, और यह होगा कि वाईकॉम्बिनेटर के साथ संबंध रखने वाले इस साथी को समलैंगिकता की एलआईएसपी परंपरा में डेटा के रूप में कोड के रूप में संदर्भित किया जा सकता है। यह मेरे मन में अर्थ के रूप में इसे बढ़ाने के लिए एक खिंचाव है, लेकिन यह YCombinator है इसलिए मैं यह नहीं कहूंगा कि बोली बस यह कह रही है कि LISPers "सर्वश्रेष्ठ प्रोग्रामर" हैं।

Comments

यह "डेटा" से बात नहीं करता है और कैसे 'अनुकूलन कोड और संरचित डेटा के बीच अंतर नहीं है'। ऑप्टिमाइज़िंग कोड खराब डेटा का पुनर्गठन नहीं करता है जब तक कि यह किसी तरह का स्व-पचाने वाला, ट्यूरिंग-कम्पलीट, मशीन नहीं हो

— New Alexandria

@NewAlexandria मॉडल का उल्लेख "डेटा" है। अक्सर, खराब कोड और एक खराब मॉडल हाथ में हाथ जाता है। एक को ठीक करने से दूसरे को ठीक करने पर जोर पड़ता है।

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

— जिमी होफा

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

— न्यू अलेक्जेंड्रिया

Answer 2

मुझे लगता है कि लेखक संकेत दे रहा है कि डेटा के किसी भी पुनर्गठन से कोड पुनर्गठन होता है। इसलिए, आपके सिस्टम को अनुकूलित करने के लक्ष्य के साथ डेटा का पुनर्गठन आपको "क्या अंतर है?" प्रतिक्रिया।

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

Comments

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

— जिमी हॉफ

कभी-कभी डेटा पुनर्गठन कोड पुनर्गठन की अनुमति देता है, लेकिन मुझे लगता है कि कभी-कभी जब आप किए जाते हैं, तो नया कोड पुराने कोड के साथ बहुत कम होता है।

— DeveloperDon

OTOH, कैश लाइन आकार के लिए डेटा संरेखित करने से बहुत प्रभाव पड़ सकता है। ; -प

— मैकए

Answer 3

इसके सबसे स्पष्ट उदाहरण पर विचार करें - "उपयोगकर्ता डेटा की खोज बहुत धीमी है!"

यदि आपका उपयोगकर्ता डेटा अनुक्रमित या कम से कम सॉर्ट नहीं किया गया है, तो आपके डेटा के पुनर्गठन से कोड प्रदर्शन में तेजी से वृद्धि होगी। यदि डेटा ठीक से संरचित है और आप केवल संग्रह के माध्यम से पुनरावृत्ति कर रहे हैं (बल्कि अनुक्रमणिका का उपयोग कर रहे हैं या बाइनरी खोज जैसा कुछ कर रहे हैं) तो कोड पैदावार को संशोधित करके कोड प्रदर्शन में वृद्धि हुई है।

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

Answer 4

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

मुझे लगता है कि लेखक को "सर्वश्रेष्ठ प्रोग्रामर: मैं दोनों को अनुकूलित करता हूं" के रूप में अंतिम भाग लिखना चाहिए था ।

एक महान पुस्तक है (कम से कम जब यह प्रकाशित हुआ था) में कहा जाता है: एल्गोरिथम + डेटा संरचनाएं = कार्यक्रम ।

Answer 5

ऑप्टिमाइज़िंग कोड कभी-कभी दो के एक कारक द्वारा गति में सुधार कर सकता है, और कभी-कभी दस या बीस के एक कारक द्वारा, लेकिन यह इसके बारे में है। यह एक बहुत की तरह लग सकता है, और अगर एक कार्यक्रम के निष्पादन का 75% एक पांच-लाइन दिनचर्या में खर्च किया जाता है, जिसकी गति आसानी से दोगुनी हो सकती है, तो ऐसा अनुकूलन अच्छी तरह से लायक हो सकता है। दूसरी ओर, डेटा संरचनाओं का चयन चयन परिमाण के कई आदेशों द्वारा निष्पादन की गति को प्रभावित कर सकता है। रैम में संग्रहीत 10,000,000-आइटम रैखिक लिंक्ड सूची में कुंजी द्वारा डेटा को देखने के लिए सुपर-अनुकूलित कोड से चलने वाला एक आधुनिक हाइपर-अनुकूलित मल्टी-थ्रेडेड प्रोसेसर होगा, जो कि बहुत ही धीमी गति से चलने वाले नेस्टेड हैश टेबल को चलाने वाले एक बहुत धीमे प्रोसेसर की तुलना में धीमा होगा। वास्तव में, अगर किसी के पास ठीक से डेटा रखा गया था, तो भी 1980 '

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

Answer 6

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

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

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

डेटा की रचनात्मक संरचना एक समस्या को दूर करने और नए एल्गोरिदम के द्वार खोलने में मदद कर सकती है जो कठिन अनुप्रयोगों को तेज और कभी-कभी असंभव कार्यों को संभव बनाते हैं।

Answer 7

लेख का क्या अर्थ है, इस पर मेरा सबसे अच्छा अनुमान व्यक्त करने के लिए, मैं एक अस्पष्ट सबटेक्स्ट (जो लेख में गायब लगता है) मानूंगा कि किसी भी प्रोग्रामर को अनुकूलन के बारे में समझना चाहिए:

• आपके द्वारा प्रोग्राम को ठीक से चलाने और सही ढंग से चलाने के बाद ही अनुकूलन आता है:
  • इसे सही तरीके से चलाएं, फिर इसे तेजी से चलाएं
  • यह सिद्धांत नूथ की अधिकतमता का बिंदु है, "समयपूर्व अनुकूलन सभी बुराई की जड़ है"
• यदि और जब आपने यह निर्धारित कर लिया है कि अनुकूलन समय से पहले नहीं है, तो आपको यह निर्धारित करने के लिए पहले से ठीक से मापना चाहिए कि वास्तव में अनुकूलन के दौरान अनुकूलन और आपके प्रयासों का क्या प्रभाव पड़ रहा है।
  • यदि आपका कोड विकास में चलता है, तो प्रोफाइलर आपका मित्र है।
  • यदि आपका कोड उत्पादन में चलता है, तो आपको अपना कोड इंस्ट्रूमेंट करना होगा, और इसके बजाय अपने लॉगिंग सिस्टम से दोस्त बनाना होगा।

---

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

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

"सर्वश्रेष्ठ प्रोग्रामर" में पूरी तरह से मानसिक मॉडल होगा कि मशीन कैसे काम करती है, एल्गोरिथम डिजाइन में एक अच्छी ग्राउंडिंग और वे कैसे बातचीत करते हैं, इसकी एक व्यावहारिक समझ है। यह उसे सिस्टम को एक एकीकृत पूरे के रूप में विचार करने की अनुमति देता है - वह कोड और डेटा के अनुकूलन के बीच कोई अंतर नहीं देखेगा, क्योंकि वह एक वास्तु स्तर पर उनका मूल्यांकन करता है।

Answer 8

बेस्ट प्रोग्रामर: क्या अंतर है?

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