एक अच्छा सॉफ्टवेयर डिजाइन के लिए 20% प्रदर्शन जुर्माना

17

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

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

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

जो मुझे मेरे सवाल पर लाता है: अगर मुझे इसका मतलब अच्छा ऑब्जेक्ट मॉडल लगता है तो मुझे एक प्रदर्शन हानि कितनी होनी चाहिए?

linear-algebra sparse-matrix oop

— डैनियल शेपरो
स्रोत

आप किस विरल मैट्रिक्स ऑपरेशन को माप रहे थे?

— बिल बर्थ

मैट्रिक्स-वेक्टर गुणा। से लेकर मेट्रिसेस आकार में थे । मैंने उन्हें औसत डिग्री साथ Erdos-Renyi यादृच्छिक रेखांकन के लिए ग्राफ । इसके अलावा, 20% का आंकड़ा कुछ मशीनों पर खराब हो जाता है, इसलिए अब मैं पूरी बात को टॉस करने के लिए इच्छुक हूं। गहरी आह

n = 1024, . . ., 16384

$n = 1024,...,16384$

d = \log_{2} n

$d = \log_2n$

— डैनियल शेपरो

3

आप किस प्रोग्रामिंग भाषा का उपयोग कर रहे हैं? आमतौर पर C ++ जैसी कोई चीज आपको कम (या कोई नहीं) लागत पर सुरुचिपूर्ण (ish) डिजाइनों से दूर कर देगी। मेटा-प्रोग्रामिंग (जावा, फोरट्रान, आदि) के बिना अन्य भाषाओं में 20% लागत उचित लगती है।

— LKlevin

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

— किरिल

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

— एलेक्सा

9

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

इन बाधाओं के कुछ विशिष्ट उदाहरण यहां दिए गए हैं, जैसा कि आपके विरल मैट्रिक्स लाइब्रेरी के डिजाइन पर लागू किया जा सकता है:

एक महीने में पूरा हुआ
आपके लैपटॉप और कई वर्कस्टेशन पर सही तरीके से चलता है
कुशलता से चलता है

सॉफ्टवेयर इंजीनियरिंग से वैज्ञानिक कुछ अन्य सामान्य आवश्यकताओं पर धीरे-धीरे ध्यान दे रहे हैं:

प्रलेखन (उपयोगकर्ता गाइड, ट्यूटोरियल, कोड टिप्पणी)
रखरखाव (संस्करण नियंत्रण, परीक्षण, मॉड्यूलर डिजाइन)
पुन: प्रयोज्य (मॉड्यूलर डिजाइन, "लचीलापन")

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

आपके प्रश्न पर वापस आते हुए, "अच्छा डिज़ाइन", पर्याप्त विकास समय प्रदान करता है, कभी भी प्रदर्शन का त्याग नहीं करना चाहिए। यदि उद्देश्य ऐसा कोड बनाना है जो जितनी तेजी से संभव हो सके, तो उन बाधाओं के आसपास कोड डिजाइन किया जाना चाहिए। आप कोड पीढ़ी, इनलाइन असेंबली जैसी तकनीकों का उपयोग कर सकते हैं, या अपनी समस्या को हल करने में मदद करने के लिए उच्च-स्तरीय पुस्तकालयों का लाभ उठा सकते हैं।

लेकिन क्या होगा अगर आपके पास पर्याप्त विकास समय नहीं है? क्या अच्छा है? खैर, यह निर्भर करता है, और कोई भी आपको अधिक संदर्भ के बिना इस सवाल का एक अच्छा जवाब देने में सक्षम होने जा रहा है।

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

— एरन अहमदिया
स्रोत

मैं कोड जनरेटर के बारे में उत्सुक हूं - मुझे लगता है कि वे मेरे लिए उपयोगी हो सकते हैं लेकिन मुझे चिंता है कि वे बनाए रखना मुश्किल होगा। मुझे पता है कि जावा प्रोग्रामर उनका बहुत उपयोग करते हैं, लेकिन वे अक्सर विशिष्ट अनुप्रयोगों के लिए कोड उत्पन्न करने के लिए अनुकूलित होते हैं। क्या आप किसी ऐसे वैज्ञानिक कोड के बारे में जानते हैं जो उनका उपयोग करता है?

— डैनियल शेपरो

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

— एरन अहमदिया

12

यह एक सवाल है कि आप अपना समय किस पर व्यतीत करते हैं। हम में से ज्यादातर के लिए, हम समय प्रोग्रामिंग के 3/4 और परिणामों के इंतजार में 1/4 समय बिताते हैं। (आपकी संख्या भिन्न हो सकती है, लेकिन मुझे लगता है कि संख्या पूरी तरह से गुण के बिना नहीं है।) इसलिए, यदि आपके पास एक ऐसा डिज़ाइन है जो आपको दो बार तेज कार्यक्रम करने की अनुमति देता है (1.5 समय इकाइयों के बजाय एक समय इकाई का 3/4), तो आप प्रदर्शन में 300% हिट ले सकता है (1/4 से 1 टाइम यूनिट तक) और आप अभी भी समस्या को सुलझाने में खर्च किए गए वास्तविक समय के मामले में आगे आते हैं।

दूसरी ओर, यदि आप भारी शुल्क गणना कर रहे हैं, तो आपकी गणना अलग-अलग दिख सकती है और आप अपने कोड का अनुकूलन करते हुए अधिक समय व्यतीत करना चाह सकते हैं।

मेरे लिए, 20% काफी अच्छा व्यापार बंद जैसा लगता है यदि आप अधिक उत्पादक होते हैं।

— वोल्फगैंग बंगर्थ
स्रोत

अच्छा जवाब, मैं वह महत्व भी जोड़ूंगा जहां प्रदर्शन मायने रखता है। एक दिया गया वैज्ञानिक कोड केवल मैट्रिक्स गुणा नहीं कर रहा है; यदि आपके रनटाइम का 20% मैट्रिक्स गुणन में है, तो एक 20% प्रदर्शन हिट होने पर कुल मिलाकर केवल 4% का अंतर होता है, और मैं आसानी से उपयोग में लाई जाने वाली लाइब्रेरी के बदले में ख़ुशी से लेना चाहता हूँ।

— ऑरेलियस

1

और एक बेहतर लिखित लाइब्रेरी का मतलब है कम कीड़े, ताकि आप कम समय में गलत परिणामों की प्रतीक्षा करें।

— डेविड

4

IMHO 50% तक का जुर्माना (जो भी कारण हो) वह बुरा नहीं है।

वास्तव में मैंने केवल संकलक के प्रकार के आधार पर प्रदर्शन में 0-30% का अंतर देखा है। यह पेट्सक के विरल मैटल्ट रूटीन के लिए है, जो कम ऑर्डर एफई विवेक से उत्पन्न होने वाले मेट्रिसेस पर है।

— stali
स्रोत

1

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

— MirekE
स्रोत

मुझे नहीं लगता कि यह सवाल का जवाब देता है।

— nicoguaro

0

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

— jolvi
स्रोत