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