মাল্টি-লেভেল ক্যাশ (L1/L2/L3)

১ · কেন একাধিক স্তরের ক্যাশ দরকার

L38-L41-এ আমরা একটি একক ক্যাশ স্তর ধরে নিয়ে কাজ করেছি — CPU হিট বা মিস করে, মিস হলে সরাসরি মূল মেমরিতে যায়। কিন্তু বাস্তব CPU-তে একটি সমস্যা আছে: একটি ক্যাশকে দ্রুত রাখতে হলে সেটাকে ছোট রাখতে হয় (ছোট ক্যাশে ঠিকানা খোঁজা দ্রুত হয়), কিন্তু ছোট ক্যাশে হিট রেট কম থাকে। এই দ্বন্দ্ব সমাধানের বাস্তব উপায় হলো একাধিক স্তর ব্যবহার করা — প্রতিটি স্তর আগের স্তরের চেয়ে বড় কিন্তু কিছুটা ধীর।

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

২ · রিকার্সিভ মাল্টি-লেভেল AMAT সূত্র

L41-এ আমরা একটি একক ক্যাশের AMAT বের করেছিলাম: $AMAT = HitTime + MissRate \times MissPenalty$। মাল্টি-লেভেল ক্যাশে এই একই ধারণা রিকার্সিভভাবে প্রয়োগ হয় — L1-এর "মিস পেনাল্টি" এখন আর সরাসরি মূল মেমরির সময় নয়, বরং L2-এর নিজস্ব AMAT-ই সেই ভূমিকা নেয়:

$$AMAT_{total} = HitTime_{L1} + MissRate_{L1} \times (HitTime_{L2} + MissRate_{L2} \times MissPenalty_{L2\_to\_mem})$$

অর্থাৎ ভেতরের অংশ — $HitTime_{L2} + MissRate_{L2} \times MissPenalty_{L2\_to\_mem}$ — আসলে L2-এর নিজের AMAT-ই, যা L1-এর দৃষ্টিকোণ থেকে শুধু "L1 মিস হলে কত সময় লাগবে" হিসেবে কাজ করছে। তিন স্তর থাকলে এই একই প্যাটার্ন আরও একবার ভেতরে প্রয়োগ হতো (L3-এর AMAT হয়ে যেত L2-এর মিস পেনাল্টি)।

# মাল্টি-লেভেল AMAT -- রিকার্সিভ সূত্র বাস্তবে গণনা করে যাচাই
def multi_level_amat(l1_hit_time, l1_miss_rate, l2_hit_time, l2_miss_rate, mem_penalty):
    """L2-এর নিজস্ব AMAT-ই L1-এর মিস পেনাল্টি হিসেবে কাজ করে -- এখানে সেই রিকার্সিভ সম্পর্ক"""
    l2_effective_cost = l2_hit_time + l2_miss_rate * mem_penalty
    amat_total = l1_hit_time + l1_miss_rate * l2_effective_cost
    return l2_effective_cost, amat_total

def single_level_amat(hit_time, miss_rate, mem_penalty):
    """L2 না থাকলে -- L1 মিস করলেই সরাসরি মূল মেমরিতে"""
    return hit_time + miss_rate * mem_penalty

l1_hit_time, l1_miss_rate = 1, 0.10
l2_hit_time, l2_miss_rate = 10, 0.05
mem_penalty = 100

l2_cost, amat_two_level = multi_level_amat(
    l1_hit_time, l1_miss_rate, l2_hit_time, l2_miss_rate, mem_penalty
)
amat_single = single_level_amat(l1_hit_time, l1_miss_rate, mem_penalty)

print(f"L2-এর কার্যকর খরচ = {l2_hit_time} + {l2_miss_rate} × {mem_penalty} = {l2_cost} সাইকেল")
print(f"দুই-স্তরের AMAT   = {l1_hit_time} + {l1_miss_rate} × {l2_cost}  = {amat_two_level} সাইকেল")
print(f"L2 ছাড়া AMAT     = {l1_hit_time} + {l1_miss_rate} × {mem_penalty} = {amat_single} সাইকেল")
print()
speedup_cycles = amat_single - amat_two_level
speedup_pct = (1 - amat_two_level / amat_single) * 100
print(f"L2 যোগ করায় AMAT কমেছে {speedup_cycles} সাইকেল ({speedup_pct:.1f}% দ্রুত)")

৩ · L3 শেয়ারিং ও ভবিষ্যৎ প্রভাব

মাল্টিকোর CPU-তে (M11) প্রতিটি কোরের সাধারণত নিজস্ব প্রাইভেট L1 ও L2 থাকে, কিন্তু L3 সব কোরের মধ্যে শেয়ার্ড — এর একটি বাস্তব সুবিধা আছে: একটি কোর যদি কোনো ডেটা ইতিমধ্যে L3-এ এনে ফেলে, অন্য কোর সেটা আবার মূল মেমরি থেকে না এনেই ব্যবহার করতে পারে। কিন্তু এই একই শেয়ারিং একটি গুরুতর সমস্যারও জন্ম দেয় — যদি একাধিক কোরের প্রাইভেট L1/L2-এ একই ঠিকানার আলাদা কপি থাকে, আর একটি কোর সেটা পরিবর্তন করে, অন্য কোরগুলো কীভাবে জানবে তাদের কপি পুরনো হয়ে গেছে? এটিই L52-এর ক্যাশ কোহেরেন্স সমস্যা — এই পাঠের বিষয় নয়, তবে এর মূল কারণ এখানেই তৈরি হয়।