পারফরম্যান্স স্কেলিংয়ের জন্য জন হেনেসির আর্কিটেকচারের ধারণা

কেন হেনেসি আধুনিক পারফরম্যান্সে এখনও প্রাসঙ্গিক

জন হেনেসি এমন একজন আর্কিটেক্ট যিনি স্পষ্টভাবে ব্যাখ্যা করেছেন কেন কম্পিউটার দ্রুততর হয়—এবং কেন সেই উন্নতি কখনও কখনও আটকে যায়। প্রভাবশালী প্রসেসর তৈরি করা এবং RISC ধারণাকে জনপ্রিয় করার পাশাপাশি, তিনি সিস্টেম নির্মাতাদের জন্য পারফরম্যান্স সিদ্ধান্ত নেওয়ার একটি ব্যবহারিক শব্দভাণ্ডারও দিয়েছেন: কি অপ্টিমাইজ করবেন, কি না, এবং কীভাবে পার্থক্য বোঝবেন।

যখন কেউ “পারফরম্যান্স স্কেলিং” বলে, তারা প্রায়ই বোঝায় “আমার প্রোগ্রামটি দ্রুত চলছে।” বাস্তব সিস্টেমে স্কেলিং হলো গতি (speed), খরচ (cost), এবং পাওয়ার/এনার্জি—এই তিনের মধ্যে আলোচনার ফল। যে পরিবর্তনটি একটি ওয়ার্কলোড 20% দ্রুত করতে পারে, সেটা চিপকে আরও দামী করে তুলতে পারে, সার্ভারকে ঠান্ডা করা কঠিন করে দিতে পারে, বা ব্যাটারি দ্রুত খরচ করতে পারে। হেনেসির ফ্রেমিং গুরুত্বপূর্ণ কারণ এটি সেই সীমাবদ্ধতাগুলোকে অপ্রত্যাশিত সমস্যার মতো নয়, বরং স্বাভাবিক ইঞ্জিনিয়ারিং ইনপুট হিসেবে দেখে।

তিনটি বিষয় যা আমরা সারাজুড়ে ব্যবহার করব

প্রথম হলো সমান্তরালতা: একই সময়ে আরও কাজ করা। এটা একটি কোরের ভেতর (ইন্সট্রাকশন-স্তরের কৌশল), কোরগুলোর মধ্যে (থ্রেড), এবং পুরো মেশিন জুড়ে দেখা যায়।

দ্বিতীয় হলো বিশেষায়ন: কাজের জন্য সঠিক টুল ব্যবহার করা। GPU, ভিডিও এনকোডার, এবং ML অ্যাকসেলারেটর গুলো আছে কারণ সাধারণ উদ্দেশ্যের CPU সবকিছু দক্ষভাবে করতে পারে না।

তৃতীয় হলো ট্রেডঅফ: প্রতিটি “জয়” এর একটি দাম আছে। মূল লক্ষ্য হলো কোথায় সীমা আছে—কম্পিউটেশন, মেমরি, কমিউনিকেশন, না কি এনার্জি—এটা বোঝা।

প্রত্যাশা কী

এটি জীবনী নয়। বরং এটি একটি ব্যবহারিক ধারণার সেট যা আপনি বেঞ্চমার্ক পড়া, হার্ডওয়্যার নির্বাচন বা এমন সফটওয়্যার ডিজাইন করার সময় প্রয়োগ করতে পারবেন যা চাহিদার সঙ্গে বাড়ে।

“ফ্রি” স্পিডআপ থেকে বাস্তব সীমা পর্যন্ত

এক দীর্ঘ সময়কাল কম্পিউটিং ইতিহাসে পারফরম্যান্স উন্নতি প্রায় স্বয়ংক্রিয় মনে হতো। ট্রানজিস্টর যত ছোট হচ্ছিল, চিপメーカーরা তত বেশি ট্রানজিস্টর প্যাক করতে পারছিল এবং প্রায়ই উচ্চ ক্লকও চালাতে পারছিল। সফটওয়্যার টিম একই প্রোগ্রাম নতুন মেশিনে চালালেই তা দ্রুত সম্পন্ন হতে দেখতো—পুনরায় ডিজাইনের প্রয়োজন পড়ত না।

“ফ্রি পারফরম্যান্স” যুগ

এই সময়ে প্রতিটি নতুন CPU জেনারেশন প্রায়ই বেশি GHz, প্রতিটি ট্রানজিস্টরের কম খরচ, এবং প্রতিদিনের কোডে লক্ষ্যণীয় স্পিডআপ নিয়ে আসত। অনেকটাই এমন অর্জন যা ডেভেলপারদের আলাদা ভাবে চিন্তা করার দরকার ছিল না; কম্পাইলার ও হার্ডওয়্যার আপগ্রেডই ভারী কাজ করত।

কেন “পাওয়ার ওয়াল” নিয়ম বদলে দিল

অবশেষে, উচ্চতর ক্লকগুলো সহজ সাফল্য থাকা বন্ধ করল কারণ পাওয়ার ও হিট দ্রুত বাড়ছিল। ট্রানজিস্টর ছোট করা আর আগের মতো স্বয়ংক্রিয়ভাবে পাওয়ার কমাচ্ছিল না, এবং ফ্রিকোয়েন্সি বাড়ালে চিপ গরম হয়ে যেত। এমন এক সময় এসেছে যখন সীমা আর “আমরা কি দ্রুততর করতে পারি?” নয়, বরং “আমরা কি এটাকে বিশ্বাসযোগ্যভাবে ঠান্ডা ও পাওয়ার দিতে পারি?” হয়ে দাঁড়ায়।

একটি সহজ উপমা: কার ইঞ্জিন বনাম তাপ ও জ্বালানি

একটি কার ইঞ্জিনের কথা ভাবুন। আপনি প্রায়ই রেভ বাড়িয়ে দ্রুত যেতে পারেন—যতক্ষণ না আপনি সীমাতে পৌঁছান: জ্বালানির ব্যবহার বেড়ে যায়, অংশগুলো অতিরিক্ত গরম হয়, এবং সিস্টেম নিরাপদ থাকে না। CPU-ও একই সীমায় লাগে: “RPM” (ক্লক স্পিড) বাড়ালে disproportionately বেশি এনার্জি লাগে এবং তাপ উৎপন্ন হয়।

ফ্রি স্পিডআপ থেকে স্মার্টার ডিজাইনে

একবার ক্লক স্কেলিং ধীর হয়ে গেলে, পারফরম্যান্স এমন কিছু হয়ে যায় যা ডিজাইনের মাধ্যমে অর্জন করতে হয়: বেশি সমান্তরাল কাজ, ক্যাশ ও মেমরি আরও ভালো ব্যবহার, বিশেষায়িত হার্ডওয়্যার, এবং সতর্ক সফটওয়্যার পছন্দ। হেনেসির বার্তা এই বদলে যাওয়া পরিস্থিতির সঙ্গে খাপ খায়: বড় অর্জনগুলো এখন আসে যখন পুরো সিস্টেম—হার্ডওয়্যার এবং সফটওয়্যার—একসাথে কাজ করে, পরবর্তী চিপটি স্বয়ংক্রিয়ভাবে আপনাকে বাঁচাবে বলে আশা না রেখে।

ইনস্ট্রাকশন-স্তরের সমান্তরালতা: লাভ ও হ্রাসমান রিটার্ন

ইনস্ট্রাকশন-স্তরের সমান্তরালতা (Instruction-Level Parallelism, ILP) হলো একটি একক CPU কোরের ভেতরে ছোট ছোট ধাপ একসাথে করা। এমনকি আপনার প্রোগ্রাম যদি “সিঙ্গল-থ্রেডেড” হয়, প্রসেসর প্রায়ই কাজ ওভারল্যাপ করে ফেলতে পারে: যখন একটি ইনস্ট্রাকশন কিছু জন্য অপেক্ষা করছে, অন্যটি শুরু হতে পারে—যদি সেগুলো পরস্পরের উপর নির্ভর না করে।

পাইপলাইনিং: অ্যাসেম্বলি লাইন ইফেক্ট

ILP বোঝার সহজ উপায় হলো পাইপলাইনিং। একটি অ্যাসেম্বলি লাইনের কথা ভাবুন: একটি ধাপ ইনস্ট্রাকশন ফেচ করে, আরেকটি ডিকোড করে, আরেকটি এক্সিকিউট করে, আরেকটি রেজাল্ট লিখে। পাইপলাইন যখন ভরা থাকে, CPU প্রায় প্রতিটি সাইকেলে একটি ইনস্ট্রাকশন সমাপ্ত করতে পারে, যদিও প্রতিটি ইনস্ট্রাকশনই বহু ধাপ পেরোতে সময় নেয়।

পাইপলাইনিং বহু বছর পারফরম্যান্স বাড়িয়েছে কারণ এটি থ্রুপুট উন্নত করে, প্রোগ্রামারদের সবকিছু পুনর্লিখতে বাধ্য না করে।

ব্রাঞ্চ প্রেডিকশন: পাইপলাইনকে ভর্তি রাখার কৌশল

বাস্তব প্রোগ্রাম সরলভাবে চলে না। এগুলো ব্রাঞ্চে আঘাত করে ("if this, then that"), এবং CPU-কে পরবর্তী কি ফেচ করতে হবে সেটি সিদ্ধান্ত নিতে হয়। যদি এটি জানার জন্য অপেক্ষা করে, পাইপলাইন আটকে যেতে পারে।

ব্রাঞ্চ প্রেডিকশন CPU-র একটি কৌশল যা পরবর্তী পথটি অনুমান করে যাতে কাজ চলতেই থাকে। অনুমান ঠিক হলে পারফরম্যান্স বজায় থাকে। ভুল হলে CPU ভুল-পথের কাজ ফেলে দেয় এবং একটি জরিমানা দেয়—বেঠিক সাইকেল ও শক্তি নষ্ট হয়।

দাম: জটিলতা, শক্তি এবং হ্রাসমান রিটার্ন

ILP আরও এগিয়ে নেওয়ার জন্য হার্ডওয়্যারে বেশি শয়তানি দরকার—স্বাধীন ইনস্ট্রাকশন খুঁজে বের করা, সেগুলোকে নিরাপদে রি-অর্ডার করা, এবং ভুল থেকে উদ্ধার করা। এতে বাড়ে জটিলতা ও ভ্যালিডেশন কাজ, বাড়ে শক্তি ব্যবহার, এবং প্রতিটি প্রজন্মে প্রায়ই ছোট লাভ আসে।

এটাই হেনেসির বারবারের শিক্ষা: ILP মূল্যবান, কিন্তু এর ব্যবহারিক সীমা আছে—সুতরাং স্থায়ী পারফরম্যান্স স্কেলিং শুধুমাত্র “আরও চতুর” সিঙ্গল-কোর এক্সিকিউশনে নির্ভর করতে পারে না।

অ্যামডাহলের আইন: বড় সিদ্ধান্তের পিছনের সহজ গণিত

অ্যামডাহলের আইন মনে করিয়ে দেয় যে কাজের কোনো একটি অংশই দ্রুত করলে পুরো কাজকে অনির্দিষ্টভাবে দ্রুত করা যায় না—বাকি ধীর অংশ যতটা সীমা সেট করে। ভারী গাণিতিক দরকার নেই—আপনাকে শুধু লক্ষ্য করতে হবে কোন অংশ প্যরালালাইজ করা যায় না।

একটি দৈনন্দিন উদাহরণ

ধরা যাক একটি মুদি দোকানে এক গ্রাহক এবং একটি চেকআউট প্রক্রিয়া:

• আইটেম স্ক্যান করা একাধিক রেজিস্টারের মধ্যে ছড়ানো যায় (প্যারালাল কাজ)।
• পেমেন্ট করা (একটা কার্ড, একটা রসিদ) এখনও একটি একক ধাপ (সিরিয়াল কাজ)।

যদি পেমেন্ট সবসময় মোট সময়ের, বলুন, 10% নেয়, তাহলে আপনি স্ক্যানিংকে “অনন্ত” করে দিলেও সর্বোচ্চ মোট 10× স্পিডআপ পাবেন—সিরিয়াল অংশই ছাদ হয়ে দাঁড়ায়।

রান্নার ক্ষেত্রেও একই প্যাটার্ন দেখা যায়: আপনি সবজি কাটা এবং পানি গরম হওয়ার কাজ একসাথে করতে পারেন (প্যারালাল), কিন্তু একটি কেক বেক করার সময় আপনি তা প্যারালালাইজ করতে পারবেন না—ওভেনে 30 মিনিট থাকতে হবে।

কেন ছোট সিরিয়াল অংশ সবকিছুকে প্রভাবিত করে

মুখ্য বার্তা হলো শেষ কয়েক শতাংশ সিরিয়াল কাজই সবকিছুকে সীমাবদ্ধ করে। “99% প্যারালাল” শোনায় চমৎকার—তবু যখন আপনি অনেক কোরে স্কেল করবেন, তখনই দেখবেন যে অবশিষ্ট 1% সিরিয়াল অংশই দীর্ঘ মেয়াদী বাধা।

কিভাবে এটা আর্কিটেকচারের সিদ্ধান্তগুলোকে গঠিত করে

অ্যামডাহলের আইনই ব্যাখ্যা করে কেন "শুধু কোর বাড়ানো" প্রায়ই হতাশ করে। বেশি কোর তখনই সাহায্য করে যখন যথেষ্ট প্যারালাল কাজ থাকে এবং সিরিয়াল বটলনেকগুলো (সিঙ্ক্রোনাইজেশন, I/O, সিংগেল-থ্রেড ধাপ, মেমরি স্টল) ছোট রাখা হয়।

এটি ব্যাখ্যা করে কেন অ্যাক্সেলারেটরগুলো জটিল হতে পারে: যদি একটি GPU একটি কERNEL দ্রুত করে, কিন্তু পাইপলাইনের বাকি অংশ সিরিয়াল থাকে, মোট লাভ সীমিত হতে পারে।

নিয়মের ছোঁয়া

প্যারালালিজমে বিনিয়োগ করার আগে প্রশ্ন করুন: কতটা অংশ সত্যিই প্যারালাল, এবং কি অংশ সিরিয়াল থেকে যায়? তারপর সময় সেই জায়গায় ব্যয় করুন—প্রায়ই "বোরিং" সিরিয়াল পথটাই সীমা নির্ধারণ করে।

থ্রেড-স্তরের সমান্তরালতা: মাল্টিকোর পরিবর্তন

বহু বছর ধরে পারফরম্যান্স লাভের মূল অর্থ ছিল একটি একক CPU কোরকে দ্রুত চালানো। সেই ধারণা বাস্তব সীমায় পৌঁছায়: উচ্চ ক্লক স্পিড হিট করলে তাপ ও পাওয়ার বাড়ে, এবং গভীর পাইপলাইন বাস্তব-জগতের স্পিডআপে অনুপাতিক ফল দেয় না। প্রধান উত্তর ছিল এক চিপে একাধিক কোর রাখা এবং একই সময়ে বেশি কাজ করা।

এক কাজ দ্রুত বনাম একাধিক কাজ

মাল্টিকোর দুইভাবে সাহায্য করে:

• এক কাজকে দ্রুত চালানো—একে প্যারালাল অংশে ভাগ করে (এক প্রোগ্রাম, অনেক থ্রেড)।
• একাধিক কাজ একসঙ্গে চালানো—অনেক প্রোগ্রাম একই সময়ে (প্রতি একটি থ্রেড বা প্রক্রিয়া), যা রেসপন্সনেস ও থ্রুপুট বাড়ায় এমনকি যদি কোনো একক কাজ দ্রুত না হয়।

এই পার্থক্য পরিকল্পনায় গুরুত্বপূর্ণ: একটি সার্ভার দ্রুত উপকৃত হতে পারে একসাথে বেশি অনুরোধ হ্যান্ডেল করে, যেখানে একটি ডেস্কটপ অ্যাপ কেবলমাত্র তখনই দ্রুত অনুভব করবে যদি তার নিজস্ব কাজ প্যারালালাইজ করা যায়।

সফটওয়্যারকে কী করতে হবে উপকৃত হতে

থ্রেড-স্তরের সমান্তরালতা স্বয়ংক্রিয় নয়। সফটওয়্যারকে থ্রেড, টাস্ক কিউ বা ফ্রেমওয়ার্ক ব্যবহার করে প্যারালাল কাজ প্রকাশ করতে হবে—একটি কাজকে স্বাধীন ইউনিটে ভাগ করা উচিত যাতে কোরগুলো ব্যস্ত থাকে এবং একে অপরের উপরে অপেক্ষা না করে।

প্রায়োগিক পদক্ষেপগুলো: লুপ প্যারালালাইজ করা, স্বাধীন ধাপ আলাদা করা (যেমন decode → process → encode), অথবা একাধিক অনুরোধ/ইভেন্ট একসঙ্গে পরিচালনা।

ঘর্ষণ: সমন্বয় ও ভাগ করা সম্পদ

মাল্টিকোর স্কেলিং প্রায়ই ওভারহেডে আটকে:

• সমন্বয় খরচ: লক, কনটেনশন, শিডিউলিং, সিঙ্ক্রোনাইজেশন সবকিছু অতিরিক্ত সময় নেয়।
• ভাগ করা সম্পদ: একাধিক কোর ক্যাশ, মেমরি ব্যান্ডউইথ, এবং I/O নিয়ে প্রতিযোগিতা করে; কোর বাড়ালেই মেমরির গতি স্বয়ংক্রিয়ভাবে বাড়ে না।

হেনেসির বিস্তৃত বার্তা এখানে ঘটে: সমান্তরালতা শক্তিশালী, তবে বাস্তবগত স্পিডআপ নির্ভর করে সতর্ক সিস্টেম ডিজাইন ও পরিচ্ছন্ন পরিমাপের উপর—শুধু কোর বাড়ানো নয়।

মেমরি এবং লুকানো বটলনেক

CPU কেবলই সেই ডেটা নিয়ে কাজ করতে পারে যা হাতে রয়েছে। যখন ডেটা প্রস্তুত নয়—কারণ তা এখনও মেমরি থেকে আসছে—CPU-কে অপেক্ষা করতে হয়। সেই অপেক্ষার সময়টাই মেমরি ল্যাটেন্সি, এবং এটি একটি “দ্রুত” প্রসেসরকে ব্যয়বহুল এক আইডল মেশিনে পরিণত করতে পারে।

ল্যাটেন্সি: ডেটার জন্য অপেক্ষার মূল্য

মেমরিকে শহরের পার্শ্ববর্তী একটি গুদামের মতো ভাবুন। আপনার কর্মীরা (CPU কোর) যদি অত্যন্ত দ্রুতও হন, তারা কিছুই তৈরি করতে পারবে না যদি পার্টস ট্রাফিকে আটকে থাকে। আধুনিক প্রসেসররা প্রতি সেকেন্ডে বিলিয়ন অপারেশন করতে পারে, কিন্তু মেইন মেমরির যাত্রা কয়েকশ CPU সাইকেল নিতে পারে। সেই ব্যবধান জমতে জমতে বড় সমস্যা করে।

ক্যাশ: ঘনিষ্ঠ তাক যেখানে প্রায়ই ব্যবহৃত আইটেম থাকে

ওয়েটিং কমাতে, কম্পিউটারগুলো ক্যাশ ব্যবহার করে—ছোট ও দ্রুত মেমরি এলাকা যা CPU-র কাছে থাকে—যেমন কাছাকাছি তাক যেখানে সবচেয়ে বেশি ব্যবহৃত অংশগুলো রাখা হয়। প্রয়োজনীয় ডেটা যদি তাকেই থাকে ("ক্যাশ হিট"), কাজ চালিয়ে যায়। না থাকলে ("মিস"), CPU-কে দূর থেকে আনতে হয় এবং পুরো ল্যাটেন্সি মূল্য দিতে হয়।

ব্যান্ডউইথ বনাম ল্যাটেন্সি (কেন দুটোই দরকার)

ল্যাটেন্সি হলো “প্রথম আইটেম আসতে কতক্ষণ লাগবে।” ব্যান্ডউইথ হলো “প্রতি সেকেন্ড কতগুলো আইটেম আসতে পারে।” আপনার কাছে বড় রাস্তা থাকতে পারে (উচ্চ ব্যান্ডউইথ) কিন্তু তবুও দীর্ঘ দুরত্ব (উচ্চ ল্যাটেন্সি) থাকতে পারে। কিছু ওয়ার্কলোড অনেক ডেটা স্ট্রিম করে (ব্যান্ডউইথ-বাউন্ড), অন্যগুলো ছোট ছোট ছড়িয়ে থাকা টুকরো বারবার চায় (ল্যাটেন্সি-বাউন্ড)। কোন সিস্টেম ধীর লাগতে পারে উভয় ক্ষেত্রেই।

মেমরি ওয়াল

হেনেসির সীমা সম্পর্কে বিস্তৃত কথাটি এখানে মেমরি ওয়াল হিসেবে আসে: CPU গতি বহু বছর মেমরি এক্সেস টাইমের চেয়ে দ্রুত উন্নতি করেছে, তাই প্রসেসরগুলো অপেক্ষার সময় বাড়িয়েছে। এজন্য পারফরম্যান্স লাভ প্রায়ই ডেটা লোকালিটি উন্নত করে (ক্যাশগুলো বেশি সাহায্য করবে), অ্যালগরিদম পুনর্বিবেচনা করে, অথবা সিস্টেম ব্যালান্স বদলে এনে আসে—কেবল কোর নিজেই দ্রুত করলেই নয়।

পাওয়ার একটি প্রথম-শ্রেণির সীমা

দীর্ঘ সময় ধরে, “দ্রুত” মানে ছিল “ক্লক বাড়াও।” সেই মানসিকতা ভেঙে যায় যখন আপনি পাওয়ারকে একটি কঠোর বাজেট হিসেবে বিবেচনা করেন, পরবর্তী চিন্তা নয়। প্রতিটি অতিরিক্ত ওয়াট তাপ হয়ে যেতে হয়, ব্যাটারি খালি করে, বা বিদ্যুৎ বিল বাড়ায়। পারফরম্যান্স এখনও লক্ষ্য, কিন্তু পারফরম্যান্স-প্রতি-ওয়াটই নির্ধারণ করে কি চালানো যায় এবং কি স্কেল করে।

মূল ট্রেডঅফ: গতি বনাম এনার্জি

পাওয়ার শুধুই একটি কারিগরি বিবরণ নয়; এটা প্রোডাক্ট সীমা। একটি ল্যাপটপ যা বেঞ্চমার্কে ভাল কিন্তু দুই মিনিট পরে থ্রটল করে, ব্যবহারকারীর কাছে ধীর অনুভুত হবে। একটি ফোন যা পেজ রেন্ডার করে তৎক্ষণাৎ কিন্তু ব্যাটারি 20% খরচ করে দেয়, তা খারাপ ডিল। সার্ভারেও, আপনার কাছে অতিরিক্ত কম্পিউট ক্ষমতা থাকতে পারে কিন্তু পাওয়ার বা কুলিং হেডরুম নাও থাকতে পারে।

কেন ফ্রিকোয়েন্সি দ্রুতভাবে ব্যয়বহুল

ফ্রিকোয়েন্সি বাড়ানো অনুপাতে দামী কারণ পাওয়ার দ্রুত বাড়ে যখন আপনি ভোল্টেজ ও সুইচিং অ্যাক্টিভিটি বাড়ান। সরলীকৃতভাবে, ডায়নামিক পাওয়ার প্রায় অনুগত:

• বেশি সুইচিং কাজ (উচ্চ ফ্রিকোয়েন্সি) মানে প্রতি সেকেন্ডে বেশি এনার্জি
• উচ্চ ভোল্টেজ (প্রায়ই স্থিতিশীল উচ্চ ক্লকের জন্য দরকার) খরচকে বহুগুণ বাড়ায়

তাই শেষ 10–20% ক্লক স্পিড ধরে রাখতে অনেক বড় ওয়াট বাড়তি দাবি করতে পারে—ফলশ্রুতিতে থার্মাল সীমা ও থ্রটলিং দেখা যায়, ধারাবাহিক লাভ নয়।

ব্যবহারিক পরিণতি: মোবাইল, ডেটা সেন্টার, ক্লাউড বিল

এই কারণেই আধুনিক ডিজাইনগুলো দক্ষতাকে গুরুত্ব দেয়: বেশি সমান্তরালতার ব্যবহার, স্মার্ট পাওয়ার ম্যানেজমেন্ট, এবং “পর্যাপ্ত” ক্লক যাকে ভালো মাইক্রোআর্কিটেকচারের সাথে মিলিয়ে দেয়া হয়। ডেটা সেন্টারে পাওয়ার একটি খরচ আইটেম যা হার্ডওয়্যার খরচের সমান হতে পারে। ক্লাউডে, অদক্ষ কোড সরাসরি বিল বাড়ায়—কারণ আপনি সময়, কোর, এবং (প্রায়শই পরোক্ষভাবে) এনার্জির জন্যই খরচ দেন।

হার্ডওয়্যার–সফটওয়্যার কো-ডিজাইন একটি কৌশল হিসেবে

হেনেসির বার্তা সোজা: পারফরম্যান্স স্কেলিং শুধুই হার্ডওয়্যার সমস্যা নয় বা শুধুই সফটওয়্যার সমস্যা নয়। হার্ডওয়্যার–সফটওয়্যার কো-ডিজাইন মানে CPU ফিচার, কম্পাইলার, রানটাইম, এবং অ্যালগরিদমগুলোকে বাস্তব ওয়ার্কলোডের চারপাশে মিলিয়ে নেওয়া—যাতে সিস্টেমটি যেটা বাস্তবে চালায় সেটাতেই দ্রুত হয়, কাগজের স্পেকশিটে ভাল দেখানোর জন্য নয়।

কো-ডিজাইন বাস্তবে কেমন লাগে

ক্লাসিক উদাহরণ হলো কম্পাইলার সাপোর্ট যা হার্ডওয়্যার সক্ষমতাগুলো আনলক করে। একটি প্রসেসর বড় ভেক্টর ইউনিট (SIMD), ব্রাঞ্চ প্রেডিকশন, বা অপারেশন ফিউজ করার ইন্সট্রাকশন থাকতে পারে, কিন্তু সফটওয়্যারকে এমনভাবে গঠিত করতে হবে যাতে কম্পাইলার সেগুলো ব্যবহার করতে পারে।

• অটো-ভেক্টরাইজেশন: যদি কোড স্পষ্ট লুপ ব্যবহার করে অ্যারে-র ওপর (এবং জটিল পয়েন্টারের অ্যালিয়াসিং এড়িয়ে যায়), কম্পাইলার বেশি করে ভেক্টর ইন্সট্রাকশন জেনারেট করার সম্ভাবনা পায়।
• প্রোফাইল-গাইডেড অপ্টিমাইজেশন (PGO): বাস্তব এক্সিকিউশন প্রোফাইল দিয়ে কম্পাইল করলে কম্পাইলার কোড লে-আউট rearrange করে এবং ব্রাঞ্চ আচরণ উন্নত করতে পারে—CPU-কে মিসপ্রেডিকশনে কম সময় নষ্ট করাতে।
• ডেটা লে-আউট সিদ্ধান্ত: “array of structs” থেকে “struct of arrays” এ যাওয়া মেমরি অ্যাক্সেসকে নিয়মিত করে তুলতে পারে, ক্যাশ ও প্রিফেচিংকে কার্যকর হতে দেয়।

কেন “ফাস্টার হার্ডওয়্যার” একা প্রায়ই হতাশ করে

যদি বটলনেক মেমরি স্টল, লক কনটেনশন, বা I/O হয়, অধিক ক্লক বা আরো কোর কেবল কটু পরিবর্তন আনতে পারে। সিস্টেম একই সীমায় পৌঁছে যাবে কেবল দ্রুতগতিতে। সফটওয়্যার পরিবর্তন ছাড়া—ভাগ করা ভাল স্ট্রাকচার, কম ক্যাশ মিস, কম সিঙ্ক্রোনাইজেশন—নতুন হার্ডওয়্যার অচল থাকতে পারে।

ব্যবহারিক কো-ডিজাইন চেকলিস্ট

পরামর্শ:

1. ওয়ার্কলোড: শীর্ষ 1–3 গুরুত্বপূর্ণ কাজ কি (রিকোয়েস্ট, কুয়েরি, ফ্রেম, জব)?
2. বটলনেক: সময় বেশি কোথায় যাচ্ছে—কম্পিউট, মেমরি, সিঙ্ক্রোনাইজেশন, না কি I/O?
3. পরিমাপযোগ্য লক্ষ্য: কোন মেট্রিক উন্নত হবে (p95 ল্যাটেন্সি, থ্রুপুট, এনার্জি প্রতি কাজ), এবং কতটা?

RISC এবং সরলতার মূল্য

RISC (Reduced Instruction Set Computing) একটি কেবল স্লোগান নয়, বরং একটি কৌশলগত বাজি: যদি আপনি ইন্সট্রাকশন সেট ছোট ও নিয়মিত রাখেন, প্রতিটি ইন্সট্রাকশন দ্রুত ও পূর্বানুমেয়ভাবে এক্সিকিউট করা যাবে। জন হেনেসি এই দিকটি জনপ্রিয় করতে ভূমিকা রেখেছেন—সরল হার্ডওয়্যারের মাধ্যমে কর্মক্ষমতা বাড়ানো যায় এমন ধারণা প্রচার করে, যদিও সফটওয়্যারকে কিছু বেশি ইন্সট্রাকশন ব্যবহার করতে হতে পারে।

“সরল ইন্সট্রাকশন” আসলে কি দেয়

একটি স্ট্রীমলাইনড ইন্সট্রাকশন সেট সাধারণত ধারাবাহিক ফর্ম্যাট ও সরল অপারেশন (load, store, add, branch) রাখে। এই নিয়মিততা CPU-কে সহজ করে তোলে:

• ইন্সট্রাকশন দ্রুত ডিকোড করা
• পাইপলাইন ভর্তি রাখা (ইন্সট্রাকশন কি মানে তা কম “বুঝতে” সময় খরচ হয়)
• অভ্যন্তরীণ ইউনিটগুলোতে কাজ দক্ষভাবে শিডিউল করা

মূল পয়েন্ট হলো: যখন ইন্সট্রাকশনগুলো পরিচালনা করা সহজ হয়, প্রসেসর ব্যবহারযোগ্য কাজ করার জন্য বেশি সময় ব্যয় করে এবং এক্সসেপশন ও বিশেষ কেস দেখা ও ম্যানেজ করার জন্য কম সময় নষ্ট করে।

কেন সরলতা কর্মক্ষমতা এবং দক্ষতা বাড়ায়

জটিল ইন্সট্রাকশনগুলো প্রোগ্রামের জন্য ইন্সট্রাকশনের সংখ্যা কমাতে পারে, কিন্তু সেগুলো হার্ডওয়্যার জটিলতা বাড়ায়—আরও সার্কিট, বেশি কর্নার কেস, কন্ট্রোল লজিকের উপর বেশি পাওয়ার খরচ। RISC উল্টো করে: সরল বিল্ডিং ব্লক ব্যবহার করে, তারপর কম্পাইলার ও মাইক্রোআর্কিটেকচারের ওপর নির্ভর করে স্পিড বের করে।

এইটি এনার্জি দক্ষতাও বাড়াতে পারে। যেই ডিজাইন কম সাইকেল কণা ও ওভারহেড নষ্ট করে, সেটি কম জুল নষ্ট করে—যা তখনি গুরুত্বপূর্ণ যখন পাওয়ার ও তাপ সীমা করে দেয় কতো দ্রুত চিপ চালানো যায়।

RISC আধুনিক সিস্টেমে কিভাবে দেখা যায়

আধুনিক CPU—মোবাইল, ল্যাপটপ, বা সার্ভারে—RISC-স্টাইলে নীতিমালা বহুস্থানে ব্যবহার করে: নিয়মিত এক্সিকিউশন পাইপলাইন, সহজ অপারেশনের উপর অপ্টিমাইজেশন, এবং কম্পাইলারের ওপর ব্যাপক নির্ভরশীলতা। ARM-ভিত্তিক সিস্টেমগুলো RISC-উৎসের একটি দৃশ্যমান উদাহরণ, কিন্তু মূল পাঠ্য নয় “কে জিতবে।”

অবশিষ্ট নীতি হলো: যেখানে সরলতা উচ্চতর থ্রুপুট, ভাল দক্ষতা, এবং কোর ধারণাগুলোর সহজ স্কেলিং সক্ষম করে সেখানে সরলতা নির্বাচন করুন।

বিশেষায়ন এবং অ্যাক্সেলারেটর: যখন সাধারণ CPU যথেষ্ট নয়

বিশেষায়ন মানে এমন হার্ডওয়্যার ব্যবহার করা যা এক ধরণের কাজ অসাধারণভাবে ভালো করে, সাধারণ-purpose CPU-কে সবকিছু করতে বলার চেয়ে। সাধারণ উদাহরণ: গ্রাফিক্স ও প্যারালাল ম্যাথের জন্য GPU, ম্যাট্রিক্স অপারেশনের জন্য AI অ্যাক্সেলারেটর (NPU/TPU), এবং নির্দিষ্ট কাজের জন্য ফিক্সড-ফাংশন ব্লক যেমন H.264/HEVC/AV1 ভিডিও কোডেক।

কেন অ্যাক্সেলারেটর দ্রুত ও অপচয় কমিয়ে দিতে পারে

CPU ডিজাইন করা হয় নমনীয়তার জন্য: অনেক ইন্সট্রাকশন, প্রচুর কন্ট্রোল লজিক, এবং ব্রাঞ্চি কোড দ্রুত হ্যান্ডলিং। অ্যাক্সেলারেটর সেই নমনীয়তাকে ত্যাগ করে দক্ষতার জন্য। তারা চিপ বাজেটকে বাড়তি কার্যকর অপারেশনের ওপর ফেলে (উদাহরণ: multiply–accumulate), কন্ট্রোল ওভারহেড কমায়, এবং প্রায়ই কম প্রিসিশন (যেমন INT8 বা FP16) ব্যবহার করে যেখানে সঠিকতা অনুমতি দেয়।

এই ফোকাস মানে প্রতি ওয়াটে বেশি কাজ: কম ইন্সট্রাকশন, কম ডেটা মুভমেন্ট, এবং বেশি প্যারালেল এক্সিকিউশন। যদি ওয়ার্কলোডটি একটি পুনরাবৃত্ত কের্নেলে ডমিনেন্ট হয়—রেন্ডারিং, ইনফারেন্স, এনকোডিং—তাহলে এটি নাটকীয় স্পিডআপ দিতে পারে এবং পাওয়ার নিয়ন্ত্রণে রাখে।

যে ট্রেডঅফগুলো উপেক্ষা করা যায় না

বিশেষায়ন খরচ নিয়ে আসে। আপনি নমনীয়তা হারাতে পারেন (হার্ডওয়্যার এক কাজের জন্য দুর্দান্ত আর অন্যগুলোর জন্য সাধারণ), উচ্চ ইঞ্জিনিয়ারিং ও ভ্যালিডেশন খরচ নিতে পারেন, এবং সফটওয়্যার ইকোসিস্টেম—ড্রাইভার, কম্পাইলার, লাইব্রেরি—এর ওপর নির্ভরশীল হতে পারেন যা পিছিয়ে থাকতে বা ভেন্ডরে লক করতে পারে।

কখন বিশেষায়ন মূল্যবান?

অ্যাক্সেলারেটর বেছে নিন যখন:

• ওয়ার্কলোড আপনার কম্পিউট বাজেটের বড়, পুনরাবৃত্ত অংশ।
• কম্পিউটেশন স্থির ও ভালভাবে বোঝা যায় (অল্প অ্যালগরিদম পরিবর্তন)।
• পারফরম্যান্স বা এনার্জি একটি কঠোর সীমা (ব্যাটারি, থার্মাল, ডেটাসেন্টার পাওয়ার)।
• আপনার কাছে成熟 টুলিং ও লাইব্রেরি আছে বা গ্রহণ করতে পারেন।

ওয়ার্কলোড অনিয়মিত, দ্রুত পরিবর্তনশীল, বা সফটওয়্যার খরচ সঞ্চয় তূলনায় বেশি হলে CPU-ই ধরেই রাখুন।

ট্রেডঅফ: কোনো আর্কিটেকচার সিদ্ধান্ত বিনামূল্যের নয়

কম্পিউটার আর্কিটেকচারে প্রতিটি পারফরম্যান্স “জয়” এর সাথে একটা বিল থাকে। হেনেসির কাজ থাকে বারবার এই বাস্তবতায় ফিরে আসা: সিস্টেম অপ্টিমাইজ করা মানে আপনি কি দিয়ে ছাড়তে রাজি তা বেছে নেওয়া।

মূল ট্রেডঅফগুলো যা এড়ানো যায় না

কিছু টানাপড়েনে বারবার দেখা যায়:

• ল্যাটেন্সি বনাম থ্রুপুট: আপনি একটি রিকোয়েস্টকে দ্রুত করতে পারেন (কম ল্যাটেন্সি), বা প্রতি সেকেন্ডে বেশি রিকোয়েস্ট শেষ করতে পারেন (উচ্চ থ্রুপুট)। ইন্টারঅ্যাকটিভ টাস্কের জন্য টিউন করা CPU দ্রুততা অনুভূত হতে পারে, আর ব্যাচ প্রসেসিং টোটাল কাজের ওপর নজর দেয়।

• সরলতা বনাম ফিচার: সরল ডিজাইন সাধারণত অপ্টিমাইজ, ভেরিফাই, এবং স্কেল করা সহজ করে। ফিচার-ভরশালী ডিজাইন কিছু ওয়ার্কলোডকে সাহায্য করে, কিন্তু তারা কমন কেসকে ধীর করতে পারে।

• খরচ বনাম গতি: দ্রুত হার্ডওয়্যার সাধারণত বেশি খরচে পড়ে—অধিক সিলিকন এলাকা, বেশি মেমরি ব্যান্ডউইথ, বেশি কুলিং, বেশি ইঞ্জিনিয়ারিং সময়। কখনও কখনও সবচেয়ে সস্তা “স্পিডআপ” হলো সফটওয়্যার বা ওয়ার্কলোড বদলানো।

যখন একটি মেট্রিক ভালো হয়, আরেকটি প্রায়শই খারাপ হয়

কোনো একটি সংখ্যার জন্য অপ্টিমাইজ করা সহজ এবং ভুলে গিয়ে ব্যবহারকারীর বাস্তব অভিজ্ঞতা খারাপ করে ফেলতে পারে।

উদাহরণস্বরূপ, ক্লক স্পিড বাড়ানো পাওয়ার ও তাপ বাড়ায়, ফলস্বরূপ থ্রটলিং দেখা দেয় যা ধারাবাহিক পারফরম্যান্সকে নষ্ট করে। কোর বাড়ানো থ্রুপুট বাড়ায়, কিন্তু মেমরির কনটেনশন বাড়িয়ে প্রতিটি কোরকে কম কার্যকর করে তুলতে পারে। বড় ক্যাশ মিস কমাতে সাহায্য করে (ল্যাটেন্সির জন্য ভাল) কিন্তু চিপ এলাকার এবং প্রতি অ্যাক্সেস এনার্জি বাড়ায় (খরচ ও দক্ষতার জন্য খারাপ)।

ওয়ার্কলোডের জন্য ডিজাইন করুন, গর্বের নম্বরের জন্য নয়

হেনেসির পারফরম্যান্স দৃষ্টিভঙ্গি ব্যবহারিক: আপনি যে ওয়ার্কলোড নিয়ে চিন্তা করেন সেটি সংজ্ঞায়িত করুন, তারপর সেই বাস্তবতার জন্য অপ্টিমাইজ করুন।

একটি সার্ভার যা মিলিয়ন মিলিয়ন অনুরোধ পরিচালনা করে তা সততা পূর্ণ থ্রুপুট ও এনার্জি-পার-অপারেশন চায়। একটি ল্যাপটপ রেসপন্সনেস ও ব্যাটারি লাইফ নিয়ে চিন্তা করে। একটি ডেটা পাইপলাইন মোট কাজের সময় উন্নত হলে উচ্চ ল্যাটেন্সি মেনে নিতে পারে। বেঞ্চমার্ক ও হেডলাইন স্পেস আছে, কিন্তু কেবলমাত্র যদি তারা আপনার বাস্তব ব্যবহারকেস মেলে।

আপনি পরে বাস্তবে লাগাতে পারবেন এমন একটি নোট

একটি ছোট টেবিল যোগ করার কথা বিবেচনা করুন যেখানে কলাম থাকবে: Decision, Helps, Hurts, Best for। সারিগুলো হতে পারে “more cores,” “bigger cache,” “higher frequency,” “wider vector units,” এবং “faster memory.” এতে ট্রেডঅফগুলো বাস্তবসম্মতভাবে দেখা যায়—আউটকামসমূহের সঙ্গে, হাইপ নয়।

নিজেকে মিথ্যা না করে পারফরম্যান্স মাপা

পারফরম্যান্স দাবি তাদের মাপের উপরই সত্য। একটি বেঞ্চমার্ক পুরোপুরি “ঠিক” হতে পারে এবং তবুও বিভ্রান্ত করতে পারে যদি তা আপনার বাস্তব ওয়ার্কলোডের অনুরূপ না: ভিন্ন ডেটা সাইজ, ক্যাশ আচরণ, I/O প্যাটার্ন, কনকারেন্সি, বা পড়া-ব_write-র মিশ্রণ ফল উল্টে দিতে পারে। এজন্য হেনেসির পরম্পরা মনে করে বেঞ্চমার্কিং হলো একটি পরীক্ষা, ট্রফি নয়।

ব্যবহারকারীর অভিজ্ঞতা সত্যিই ব্যাখ্যা করে এমন মেট্রিকগুলো

থ্রুপুট হলো আপনি প্রতি ইউনিট সময়ে কত কাজ শেষ করছেন (রিকোয়েস্ট/সেকেন্ড, জব/ঘণ্টা)। এটি ক্যাপাসিটি পরিকল্পনার জন্য ভালো, কিন্তু ব্যবহারকারী গড়কে অনুভব করে না।

টেইল ল্যাটেন্সি ধীরতর রিকোয়েস্টগুলোতে মনোযোগ করে—সেগুলো প্রায়শই p95/p99 হিসেবে রিপোর্ট করা হয়। একটি সিস্টেম গড়ে চমৎকার ল্যাটেন্সি থাকতে পারে অথচ p99 ভয়াবহ হতে পারে কিউয়িং, GC পজ, লক কনটেনশন, বা noisy neighbors-র কারণে।

উপযোগিতা (Utilization) দেখে কতোটা রিসোর্স ব্যস্ত (CPU, মেমরি ব্যান্ডউইথ, ডিস্ক, নেটওয়ার্ক)। উচ্চ উপযোগিতা ভালো—যতক্ষণ না এটি আপনাকে লম্বা কিউয়ে ঠেলে দেয় যেখানে টেইল ল্যাটেন্সি বাড়ে।

ব্যবহারিক ইভ্যালুয়েশন লুপ

একটি পুনরাবৃত্ত লুপ ব্যবহার করুন:

1. মাপুন প্রতিনিধিত্বমূলক ইনপুট ও বাস্তব কনকারেন্সিতে।
2. একটা জিনিস পরিবর্তন করুন (কম্পাইলার ফ্ল্যাগ, থ্রেড কাউন্ট, ডেটা লে-আউট, ক্যাশ নীতি, হার্ডওয়্যার সেটিং)।
3. আবার মাপুন, এবং কেবল গড় নয়, ভ্যারিয়াবিলিটি ও টেইল মিলিয়েই তুলনা করুন।

কনফিগারেশন, ভার্সন, ও পরিবেশের নোট রাখুন যাতে পরে পুনরায় ফলাফল তৈরি করা যায়।

আত্মানির্মিত বিভ্রান্তি এড়ানো

সেরা রানটি চয়ন করবেন না, সবচেয়ে আকর্ষণীয় ডেটাসেট বেছে নেবেন না, বা এমন একমাত্র মেট্রিক ধরে ফেলবেন যা আপনার পরিবর্তনকে ভালো দেখায়। এবং সাধারণীকরণ করবেন না: একটি মেশিন বা বেঞ্চমার্কে যে জয় হয় তা আপনার ডেপ্লয়মেন্ট, আপনার খরচ সীমা, বা ব্যবহারকারীদের পিক-ঘন্টার ট্রাফিকের ক্ষেত্রে নেই।

মূল উপসংহার এবং আজকের জন্য প্রয়োগযোগ্যভাবে

হেনেসির স্থায়ী বার্তা ব্যবহারিক: পারফরম্যান্স ইচ্ছাপূরকভাবে বড় হয় না—এটি তখনই বড় হয় যখন আপনি সঠিক ধরনের সমান্তরালতা বেছে নেন, এনার্জি সীমাকে সম্মান করেন, এবং সেই ওয়ার্কলোডগুলোর জন্য অপ্টিমাইজ করেন যেগুলো বাস্তবে গুরুত্বপূর্ণ।

কৌশলগত শিক্ষা

সমান্তরালতা প্রধান পথ, কিন্তু কখনোই "ফ্রি" নয়। ILP, মাল্টিকোর থ্রুপুট, অথবা অ্যাক্সেলারেটর—সহজ লাভ শেষ হয় এবং সমন্বয় ওভারহেড বাড়ে।

দক্ষতা একটি ফিচার। এনার্জি, তাপ, এবং মেমরি মুভমেন্ট প্রায়শই বাস্তবগত গতি কে ঘোর দিয়ে দেয় অনেক আগে যে শীর্ষ "GHz" সংখ্যা পৌঁছায়। একটি দ্রুত ডিজাইন যা পাওয়ার বা মেমরি সীমা মেনে চলতে পারে না, ব্যবহারকারী-দৃশ্যমান জয় দেবে না।

ওয়ার্কলোড ফোকাস সাধারণ অপ্টিমাইজেশনের চেয়ে উত্তম। অ্যামডাহলের আইন মনে করিয়ে দেয় সময় যেখানে ব্যয় হবে সেখানে শুয়োর খোঁজা: প্রথম প্রোফাইল করুন; তারপর অপ্টিমাইজ করুন।

নির্মাতাদের জন্য ব্যবহারিক চেকলিস্ট

• মাপ দিয়ে শুরু করুন: আর্কিটেকচার পরিবর্তনের আগে শীর্ষ বটলনেক (CPU, মেমরি, স্টোরেজ, নেটওয়ার্ক) চিহ্নিত করুন।
• পরিকল্পনায় অ্যামডাহলের আইন ব্যবহার করুন: প্যারালালাইজেশনে বিনিয়োগ করার আগে সর্বোচ্চ সুবিধা অনুমান করুন।
• সরল, স্কেলযোগ্য ডিজাইন পছন্দ করুন: কম বিশেষ কেস প্রায়ই পূর্বানুমেয়তা ও সহজ টিউনিং দেয়।
• পাওয়ার ও খরচকে প্রথম দিন থেকেই সীমা মনে করুন, পরে না বলে নয়।
• প্রোডাক্টের জন্য হার্ডওয়্যার মেলান: GPU/NPUs বিবেচনা করুন কেবল যখন ওয়ার্কলোড স্থির, ভালভাবে বোঝা যায়, এবং জটিলতা ন্যায্য হয়।

এটি দৈনন্দিন সফটওয়্যার নির্মাণে কিভাবে মেলে

এই ধারনাগুলো শুধুমাত্র CPU ডিজাইনারদের জন্য নয়। যদি আপনি একটি অ্যাপ তৈরি করেন, একই সীমাবদ্ধতা কিউয়িং, টেইল ল্যাটেন্সি, মেমরি চাপ, এবং ক্লাউড খরচ হিসেবে দেখা যাবে। “কো-ডিজাইন” অপারেশনালাইজ করার একটি ব্যবহারিক উপায় হলো আর্কিটেকচার সিদ্ধান্তগুলোকে ওয়ার্কলোড ফিডব্যাকের কাছাকাছি রাখা: মাপুন, পুনরাবৃত্তি করুন, এবং চালান।

যদি আপনারা একটি চ্যাট-চালিত বিল্ড ওয়ার্কফ্লো ব্যবহার করেন যেমন Koder.ai, এটি বিশেষভাবে উপকারী হতে পারে: আপনি দ্রুত একটি সার্ভিস বা UI প্রোটোটাইপ তৈরি করে, তারপর প্রোফাইলিং ও বেঞ্চমার্ক ব্যবহার করে সিদ্ধান্ত নিতে পারেন যে প্যারালালিজম (উদাহরণস্বরূপ, রিকোয়েস্ট কনকারেন্সি) অনুসরণ করবেন, ডেটা লোকালিটি উন্নত করবেন (কম রাউন্ড-ট্রিপ, টাইটার কুয়েরি), না কি বিশেষায়ন নিবেন (ওজনদার টাস্ক অফলোড করা)। প্ল্যাটফর্মের planning mode, snapshots, এবং rollback পারফরম্যান্স-প্রভাবিত পরিবর্তনগুলো ধাপে ধাপে পরীক্ষা করা সহজ করে—অপ্টিমাইজেশনকে একটিমাত্র পথ বানিয়ে না।

আরও পড়াশোনা

• John L. Hennessy & David A. Patterson, Computer Architecture: A Quantitative Approach.
• John L. Hennessy & David A. Patterson, Computer Organization and Design.
• Gene Amdahl, “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities” (1967).
• Hennessy & Patterson, “A New Golden Age for Computer Architecture” (ACM Turing Lecture).

আপনি যদি আরও এরকম পোস্ট চান, ব্রাউজ করুন /blog.