मल्टीकोर टेक्स्ट फ़ाइल पार्सिंग

मेरे पास क्वाड कोर मशीन है और एक टेक्स्ट फ़ाइल को पार्स करने के लिए कुछ कोड लिखना चाहूंगा जो सभी चार कोर का लाभ उठाती है। टेक्स्ट फ़ाइल में मूल रूप से प्रति पंक्ति एक रिकॉर्ड होता है।

मल्टीथ्रेडिंग मेरा फोर्टे नहीं है इसलिए मैं सोच रहा हूं कि कोई मुझे कुछ पैटर्न दे सकता है कि मैं फ़ाइल को इष्टतम तरीके से पार्स करने के लिए उपयोग करने में सक्षम हो सकता हूं।

मेरे पहले विचार सभी पंक्तियों को किसी प्रकार की कतार में पढ़ना है और फिर पंक्तियों को कतार से दूर खींचने और उन्हें संसाधित करने के लिए थ्रेड को स्पिन करना है, लेकिन इसका मतलब है कि कतार स्मृति में मौजूद होगी और ये बड़ी बड़ी फाइलें हैं इसलिए मैं ' मैं उस विचार पर इतना उत्सुक नहीं हूँ।

मेरे अगले विचारों में कुछ प्रकार का नियंत्रक होना है जो एक पंक्ति में पढ़ेगा और इसे एक थ्रेड को पर्स करने के लिए असाइन करेगा, लेकिन मुझे यकीन नहीं है कि अगर नियंत्रक लाइनों को तेज़ी से संसाधित कर रहे हैं तो नियंत्रक एक बाधा बन जाएगा उन्हें पढ़ें और असाइन करें।

मुझे पता है कि इनमें से दोनों की तुलना में शायद एक और आसान समाधान है लेकिन फिलहाल मैं इसे देख नहीं रहा हूं।

0
ro fr bn

7 उत्तर

मेरा अनुभव जावा के साथ है, सी # नहीं, इसलिए माफी माँगती है अगर ये समाधान लागू नहीं होते हैं।

तत्काल समाधान जो मैं अपने सिर के ऊपर से सोच सकता हूं, वह एक निष्पादक होगा जो 3 धागे चलाता है ( निष्पादक .newFixedTreadPool , कहें)। इनपुट फ़ाइल से पढ़ने वाली प्रत्येक पंक्ति / रिकॉर्ड के लिए, निष्पादक पर नौकरी को बंद करें ( execorService .submit )। निष्पादक आपके लिए अनुरोध कतार देगा, और 3 धागे के बीच आवंटित करेगा।

शायद बेहतर समाधान मौजूद हैं, लेकिन उम्मीद है कि यह काम करेगा। :-)

ईटीए: वोल्फबाइट के दूसरे समाधान की तरह बहुत कुछ लगता है। :-)

ईटीए 2: System.Threading.ThreadPool .NET में एक बहुत ही समान विचार की तरह लगता है। मैंने कभी इसका इस्तेमाल नहीं किया है, लेकिन यह आपके समय के लायक हो सकता है!

0
जोड़ा

यह एक धागा पढ़ने की बाधाओं को खत्म कर देगा:

open file
for each thread n=0,1,2,3:
    seek to file offset 1/n*filesize
    scan to next complete line
    process all lines in your part of the file
0
जोड़ा

चूंकि बाधा आम तौर पर प्रसंस्करण में होगी और फाइलों से निपटने के दौरान पढ़ने पर नहीं, मैं निर्माता के साथ जाऊंगा -कंस्यूमर पैटर्न। लॉकिंग से बचने के लिए मैं लॉक फ्री सूचियों को देखता हूं। चूंकि आप सी # का उपयोग कर रहे हैं, आप जूलियन बकनल के लॉक-फ्री सूची कोड पर एक नज़र डाल सकते हैं ।

0
जोड़ा

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

या यदि आप चाहें, तो एक पाठक थ्रेड लाइनों को तीन अन्य प्रोसेसर थ्रेड (अपनी स्वयं के कतारों के माध्यम से) असाइन करें और कार्य-चोरी रणनीति । मैंने कभी ऐसा नहीं किया है इसलिए मुझे नहीं पता कि यह कितना मुश्किल है।

0
जोड़ा

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

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

0
जोड़ा

@lomaxx

@Derek & Mark: I wish there was a way to accept 2 answers. I'm going to have to end up going with Wolfbyte's solution because if I split the file into n sections there is the potential for a thread to come across a batch of "slow" transactions, however if I was processing a file where each process was guaranteed to require an equal amount of processing then I really like your solution of just splitting the file into chunks and assigning each chunk to a thread and being done with it.

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

0
जोड़ा

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

प्री-पार्स किए गए डेटा भाग (जहां आप पहले से ही सभी स्ट्रिंग तुलना और "टोकननाइज्ड" कर चुके हैं) को कोड के उस हिस्से में पारित किया जा सकता है जो वास्तव में टोकनयुक्त डेटा के अर्थशास्त्र और ऑर्डरिंग को देखेगा।

साथ ही, आप उल्लेख करते हैं कि आप अपनी फाइल के आकार से बड़ी मात्रा में स्मृति पर कब्जा कर रहे हैं। आपके मेमोरी बजट पर कटौती करने के लिए आप कुछ चीजें कर सकते हैं।

फ़ाइल को टुकड़ों में विभाजित करें और इसे पार्स करें। जैसा कि आप एक समय में काम कर रहे हैं, उतने ही हिस्सों में पढ़ें, कुछ "आगे पढ़ें" के लिए, इसलिए जब आप अगले खंड पर जाने से पहले एक खंड को संसाधित करते हैं तो आप डिस्क पर रुकते नहीं हैं।

वैकल्पिक रूप से, बड़ी फ़ाइलों को स्मृति मैप किया जा सकता है और "मांग" लोड। आप और अधिक धागे सीपीयू से फ़ाइल को संसाधित करने पर काम कर है, तो (आमतौर पर धागे = 1.5-2X CPU के मांग पृष्ठन क्षुधा के लिए एक अच्छी संख्या में है), धागे कि स्मृति मैप की गई फ़ाइल के लिए आईओ पर रोकने कर रहे हैं जब तक ओएस से स्वचालित रूप से रुक जाएगा उनके स्मृति के लिए तैयार है और अन्य धागे प्रक्रिया जारी रहेगी।

0
जोड़ा