মেমরি হায়ারার্কি, cache আর virtual memory

১ · দ্রুত মানেই দামি — কেন একটিমাত্র মেমরি যথেষ্ট নয়

পর্ব ০৪-এ আপনি দেখেছেন, RAM হলো কম্পিউটারের কাজের টেবিল আর SSD/HDD হলো আলমারি; CPU-র ভেতরে আরও ছোট আর দ্রুত register আর cache আছে। এই পর্বে একটি প্রশ্নের গভীরে যাব: এত রকম মেমরি কেন? সবকিছু একটিমাত্র, অতি দ্রুত মেমরিতে রাখলেই তো ঝামেলা মিটে যেত।

সমস্যা হলো, পদার্থবিজ্ঞান আর টাকা — দুটোই একসাথে এমন মেমরি বানাতে দেয় না, যা একই সঙ্গে খুব দ্রুত, খুব বড় আর খুব সস্তা। দুটি কারণ দেখুন:

• প্রতি byte-এর খরচ। cache তৈরি হয় SRAM দিয়ে — প্রতিটি bit রাখতে সাধারণত ৬টি ট্রানজিস্টর. RAM তৈরি হয় DRAM দিয়ে — প্রতি bit-এ ১টি ট্রানজিস্টর আর একটি ছোট ক্যাপাসিটর। SSD-র flash-এ একটি সেলেই কয়েকটি bit. ফলে একই টাকায় cache-এর চেয়ে বহু গুণ বেশি RAM, আর RAM-এর চেয়ে বহু গুণ বেশি SSD কেনা যায়।
• দূরত্ব আর আকার। ৩ GHz-এর CPU-র এক ক্লক-টিকে আলো যায় মাত্র ১০ সেন্টিমিটারের মতো, চিপের তারে সংকেত আরও কম। মেমরি যত বড়, খুঁজতে আর CPU পর্যন্ত আসতে পথ তত লম্বা। তাই সবচেয়ে দ্রুত মেমরিকে হতেই হবে ছোট আর CPU-র গায়ে লাগানো।

২ · মেমরির পিরামিড — register থেকে টেপ পর্যন্ত

স্তরগুলোকে একটি পিরামিডে সাজালে ছবিটা পরিষ্কার হয়। চূড়ায় সবচেয়ে ছোট আর দ্রুত, নিচে সবচেয়ে বড় আর ধীর। প্রতিটি স্তর নিচের স্তরের একটি ছোট, দ্রুত “কপি-ঘর” হিসেবে কাজ করে।

এবার প্রতিটি স্তরের আনুমানিক মাপ দেখুন। সতর্কতা: সংখ্যাগুলো আজকের সাধারণ ডেস্কটপ-ল্যাপটপের মোটামুটি ধারণা, প্রতিটি CPU আর ডিভাইসে আলাদা, আর প্রতি বছর বদলায়। মুখস্থ করার জন্য নয় — অনুপাত বোঝার জন্য।

মানুষের সময়ে — যদি L1 cache হয় ১ সেকেন্ড

ন্যানোসেকেন্ড (ns) এত ছোট যে মন ধরতে পারে না। একটি কৌশল: সব সময়কে ১০০ কোটি দিয়ে গুণ করুন, অর্থাৎ ১ ns-কে বানান ১ সেকেন্ড। ওপরের আনুমানিক মান থেকে হিসাব (প্রতিটি সারি একটি দৃষ্টান্ত, নির্দিষ্ট মাপ নয়):

এই টেবিলের সবচেয়ে বড় শিক্ষা: RAM থেকে SSD-তে নামলেই সময় প্রায় এক হাজার গুণ বেড়ে যায়, আর L1 থেকে RAM-এ নামলে প্রায় একশো গুণ। ৩ GHz-এর একটি CPU RAM-এর একটি উত্তরের জন্য অপেক্ষা করতে করতে প্রায় ৩০০টি ক্লক-টিক পার করে ফেলে। মেমরি হায়ারার্কির পুরো খেলা এই ফাঁক লুকানোর খেলা।

৩ · Locality — cache কেন এত ভালো কাজ করে

একটি ধাঁধা: একটি সাধারণ ল্যাপটপে RAM ধরুন ১৬ GB, আর L1 cache একটি কোরে মাত্র ৪৮ KB — তিন লাখ ভাগের এক ভাগেরও কম। তবু CPU-র চাওয়া ডেটার সাধারণত ৯০% বা তারও বেশি এই ছোট্ট L1-এই পাওয়া যায়। কীভাবে? উত্তর প্রোগ্রামের স্বভাবে, যার নাম locality of reference. প্রোগ্রাম মেমরির সব জায়গা সমানভাবে ব্যবহার করে না; একটি সময়ে সে ঘুরেফিরে অল্প কিছু জায়গাতেই কাজ করে। Locality দুই রকম:

“পাশের জিনিসও নিয়ে আসা” কাজটি হয় cache line দিয়ে। CPU একটি byte চাইলেও RAM থেকে cache-এ আসে পুরো একটি টুকরো — বেশিরভাগ আধুনিক x86 আর ARM CPU-তে ৬৪ byte (Apple-এর কিছু চিপে ১২৮ byte). একটি সাধারণ পূর্ণসংখ্যা (int) ৪ byte, তাই একটি লাইনে পাশাপাশি ১৬টি int. নিচের stepper-এ দেখুন, একটি অ্যারের যোগফল বের করার লুপে কী ঘটে:

Locality প্রাকৃতিক নিয়ম নয়, একটি পর্যবেক্ষণ। যে প্রোগ্রাম মেমরির এলোমেলো জায়গায় লাফায়, তাকে cache খুব একটা সাহায্য করতে পারে না — অংশ ৫-এর সিমুলেটরে দেখবেন।

৪ · Cache hit, miss আর গড় সময়ের হিসাব

CPU কোনো ঠিকানার ডেটা চাইলে প্রথমে cache-এ খোঁজে। পাওয়া গেলে বলে cache hit — খুশির খবর। না পেলে cache miss — পরের স্তরে যেতে হবে। আধুনিক CPU-তে তিন স্তরের cache থাকে, তাই একটি miss L1 থেকে L2, L2 থেকে L3, শেষে RAM পর্যন্ত গড়াতে পারে। নিচের stepper-এ একটি ভ্যারিয়েবল x প্রথমবার পড়ার পুরো যাত্রা দেখুন:

Hit ratio আর গড় অ্যাক্সেস টাইম

মোট চাওয়ার কত ভাগ cache-এ মিলল, তাকে বলে hit ratio (h). ১০০০ বার চাওয়ায় ৯৫০ বার পাওয়া গেলে h = ৯৫০ ÷ ১০০০ = ০.৯৫ বা ৯৫%; বাকি ০.০৫ হলো miss ratio. এবার গড়ে একবার ডেটা আনতে কত সময় লাগে, তার সহজ সূত্র (average memory access time):

উদাহরণ: h = ৯৫%, cache-এর সময় ১ ns, RAM-এর সময় ১০০ ns.
T = ০.৯৫ × ১ + ০.০৫ × ১০০ = ০.৯৫ + ৫ = ৫.৯৫ ns.
cache না থাকলে প্রতিবার লাগত ১০০ ns — অর্থাৎ cache-এর কারণে গড়ে প্রায় ১৭ গুণ দ্রুত (১০০ ÷ ৫.৯৫ ≈ ১৬.৮)।

এবার মজার অংশ। hit ratio মাত্র ৪ শতাংশ-বিন্দু বাড়িয়ে ৯৯% করলে: T = ০.৯৯ × ১ + ০.০১ × ১০০ = ০.৯৯ + ১ = ১.৯৯ ns — আগের প্রায় তিন ভাগের এক ভাগ! আর ৯৫% থেকে কমে ৯০% হলে T = ০.৯ + ১০ = ১০.৯ ns — প্রায় দ্বিগুণ ধীর। কারণ সময়ের বেশিরভাগটা খায় অল্প কয়েকটি miss. তাই প্রকৌশলীরা hit ratio-র এক-দুই শতাংশের জন্যও কঠোর পরিশ্রম করেন।

৫ · Cache-এর ভেতরে — line, mapping, LRU আর লেখার নিয়ম

Cache বানাতে প্রকৌশলীদের চারটি প্রশ্নের উত্তর দিতে হয়: ডেটা কোন মাপের টুকরোয় আসবে, কোন ঘরে বসবে, ঘর ভরে গেলে কাকে সরানো হবে, আর লেখার সময় কী হবে। খুব সংক্ষেপে চারটিই দেখি।

১. কোন ঘরে বসবে — mapping

RAM-এ কোটি কোটি লাইন, cache-এ মাত্র কয়েকশো বা কয়েক হাজার ঘর। একটি লাইন কোন ঘরে বসবে, তার তিনটি নীতি:

ছোট একটি উদাহরণ: ৮ ঘরের direct-mapped cache-এ লাইন ৩, ১১ আর ১৯ — তিনটিরই ৮ দিয়ে ভাগশেষ ৩, তাই তিনটিই ঘর ৩-এ বসতে চায়। প্রোগ্রাম যদি পালাক্রমে এই তিনটি লাইন ব্যবহার করে, প্রতিবার miss — যদিও বাকি ৭টি ঘর খালি পড়ে আছে! Set-associative নকশা এই সমস্যা অনেকটাই কমায়।

২. ঘর ভরা থাকলে কাকে সরাবে — replacement

নতুন লাইন আনতে পুরোনো একটি সরাতে হয়। সবচেয়ে প্রচলিত ধারণা LRU (Least Recently Used): যেটি সবচেয়ে দীর্ঘ সময় ব্যবহার হয়নি, সেটি সরানো হয় — temporal locality অনুযায়ী সেটির আবার লাগার সম্ভাবনা সবচেয়ে কম। আসল CPU-তে নিখুঁত LRU ব্যয়বহুল, তাই কাছাকাছি সহজ সংস্করণ (pseudo-LRU) ব্যবহার হয়।

৩. লেখার সময় — write-through বনাম write-back

• Write-through: cache-এ লিখলে সাথে সাথে RAM-এও লেখা। সরল, RAM সবসময় হালনাগাদ — কিন্তু প্রতিটি লেখায় ধীর RAM-এর কাছে যেতে হয়।
• Write-back: শুধু cache-এ লিখে লাইনটিকে “বদলানো” (dirty) চিহ্ন দেওয়া; RAM-এ লেখা হয় পরে, লাইনটি cache থেকে সরানোর সময়। একই ভ্যারিয়েবল ১০০০ বার বদলালে RAM-এ যেতে হয় একবার। আধুনিক CPU-র cache সাধারণত write-back.

৪. লুপের ক্রম কেন গতি বদলে দেয়

একটি ৩২ × ৩২ ম্যাট্রিক্স (টেবিল) ভাবুন। C, C++, Python-এর NumPy (সাধারণ সেটিংয়ে) আর বেশিরভাগ ভাষায় ২-মাত্রিক অ্যারে মেমরিতে সারি ধরে (row-major) রাখা হয়: আগে সারি ০-এর ৩২টি সংখ্যা পাশাপাশি, তারপর সারি ১-এর, এভাবে। এখন সব সংখ্যা যোগ করতে দুটি উপায়:

• সারি ধরে পড়া (প্রথমে সারি ০-এর সব কলাম, তারপর সারি ১…): ঠিকানাগুলো পাশাপাশি — spatial locality চমৎকার।
• কলাম ধরে পড়া (প্রথমে কলাম ০-এর সব সারি…): প্রতিবার এক সারি সমান লাফ — ৩২ × ৪ = ১২৮ byte. প্রতিটি পড়া নতুন একটি cache line-এ পড়ে, আর ছোট cache-এ লাইনগুলো আবার দরকার হওয়ার আগেই বেরিয়ে যায়।

কাজ একই, যোগফলও একই — কিন্তু গতিতে বিশাল তফাত। নিচের ছোট সিমুলেটরে নিজেই দেখুন। এটি একটি খুব ছোট cache বানায় — ৮টি লাইন, প্রতিটি ৬৪ byte, LRU নিয়মে — আর তিন ধরনের ঠিকানা-ক্রম চালায়: সারি ধরে, কলাম ধরে, আর এলোমেলো (একটি নির্দিষ্ট সূত্রে তৈরি, তাই প্রতিবার একই ফল)।

function simulate(label, addrs) {        // ৮ লাইনের LRU cache, প্রতি লাইন ৬৪ byte
  const cache = []; let hits = 0;         // লাইন নম্বর; সবচেয়ে নতুনটি শেষে
  for (const a of addrs) {
    const line = Math.floor(a / 64);      // ঠিকানাটি কোন ৬৪-byte লাইনে
    const i = cache.indexOf(line);
    if (i >= 0) { hits++; cache.splice(i, 1); }       // hit
    else if (cache.length === 8) cache.shift();       // miss, cache ভরা: LRU বাদ
    cache.push(line);
  }
  const h = hits / addrs.length, t = h * 1 + (1 - h) * 100;   // hit 1 ns, miss 100 ns
  console.log(`${label}: hit ${hits}, miss ${addrs.length - hits}, hit ratio ${(h * 100).toFixed(1)}%, avg ${t.toFixed(2)} ns`);
}
const N = 32, rowWise = [], colWise = [], rnd = [];   // 32x32 int (৪ byte) ম্যাট্রিক্স
let seed = 7;
for (let r = 0; r < N; r++) for (let c = 0; c < N; c++) {
  rowWise.push((r * N + c) * 4);          // পাশাপাশি ঠিকানা
  colWise.push((c * N + r) * 4);          // প্রতিবার ১২৮ byte লাফ
  seed = (seed * 75 + 74) % 65537; rnd.push((seed % (N * N)) * 4);
}
simulate('row by row   ', rowWise);
simulate('column by col', colWise);
simulate('random       ', rnd);

৬ · Virtual memory — প্রতিটি প্রোগ্রামের নিজের ঠিকানার জগৎ

এবার পিরামিডের নিচের দিকে যাই — RAM আর ডিস্কের সম্পর্কে। আপনার কম্পিউটারে একসাথে চলছে ব্রাউজার, Word, Facebook Messenger, অ্যান্টিভাইরাস, আর অপারেটিং সিস্টেমের নিজের অনেক প্রোগ্রাম। প্রতিটি চলমান প্রোগ্রামকে বলে একটি process (বিস্তারিত পর্ব ২৬-এ)। তিনটি সমস্যা ভাবুন:

1. কে কোথায় থাকবে? প্রতিটি প্রোগ্রাম যদি RAM-এর আসল ঠিকানা নিজে বাছত, দুটি প্রোগ্রাম একই ঠিকানা চাইলে কী হতো?
2. নিরাপত্তা: একটি গেম কি ব্রাউজারের মেমরি থেকে আপনার পাসওয়ার্ড পড়ে ফেলতে পারবে?
3. জায়গা: সব প্রোগ্রাম মিলে RAM-এর চেয়ে বেশি মেমরি চাইলে কী হবে?

তিনটির একটিই সমাধান — virtual memory. প্রতিটি process পায় নিজের আলাদা, বিশাল একটি address space — ঠিকানার একটি কাল্পনিক জগৎ, যেন পুরো মেমরিটা শুধু তার। প্রোগ্রাম যে ঠিকানা ব্যবহার করে, তা virtual address; আসল RAM চিপের ঠিকানা হলো physical address. দুইয়ের মধ্যে অনুবাদ করে CPU-র ভেতরের একটি অংশ — MMU (Memory Management Unit) — প্রতিটি মেমরি-ব্যবহারে, অপারেটিং সিস্টেমের রাখা একটি টেবিল দেখে।

Page, frame আর page table

byte ধরে ধরে হিসাব রাখা অসম্ভব, তাই মেমরিকে সমান মাপের টুকরোয় ভাগ করা হয়। virtual memory-র টুকরোকে বলে page, আসল RAM-এর সমান মাপের ঘরকে frame. সাধারণ PC-তে page-এর মাপ ৪ KB (৪০৯৬ byte); Apple-এর M-সিরিজ চিপে macOS ১৬ KB page ব্যবহার করে, আর বড় ডেটার জন্য ২ MB-র “huge page”-ও আছে। প্রতিটি process-এর জন্য OS একটি page table রাখে, যার প্রতিটি সারিতে থাকে: এই virtual page কোন frame-এ আছে, আদৌ RAM-এ আছে কি না (present bit), আর পড়া-লেখা-চালানোর অনুমতি।

৪ KB = 2¹² byte, তাই একটি ঠিকানার শেষ ১২ bit — হেক্সাডেসিমালে (পর্ব ১৬) শেষ ৩টি অঙ্ক — হলো page-এর ভেতরের অবস্থান (offset); বাকি অংশ page নম্বর। অনুবাদে শুধু page নম্বর বদলায়, offset একই থাকে। নিচের stepper-এ একটি ঠিকানার অনুবাদ, তারপর একটি page fault দেখুন:

Memory protection — এক প্রোগ্রাম অন্যের মেমরি পড়তে পারে না

virtual memory-র সবচেয়ে বড় উপহার হয়তো নিরাপত্তা। প্রতিটি process-এর page table-এ শুধু তার নিজের page-গুলোর সারি থাকে। গেমটি যে ঠিকানাই লিখুক, MMU সেটি গেমের নিজের page table দিয়ে অনুবাদ করে — ব্রাউজারের frame-এ পৌঁছানোর কোনো পথই তার খাতায় নেই। আর page table-এর অনুমতি-bit দিয়ে আরও ঠিক করা যায়: কোডের page শুধু পড়া আর চালানো যাবে, লেখা যাবে না; ডেটার page লেখা যাবে, কিন্তু চালানো যাবে না; kernel-এর page সাধারণ প্রোগ্রাম ছুঁতেই পারবে না।

কোনো প্রোগ্রাম নিষিদ্ধ ঠিকানা ছুঁলে MMU আটকায়, আর OS সেই প্রোগ্রামটি বন্ধ করে দেয় — Windows-এ “access violation”, Linux-এ “segmentation fault” বার্তা এভাবেই আসে। বাকি প্রোগ্রাম আর OS নিরাপদে চলতে থাকে। এই memory protection-এর কারণেই একটি অ্যাপ ক্র্যাশ করলে পুরো কম্পিউটার আর আগের মতো বসে যায় না। তবে সুরক্ষাও নিখুঁত নয় — ২০১৮ সালে প্রকাশিত Meltdown আর Spectre দেখিয়েছিল, cache-এর সময় মেপেও তথ্য ফাঁস হতে পারে; প্রতিকার এসেছে OS, ব্রাউজার আর firmware হালনাগাদে। তাই নিরাপত্তা আপডেট নিয়মিত নিন (পর্ব ৪৩)।

৭ · Page file, swap আর thrashing — কম RAM-এর PC কেন হামাগুড়ি দেয়

RAM ভরে এলে OS কম ব্যবহৃত page ডিস্কে সরিয়ে জায়গা খালি করে — একে বলে paging বা swapping, আর ডিস্কের সেই জায়গাকে বলে page file. Windows-এ এটি C: ড্রাইভের মূলে লুকানো ফাইল pagefile.sys; Linux-এ swap partition বা swap file. এর আগে আধুনিক OS আরেকটি কৌশল চালায় — memory compression: কম ব্যবহৃত page RAM-এর ভেতরেই চেপে ছোট করে রাখে, কারণ চাপা-খোলা ডিস্কে যাওয়ার চেয়ে অনেক দ্রুত।

যতক্ষণ সরানো page-গুলো সত্যিই অব্যবহৃত (যেমন অনেক আগে খোলা একটি ট্যাব), ততক্ষণ কোনো সমস্যা নেই — আপনি টেরও পান না। প্রতিটি প্রোগ্রাম সাম্প্রতিক সময়ে যে page-গুলো সত্যিই ব্যবহার করছে, তাদের দলকে বলে তার working set. সব চলমান প্রোগ্রামের working set মিলে RAM-এ আঁটলে কম্পিউটার স্বচ্ছন্দ। না আঁটলেই বিপদ — নিচে দেখুন:

৮ · নিজের কম্পিউটারে — Task Manager, dual-channel আর unified memory

Task Manager-এ মেমরি পড়তে শিখুন

Windows 10/11-এ Ctrl + Shift + Esc চেপে Task Manager খুলুন, তারপর Performance → Memory. কয়েকটি সংখ্যার মানে:

পাশের Processes ট্যাবে Memory কলামে ক্লিক করলে কোন প্রোগ্রাম কত RAM নিচ্ছে, বড় থেকে ছোট সাজানো দেখবেন। আর Linux-এ টার্মিনালে free -h চালালে total, used, free, buff/cache, available আর Swap-এর সারি দেখায় (টার্মিনাল চালানোর পরিচয় পর্ব ২৯-এ)। মনে রাখুন: RAM অনেকটা ভরা দেখানো খারাপ নয়; চিন্তার বিষয় হলো ধীরগতির সাথে ডিস্কের অবিরাম ব্যস্ততা — thrashing-এর লক্ষণ।

Dual-channel — একই RAM, দ্বিগুণ রাস্তা

বেশিরভাগ ডেস্কটপ আর ল্যাপটপের মাদারবোর্ডে CPU আর RAM-এর মধ্যে দুটি আলাদা মেমরি-পথ (channel) থাকে। দুটি স্টিক সঠিক স্লটে বসালে দুই পথে একসাথে ডেটা চলে — dual-channel, bandwidth প্রায় দ্বিগুণ। latency কমে না, কিন্তু একসাথে বেশি ডেটা আসে। একটি ১৬ GB স্টিকের চেয়ে দুটি ৮ GB স্টিক তাই প্রায়ই দ্রুত — বিশেষ করে যে ল্যাপটপে আলাদা গ্রাফিক্স কার্ড নেই, কারণ সেখানে CPU-র ভেতরের গ্রাফিক্সও এই RAM থেকেই ডেটা খায়। কোন দুটি স্লটে বসাতে হবে, তা মাদারবোর্ডের ম্যানুয়ালে লেখা থাকে।

Unified memory — ফোন আর Apple চিপে

ফোনের SoC-তে CPU, GPU, AI-এর জন্য NPU আর ক্যামেরার প্রসেসর — সবাই একটিই RAM ভাগ করে ব্যবহার করে; আলাদা ভিডিও মেমরি নেই। Apple ২০২০ সালের M1 চিপ থেকে Mac-এও এই নকশা জনপ্রিয় করেছে, নাম দিয়েছে unified memory: RAM চিপগুলো প্রসেসরের একই প্যাকেজে, খুব কাছে বসানো। সুবিধা — CPU আর GPU-কে একই ডেটা এক জায়গা থেকে আরেক জায়গায় কপি করতে হয় না, bandwidth বেশি, বিদ্যুৎ কম। অসুবিধা — RAM পরে আর বাড়ানো যায় না, আর “৮ GB”-এর মধ্যেই গ্রাফিক্সের ভাগও। তাই এমন ডিভাইস কেনার সময় ভবিষ্যতের কথা ভেবে RAM বাছাই আরও গুরুত্বপূর্ণ।

৯ · AI-এর যুগে — latency আর cache-এর সংখ্যা যাচাই করুন

AI চ্যাটবট মেমরি হায়ারার্কির ধারণা খুব গুছিয়ে ব্যাখ্যা করে। কিন্তু সংখ্যার বেলায় সাবধান। AI-এর শেখার ডেটায় পুরোনো লেখা প্রচুর — যেমন ২০০০-এর দশকের “latency numbers”-এর তালিকা, যেখানে ডিস্ক বলতে HDD আর SSD-র সংখ্যা আজকের তুলনায় অনেক ধীর। আবার নির্দিষ্ট কোনো CPU-র L2/L3 cache কত বা কোন ফোনে কত RAM — এমন তথ্য AI প্রায়ই আত্মবিশ্বাসের সাথে ভুল বলে, বা দুটি মডেল গুলিয়ে ফেলে।

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• স্তরের ক্রম ঠিক আছে: register → L1 → L2 → L3 → RAM → SSD → HDD
• প্রতিটি latency “আনুমানিক” হিসেবে বলা, আর অনুপাত বাস্তবসম্মত (L1 থেকে RAM প্রায় ১০০ গুণ, RAM থেকে SSD প্রায় ১০০০ গুণ)
• নির্দিষ্ট CPU/ফোনের cache বা RAM-এর সংখ্যা নির্মাতার অফিসিয়াল পাতায় মিলিয়েছি
• hit ratio-র হিসাব নিজে হাতে একবার করে দেখেছি
• PC-র সমস্যা নিয়ে পরামর্শ হলে Task Manager-এ In use, Committed আর Disk-এর ব্যস্ততা নিজে দেখে মিলিয়েছি; page file বন্ধ বা “RAM cleaner” জাতীয় পরামর্শ মানিনি