डेटा-लोडर परिदृश्य का अवलोकन: संख्यात्मक परिणाम

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

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

4. संख्यात्मक परिणाम

प्रयोगों के पहले सेट के लिए, हमने कार्यकर्ताओं की संख्या (देखें 2) के साथ-साथ बैच आकार को बदलते समय सभी पुस्तकालयों के प्रदर्शन का मूल्यांकन किया। ये प्रयोग निम्नलिखित विनिर्देशों के साथ एक स्थानीय सर्वर में चलाए गए: Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090, और 10TB स्टोरेज (6GB/s) वाला एक HDD [5]।

हमने तीन मोड का मूल्यांकन किया: डिफ़ॉल्ट (एकल GPU), वितरित (दो GPU), और फ़िल्टरिंग (एकल GPU) 0, 1, और 2 श्रमिकों के सभी संभावित संयोजनों के लिए। CIFAR10 और RANDOM के लिए, बैच का आकार या तो 16, 64, या 128 था। CoCo के लिए, हमने छोटे मानों का उपयोग किया: 1, 2, और 4। इन सभी प्रयोगों में 10 का कटऑफ और मॉडल चलाने वाले वैरिएंट (फॉरवर्ड और बैकवर्ड पास) का उपयोग किया गया।

4.1 बैच आकार और श्रमिकों के आधार पर गति

प्रयोगों की जांच करते समय पहली बात जो हमने नोटिस की वह यह है कि लाइब्रेरी के बीच का अंतर समस्या और इस्तेमाल किए गए डेटासेट पर निर्भर करता है। चित्र 4 एक एकल GPU पर CIFAR10 के लिए एक ऐसी तुलना दिखाता है, जबकि 5 CoCo के लिए समान परिणाम दिखाता है, वह भी एक एकल GPU पर।

यह अपेक्षित था क्योंकि बाद में, आगे और पीछे के पास की गणना करने में लगने वाला समय समग्र चलने के समय पर हावी होता है, जो छवि के मामले में नहीं है

आप गति में समग्र अंतर भी देख सकते हैं: प्रति सेकंड 4000 नमूने से केवल 20 तक।

दूसरे, हम बताते हैं कि बैच का आकार बढ़ाने से लगभग सभी मामलों में प्रोसेसिंग की गति बढ़ जाती है। हालाँकि, यह श्रमिकों की संख्या के मामले में नहीं है। हम चित्र 6 में देख सकते हैं कि श्रमिकों की संख्या बढ़ने पर FFCV का प्रदर्शन कम हो जाता है, जबकि डीप लेक 1 श्रमिक पर स्थिर हो जाता है, न कि 2 पर। एक व्याख्या यह है कि पुस्तकालयों के अपने आंतरिक एल्गोरिदम होते हैं जो तय करते हैं कि आवश्यकतानुसार थ्रेड और प्रक्रियाओं को कैसे फैलाया जाए। उपरोक्त बिंदु इन पुस्तकालयों के उपयोगकर्ताओं के लिए प्रासंगिक है, क्योंकि उनमें से एक के साथ अनुभव दूसरे में अच्छी तरह से अनुवाद नहीं कर सकता है।

4.2 डी.डी.पी. का उपयोग करते समय गति में वृद्धि

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

Torchdata में गलत कॉन्फ़िगरेशन का संकेत: बहु-GPU वातावरण में प्रयोग चलाने पर दस्तावेज़ीकरण अधिकांश पुस्तकालयों के लिए सीमित है।

4.3 फॉरवर्ड और बैकवर्ड पास के साथ और बिना तुलना

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

ऐसा प्रतीत होगा कि वहां रुकने में उन्हें वास्तविक समय से अधिक समय लगेगा।

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

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

4.4 डेटा फ़िल्टर करते समय गति संबंधी समझौता

हमारे फ़िल्टरिंग प्रयोगों के लिए, हमने CIFAR10 और RANDOM के लिए दो वर्गों का चयन किया: कुत्ता और ट्रक, और क्रमशः 0 और 13। CoCO के लिए हमने तीन वर्गों का चयन किया: पिज़्ज़ा, सोफ़ा, बिल्ली।

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

यह छोटे डेटासेट के लिए काफी तेज़ है लेकिन बड़े डेटासेट के लिए अव्यवहारिक हो जाता है: PyTorch का उपयोग करके CoCo को फ़िल्टर करना बहुत महंगा था। सामान्य तौर पर, फ़िल्टर करते समय और न करते समय प्रदर्शन काफी समान था[6]। चित्र के समान

7, चित्र 9 में, हम फ़िल्टरिंग के परिणामस्वरूप मंदी देख सकते हैं: भले ही यह टोर्चडाटा और वेबडाटासेट के लिए काफी था, हमने कोको डेटासेट के साथ काम करते समय परिणामों में उलटफेर देखा।

4.5 नेटवर्क पर स्ट्रीमिंग करते समय प्रशिक्षण

आदर्श रूप से, हम डेटासेट स्टोरेज को मशीन लर्निंग ट्रेनिंग प्रक्रिया से अलग कर सकते हैं और अपने डेटा को स्टोर करने वाले डेटाबेस को अपनी पसंद के एमएल फ्रेमवर्क से जोड़ सकते हैं, चाहे वे दोनों कहीं भी स्थित हों। इसमें ट्रेनिंग डेटा को नेटवर्क पर भेजना और काफी गति खोना शामिल है। क्लाउड पर GPU त्वरित हार्डवेयर किराए पर लेने में शामिल उच्च लागतों के साथ, ऐसा लग सकता है कि यह सुविधा इसके लायक नहीं है। लेकिन क्या ऐसा नहीं है?

इस पेपर में विचार की गई कुछ लाइब्रेरी इंटरनेट के माध्यम से सुलभ डेटासेट को निर्दिष्ट करने की अनुमति देती हैं: वेबडेटासेट, हब और डीप लेक इस मामले में विशेष रूप से अच्छे हैं[7]। फिर सवाल यह उठता है: उपयोग में आसानी और चलने के समय के बीच कितना बड़ा समझौता है?

हमने इस प्रश्न में कुछ अंतर्दृष्टि प्रदान करने के लिए निम्नलिखित प्रयोग की स्थापना की। हमने तीन पुस्तकालयों के लिए रैंडम डेटासेट के दो पूर्ण युग चलाए: हब, डीप लेक और वेबडेटासेट, जबकि डेटा की उत्पत्ति को बदलते हुए। तीन स्थानों पर विचार किया गया: प्रयोग की हार्ड ड्राइव चलाने वाली मशीन में एक स्थानीय प्रतिलिपि, S3 बकेट में एक प्रतिलिपि (हमारी मशीन के सबसे नज़दीकी क्षेत्र में), और उसी स्थानीय नेटवर्क के भीतर एक समान मशीन में चलने वाली मिनियो (S3 के बराबर एक ओपन सोर्स जिसे स्थानीय रूप से होस्ट किया जा सकता है) में संग्रहीत एक प्रतिलिपि (दोनों मशीनें WiFi के माध्यम से जुड़ी हुई थीं)। प्रयोग के कंप्यूटर में Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz, 16 GB RAM, NVIDIA GeForce RTX था

2070 रेव, और 256 जीबी स्टोरेज के साथ सैमसंग एसएसडी 850 हार्ड ड्राइव। विलंबता के संबंध में, प्रयोग चलाने वाले वर्कस्टेशन से मिनियो सर्वर (एक ही कमरे में और एक ही स्थानीय वाईफ़ाई में स्थित) तक राउंड ट्रिप टाइम 59.2 ± 58.5ms (न्यूनतम 8.8ms) लगा, जबकि AWS सर्वर में S3-बकेट तक 17.3 ± 1.3ms (न्यूनतम 14.8ms) लगा।

चित्र 10 नौ प्रयोगों के लिए कुल चलने का समय दर्शाता है, और सफेद प्रतिशत स्थानीय मामले की तुलना में मंदी (चलने के समय में वृद्धि) को दर्शाते हैं। हम देख सकते हैं कि भले ही हब और वेबडेटासेट के लिए AWS में जाने पर एक महत्वपूर्ण वृद्धि हुई है, डीप लेक केवल 13% की वृद्धि के साथ लगभग समान गति बनाए रखने में कामयाब रही। परिणाम से एक और उपयोगी अंतर्दृष्टि निकाली जा सकती है: मिनियो सेटिंग AWS सेटिंग की तुलना में लगभग दोगुनी खराब मंदी दिखाती है, जैसा कि चित्र 10 में देखा गया है। इस आउटपुट को मुख्य रूप से ऊपर दिखाए गए औसत राउंड ट्रिप टाइम्स में अंतर से समझाया जा सकता है, जो इस बात पर प्रकाश डालता है कि स्थानीय नेटवर्क (जैसे, आंतरिक कंपनी नेटवर्क[8]) अपने जटिल कॉन्फ़िगरेशन और प्रतिबंधों के कारण डेटासेट होस्ट करने का सबसे कुशल तरीका नहीं हो सकता है। इसके अलावा, यह परिणाम यह भी दर्शाता है कि नेटवर्क पर डेटासेट की सेवा करने वाला स्टोरेज रिमोट ट्रेनिंग को सक्षम करने में महत्वपूर्ण भूमिका निभाता है

सभी अतिरिक्त प्रयोगों के आरेख परिशिष्ट A में दिए गए हैं।

[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf

[6] गति में। PyTorch के लिए सैंपलर का निर्माण पहले से ही किया जाता है, जो कुल चलने के समय को काफी प्रभावित करता है।

[7] स्क्विरल में यह क्षमता है, लेकिन हम मिनियो पता निर्दिष्ट करने में कामयाब नहीं हुए, इसलिए हमने इसे तुलना से बाहर रखा। हमें टॉर्चडाटा के साथ भी ऐसी ही समस्या थी।

[८] इस मामले में एक विश्वविद्यालय नेटवर्क