डेटा-लोडर परिदृश्य का अवलोकन: चर्चा

लिंक की तालिका

• सार और परिचय
• डेटा लोडर
• प्रयोगात्मक स्थापना
• संख्यात्मक परिणाम
• बहस
• संबंधित कार्य
• निष्कर्ष, आभार और संदर्भ
• ए. संख्यात्मक परिणाम जारी

5. चर्चा

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

उपरोक्त बिंदुओं के मद्देनजर, हम पाठकों को इस पेपर के गुणात्मक पहलुओं को आत्मसात करने के लिए प्रोत्साहित करते हैं, लेकिन सावधान रहें कि यहां प्राप्त आंकड़े बदल सकते हैं।

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

हम देखते हैं कि ऐसा नहीं लगता कि सभी अन्य की तुलना में कोई बेहतर लाइब्रेरी है। इसके बजाय, हर एक की अपनी खूबियाँ हैं। FFCV के उदाहरण पर विचार करें: यह हमारे प्रयोगों में सबसे तेज़ लगता है, लेकिन लेबल परिवर्तनों के लिए समर्थन की कमी इसे उन परियोजनाओं में अपनाने से रोकती है जिनमें ऐसी सुविधाओं की आवश्यकता होती है।

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

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