সম্প্রতি লিনাক্স কার্নেলের জন্য একটি প্রস্তাব প্রকাশ করা হয়েছে, যাতে এটি a এর সাথে প্যাচগুলির একটি সেট অন্তর্ভুক্ত করার প্রস্তাব করা হয় memchr() ফাংশনের অপ্টিমাইজ করা বাস্তবায়ন একটি অ্যারেতে একটি অক্ষর অনুসন্ধান করতে ব্যবহৃত হয়।
memchr() ফাংশন c-এর প্রথম দৃষ্টান্তের জন্য s দ্বারা নির্দেশিত মেমরি এলাকার লিডিং n বাইট স্ক্যান করে। s দ্বারা নির্দেশিত মেমরি এলাকায় c এবং বাইট উভয়ই স্বাক্ষরবিহীন অক্ষর হিসাবে ব্যাখ্যা করা হয়।
প্রস্তাব প্রতিশ্রুতি দ্রুত হতে মেমরির একটি ব্লকের মধ্যে একটি চরিত্র সনাক্ত করতে। বিকাশকারী পরীক্ষায়, নতুন বাস্তবায়ন বড় অনুসন্ধানে প্রায় চারগুণ দ্রুত হতে পারে
পূর্ববর্তী সংস্করণ থেকে ভিন্ন, যা একটি বাইট-বাই-বাইট তুলনা ব্যবহার করে, প্রস্তাবিত বাস্তবায়ন 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-তে রেজিস্টারগুলি সম্পূর্ণরূপে ব্যবহার করে না।
আমরা পুরো শব্দ তুলনা ব্যবহার করি যাতে CPU-তে একই সময়ে 8টি অক্ষর তুলনা করা যায়। এই কোড ডেভিড লাইট এর বাস্তবায়ন উপর ভিত্তি করে.
প্রথম ফাইলের কর্মক্ষমতা পরিমাপ করার জন্য আমরা দুটি ফাইল তৈরি করি যেটিতে গন্তব্য অক্ষরের চেয়ে গড়ে 10টি অক্ষর রয়েছে। দ্বিতীয় ফাইলটিতে এর আগে কমপক্ষে 1000টি অক্ষর রয়েছে লক্ষ্য চরিত্র।
আমাদের "memchr()" এর বাস্তবায়ন সামান্য প্রথম পরীক্ষায় ভাল এবং আসলটির চেয়ে প্রায় 4 গুণ দ্রুত দ্বিতীয় পরীক্ষায় বাস্তবায়ন।
5.18-বিট এবং 32-বিট আর্কিটেকচারের জন্য নতুন "memchr()" ভেরিয়েন্টের সাথে কার্নেল 64 পরীক্ষা করা হচ্ছে কোনো সমস্যা প্রকাশ করেনি।
p 8 (বা 4 বিট টার্গেটে 32) বাইট সারিবদ্ধ না হলে কি হবে? সব টার্গেট অ-সারিবদ্ধ (দক্ষ) লোড সমর্থন করে না, তাই না?
আমি মনে করি এটি কাজ করে যদি p 8 বা 4 বাইট সারিবদ্ধ না হয়। ধরা যাক স্ট্রিংটি 10 বাইট। এখানে লুপটি প্রথম 8 বাইটের সন্ধান করবে। যদি গন্তব্য অক্ষরটি শেষ 2 বাইটে থাকে তবে লুপের জন্য দ্বিতীয়টি এটি খুঁজে পাবে। এটি 32-বিট মেশিনে এই মত কাজ করে।
সামগ্রিক কর্মক্ষমতা লাভ এখনও মূল্যায়ন করা হয়নি অপ্টিমাইজ করা "memchr()" ভেরিয়েন্ট ব্যবহার করার সময় কার্নেল সাবসিস্টেমগুলির মধ্যে, এবং বাস্তবায়নকে ওভাররাইড করতে হবে কিনা তা নিয়ে আলোচনা করা হয়নি (মেমচআর() ফাংশন কলটি কার্নেল কোডে 129 বার ঘটে, ড্রাইভার এবং ফাইল সিস্টেম সহ)।
পরিশেষে আপনি যদি এটি সম্পর্কে আরও জানতে আগ্রহী হন, আপনি বিশদ পরীক্ষা করতে পারেন নীচের লিঙ্কে.