Acceler8 2011 - Accelerate 2012 - और इसी तरह

क्या आपने Acceler8 2011 समानांतर प्रोग्रामिंग प्रतियोगिता में भाग लिया था? फिर यह पोस्ट आपके बारे में है।
क्या आप वर्तमान एक्सलेरेट 2012 प्रतियोगिता में भाग ले रहे हैं? फिर यह पोस्ट आपके लिए है।
क्या आपने किसी खेल प्रोग्रामिंग प्रतियोगिता में भाग लेने के लिए या सिर्फ योजना बनाई थी? या आप अपनी पहली स्वतंत्र परियोजना शुरू करने जा रहे हैं? फिर आप, स्टर्लिंगिट्ज, मैं आपको हमारे साथ रहने के लिए कहूंगा।

यह पोस्ट पिछले वर्ष की इंटेल प्रतियोगिता का "डिब्रीपिंग" है - एक्लेर 8 2011, जूरी सदस्यों में से एक द्वारा किया गया। उन्होंने मुख्य प्रतिस्पर्धी बिंदुओं पर टिप्पणी की, और इस तरह की प्रतियोगिताओं में भाग लेने और परियोजना प्रबंधन पर भी स्पष्ट और स्पष्ट, लेकिन अभी भी प्रासंगिक सलाह दी।

इस प्रकार, चलो चलें!

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

प्रतियोगिता की चुनौती

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

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

कोड की गुणवत्ता

यहां, प्रतियोगिता के आयोजकों ने चीनी लोक कहावत की सच्चाई को महसूस किया "इससे कोई फर्क नहीं पड़ता कि बिल्ली चूहों को पकड़ती है या नहीं।" किस तरह के अलंकृत निर्माण और अभिव्यक्ति कोड में नहीं थे। आयोजकों ने अपने युवाओं को याद किया जब उन्होंने बहुत कुछ उसी तरह लिखा था। यहाँ परियोजनाओं में TOP-5 "अजीब" स्थान हैं:

5 वां स्थान (कंस्ट्रक्टर में पॉइंटर की m_memory_pointer((char*)this + 1024) ): m_memory_pointer((char*)this + 1024)
4 static const int min_int = -2147483648; स्थान (वैरिएबल इनिशियलाइज़ेशन): static const int min_int = -2147483648;
3 जगह : एक सूचक के साथ संरचना की तुलना करना। लिनक्स के तहत यह संकलन कैसे किया गया?
दूसरा स्थान : 1900 लाइनों के साथ main.c फ़ाइल। दोस्तों, गंभीरता से, आप इसे कैसे नेविगेट करते हैं?
1 स्थान (लगभग एक दर्जन आवेदक): इनपुट-आउटपुट प्रारूप के साथ गैर-अनुपालन।

कभी-कभी मस्तिष्क बस विस्फोट कर जाता है, यह समझने की कोशिश करता है कि प्रतिभागियों का क्या मतलब था। टिप्पणियों की कमी ने समग्र तस्वीर को समाप्त कर दिया (हालांकि मैं झूठ बोलता हूं, कुछ फाइलों में कोड टिप्पणियों के बीच खो गया था)। लेकिन सबसे खास बात यह है कि कभी-कभी इन जटिल अपठनीय निर्माणों ने काम किया, सही ढंग से काम किया, किसी से भी तेजी से काम किया।

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

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

एल्गोरिथम गुणवत्ता

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

यदि आप परिणामों के साथ अंतिम तालिका को देखते हैं, तो आप देख सकते हैं कि पहले पांच स्थान दूसरों के प्रदर्शन में बहुत भिन्न हैं। जानते हो क्यों? क्योंकि ये टीमें बाकी प्रतिभागियों की तुलना में कुछ अधिक गैर-तुच्छ समाधानों के साथ आई थीं।

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

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

उदाहरण के लिए, टिप्पणियों में भविष्य की पीढ़ियों के लिए "संदेश" क्यों नहीं छोड़ा जाता है?