हाल ही में Linux कर्नेल के लिए एक प्रस्ताव जारी किया गया था, जिसमें ए के साथ पैच का एक सेट शामिल करने का प्रस्ताव है memchr() फ़ंक्शन का अनुकूलित कार्यान्वयन एक सरणी में एक चरित्र की खोज के लिए प्रयोग किया जाता है।
memchr () फ़ंक्शन c के पहले उदाहरण के लिए s द्वारा इंगित मेमोरी क्षेत्र के प्रमुख n बाइट्स को स्कैन करता है। स्मृति क्षेत्र में c और बाइट्स दोनों को s द्वारा इंगित किया गया है, जिन्हें अहस्ताक्षरित वर्णों के रूप में व्याख्या किया गया है।
प्रस्ताव वादे तेज हो स्मृति के एक ब्लॉक के भीतर एक चरित्र का पता लगाने के लिए। डेवलपर परीक्षणों में, बड़ी खोजों पर नया कार्यान्वयन लगभग चार गुना तेज हो सकता है
पिछले संस्करण के विपरीत, जिसमें बाइट-दर-बाइट तुलना का उपयोग किया गया था, प्रस्तावित कार्यान्वयन 64-बिट और 32-बिट CPU रजिस्टरों के पूर्ण उपयोग को ध्यान में रखते हुए बनाया गया है। बाइट्स के बजाय, मशीनी शब्दों का उपयोग करके तुलना की जाती है, जो एक बार में कम से कम 4 बाइट्स की तुलना करने की अनुमति देता है।
पैच की इस श्रृंखला ने "memchr ()" को अनुकूलित किया और इसके लिए मैक्रो जोड़ा
"memchr_inv ()" ताकि दोनों फ़ंक्शन बिटमास्क उत्पन्न करने के लिए इसका उपयोग कर सकें।"memchr ()" का मूल कार्यान्वयन बाइट तुलना पर आधारित है,
जो सीपीयू में 64 या 32 बिट रजिस्टर का पूरी तरह से उपयोग नहीं करता है। हम एक लागू करते हैं
शब्दों से तुलना करें ताकि कम से कम 4 बाइट्स की तुलना उसी से की जा सके
मौसम। अनुकूलित memchr() मूल से लगभग 4 गुना तेज है
लंबी जंजीरों के लिए। लिनक्स कर्नेल में, हम पाते हैं कि स्ट्रिंग की लंबाई
"memchr ()" द्वारा खोजा गया ड्राइवर/misc/lkdtm/heap.c में 512 बाइट्स तक है।
बड़े तार पर खोज करते समय, नया संस्करण पुराने की तुलना में लगभग 4 गुना तेज निकला (उदाहरण के लिए, 1000 वर्णों के तार के लिए)। छोटी श्रृंखलाओं के लिए, नए कार्यान्वयन की दक्षता उतनी महत्वपूर्ण नहीं है, लेकिन यह अभी भी मूल संस्करण से अधिक है।
नए प्रस्ताव के बारे में दिलचस्प बात बड़ी श्रृंखलाओं के लिए सुधार है, जिससे समय में काफी सुधार होता है। यह उल्लेखनीय है कि लिनक्स कर्नेल में, memchr() में संसाधित स्ट्रिंग्स का आकार 512 बाइट्स तक पहुँच जाता है। हमारे परीक्षणों में, 512-बाइट स्ट्रिंग्स के लिए प्रदर्शन लाभ, ऐसी स्थिति में जहां खोज वर्ण स्ट्रिंग के अंत में है, यह 20% है।
यह उल्लेखनीय है कि memchr() का मूल संस्करण बाइट-वार तुलना तकनीक के साथ कार्यान्वित किया जाता है, जो 64-बिट या 32-बिट CPU पर रजिस्टरों का पूरी तरह से उपयोग नहीं करता है।
हम संपूर्ण शब्द तुलना का उपयोग करते हैं ताकि सीपीयू पर एक ही समय में 8 वर्णों की तुलना की जा सके। यह कोड डेविड लाइट के कार्यान्वयन पर आधारित है।
हम पहली फ़ाइल के प्रदर्शन को मापने के लिए दो फ़ाइलें बनाते हैं जिसमें गंतव्य वर्ण से औसतन 10 वर्ण आगे हैं। दूसरी फ़ाइल में से पहले कम से कम 1000 वर्ण हैं लक्ष्य चरित्र।
"मेमचर ()" का हमारा कार्यान्वयन थोड़ा है पहले परीक्षण पर बेहतर और मूल से लगभग 4 गुना तेज दूसरे परीक्षण में कार्यान्वयन।
5.18-बिट और 32-बिट आर्किटेक्चर के लिए नए "memchr ()" संस्करण के साथ कर्नेल 64 परीक्षण कोई समस्या नहीं बताई।
क्या होता है यदि p 8 (या 4 बिट लक्ष्य पर 32) बाइट संरेखित नहीं है? सभी लक्ष्य गुटनिरपेक्ष (कुशल) भार का समर्थन नहीं करते हैं, है ना?
मुझे लगता है कि यह काम करता है अगर पी 8 या 4 बाइट गठबंधन नहीं है। मान लें कि स्ट्रिंग 10 बाइट्स है। यहां लूप के लिए पहले 8 बाइट्स की तलाश होगी। यदि गंतव्य वर्ण अंतिम 2 बाइट्स में है, तो लूप के लिए दूसरा इसे ढूंढ लेगा। यह 32-बिट मशीनों पर भी इसी तरह काम करता है।
समग्र प्रदर्शन लाभ का अभी मूल्यांकन नहीं किया गया है अनुकूलित "memchr ()" संस्करण का उपयोग करते समय कर्नेल सबसिस्टम का, न ही इस पर चर्चा की गई है कि कार्यान्वयन को ओवरराइड करना है या नहीं (memchr() फ़ंक्शन कॉल कर्नेल कोड में 129 बार होता है, जिसमें ड्राइवर और फ़ाइल सिस्टम शामिल हैं)।
अंत में यदि आप इसके बारे में अधिक जानने में रुचि रखते हैं, आप विवरण देख सकते हैं निम्नलिखित लिंक में.