Hardware multithreading — fine-grained, coarse-grained আর SMT

১ · খালি issue slot — vertical আর horizontal waste

পর্ব ৩৯-এ দেখেছেন, একটি superscalar core প্রতি cycle-এ একাধিক instruction শুরু (issue) করতে পারে। ধরুন core-টি ৪-wide — প্রতি cycle-এ ৪টি issue slot. আদর্শ অবস্থায় IPC = ৪। পর্ব ৪০-এর out-of-order execution আর register renaming সেই লক্ষ্যের দিকে আরও এগোয়: প্রোগ্রামের ক্রমের বাইরে গিয়েও প্রস্তুত instruction খুঁজে আনে। তবু বাস্তবে সাধারণ প্রোগ্রামে গড় IPC প্রায়ই ৪-এর অনেক নিচে থাকে। কেন?

দুটি আলাদা কারণ। প্রথমটি মেমরি. একটি load যদি cache-এ না পায় (cache miss), ডেটা আনতে main memory পর্যন্ত যেতে হয় — আধুনিক chip-এ সেটা কয়েকশো cycle (পর্ব ৪৪-এ মেমরি হায়ারার্কির পুরো ছবি)। ওই load-এর ফলের ওপর নির্ভরশীল সব instruction ততক্ষণ বসে থাকে। Out-of-order core কিছু স্বাধীন কাজ এগিয়ে রাখে, কিন্তু তার জানালা (reorder buffer) একসময় ভরে যায়, আর তখন পুরো core থেমে থাকে। একে বলে memory wall-এর সমস্যা। দ্বিতীয় কারণ নির্ভরতা: এক cycle-এ চারটি slot ভরাতে চারটি পরস্পর-স্বাধীন instruction চাই, কিন্তু অনেক কোডে একসাথে দুটি-তিনটির বেশি পাওয়া যায় না।

১৯৯৫ সালে University of Washington-এর Dean Tullsen, Susan Eggers আর Henry Levy একটি বিখ্যাত গবেষণাপত্রে এই খালি জায়গাকে দুই ভাগে ভাগ করেছিলেন। একটি ছকে কলাম হলো issue slot, সারি হলো cycle; প্রতিটি ঘরে হয় একটি instruction, নয়তো খালি। এই ছকের নাম issue-slot diagram:

• Vertical waste — যে cycle-এ একটিও instruction issue হয়নি; ছকে পুরো সারি খালি। সাধারণত লম্বা stall-এর ফল: cache miss, TLB miss, branch-এর ভুল অনুমানের পরে pipeline ভরা।
• Horizontal waste — যে cycle-এ কিছু instruction issue হয়েছে, কিন্তু সব slot ভরেনি; সারির একাংশ খালি। সাধারণত একটি thread-এর ভেতরে যথেষ্ট স্বাধীন instruction না থাকার ফল — অর্থাৎ ILP-র সীমা।

একটি ছোট হিসাব: ৪-wide core-এ একটি thread ৫০ cycle চলে (গড়ে প্রতি cycle-এ ২টি instruction), তারপর miss-এ ২০০ cycle থামে। প্রতি ২৫০ cycle-এ ১০০টি instruction: IPC = ০.৪, utilisation = ১০০ ÷ (৪ × ২৫০) = ১০% — ১০টি slot-এর ৯টিই খালি। চওড়া core বানালে মেমরির ২০০ cycle একটুও কমবে না।

ILP বনাম TLP — কাজ আনার দুটি উৎস

খালি slot ভরাতে স্বাধীন instruction চাই। সেগুলো আসতে পারে দুই জায়গা থেকে। Instruction-level parallelism (ILP) — একই instruction-ধারার ভেতরের স্বাধীন instruction, যা superscalar আর out-of-order hardware খুঁজে বের করে (পর্ব ৩৯–৪০)। Thread-level parallelism (TLP) — আলাদা instruction-ধারা, অর্থাৎ আলাদা thread বা প্রসেস, যাদের মধ্যে register-এর কোনো নির্ভরতা নেই। একটি ওয়েব সার্ভারে একসাথে শত শত অনুরোধ, একটি ফোনে একসাথে চলা অ্যাপ আর সার্ভিস, একটি compile-এর সময় আলাদা ফাইল — সবই TLP-র উৎস।

ILP খোঁজা ক্রমেই দামি হয়েছে; TLP-র নির্ভরতা-যাচাই প্রায় বিনামূল্যে, কারণ দুই thread-এর register আলাদা। তবে TLP পেতে software-কেই কাজকে thread-এ ভাগ করে দিতে হয়। Hardware multithreading হলো একটি core-এর ভেতরে TLP ব্যবহার করে ILP-র ঘাটতি পূরণ। একাধিক core দিয়ে TLP ব্যবহার — multicore — আসবে পর্ব ৫৩-এ।

২ · Hardware thread — কী আলাদা, কী ভাগ করা

OS-এর thread একটি software ধারণা: একটি নির্বাহ-ধারা, যার নিজের register-মান, PC আর stack আছে। একটি সাধারণ core একসাথে একটিমাত্র thread চালায়; অন্যটিতে যেতে OS-কে context switch করতে হয় — register মেমরিতে সেভ, অন্যটির register ফেরত, যা হাজার হাজার cycle-এর কাজ (Operating Systems কোর্সের Context switch পর্বে বিস্তারিত)। আর পর্ব ৩৮-এ দেখেছেন, এর শুরু একটি timer interrupt আর trap দিয়ে।

একটি hardware thread (বা hardware context) হলো core-এর ভেতরে একটি thread-এর architectural state রাখার একটি স্থায়ী ঘর। Core-এ যদি দুটি ঘর থাকে, তাহলে দুটি software thread একসাথে core-এ “বসে” থাকতে পারে, আর তাদের মধ্যে বদল করতে মেমরিতে কিছুই সেভ করতে হয় না — শুধু কোন ঘরের instruction আনা হবে, সেটি বদলালেই হলো। এই বদল OS জানেই না; এটি hardware-এর, cycle-এর হিসাবে।

লক্ষ করুন, আলাদা রাখা অংশগুলো ছোট — কয়েক ডজন register আর কিছু CSR. দামি অংশগুলো (execution unit, cache, predictor) ভাগ করা। এজন্য একটি দ্বিতীয় hardware thread যোগ করার খরচ একটি দ্বিতীয় পূর্ণ core-এর চেয়ে অনেক কম। ঠিক কতটা, তা chip-ভেদে ভিন্ন আর নির্মাতারা সবসময় প্রকাশ করেন না — তাই কোনো নির্দিষ্ট শতাংশ মনে রাখার দরকার নেই। মূল কথা: multithreading মানে একটি core-কে দুটি core বানানো নয়; এক core-এর খালি সময় আর খালি slot অন্য thread-কে দেওয়া।

এবার প্রশ্ন: কখন কোন thread-এর instruction issue হবে? তিনটি প্রধান নীতি আছে, যাদের পার্থক্য এক কথায়: thread বদল কত ঘন ঘন আর কত সূক্ষ্মভাবে।

৩ · Coarse-grained multithreading — লম্বা stall-এ thread বদল

Coarse-grained multithreading-এ (একে switch-on-event multithreading-ও বলা হয়) core একটি thread-ই চালাতে থাকে, যতক্ষণ না একটি লম্বা stall আসে — সাধারণত last-level cache-এর miss. তখন core অন্য একটি প্রস্তুত hardware thread-এ চলে যায়। ছোট stall-এ (যেমন একটি load-use hazard, পর্ব ৩৬) বদল হয় না, কারণ বদলেরও দাম আছে।

দামটা কী? পর্ব ৩৫-এর pipeline মনে করুন। বদলের মুহূর্তে pipeline-এ পুরোনো thread-এর পরের instruction-গুলো ভরা — সেগুলো flush করতে হয়, আর নতুন thread-এর প্রথম instruction fetch থেকে issue পর্যন্ত পৌঁছাতে কয়েক cycle লাগে। এই refill-এর সময় কোনো instruction issue হয় না: পুরো সারি খালি, অর্থাৎ vertical waste. ধরুন এই switch penalty = S cycle. In-order pipeline-এ S মোটামুটি fetch থেকে issue পর্যন্ত ধাপের সংখ্যা; গভীর pipeline-এ বেশি।

নিচের stepper-এ ৪-wide একটি core, দুটি hardware thread A আর B. প্রতিটি thread-এর instruction কয়েকটি দলে (group) সাজানো: একটি দলের instruction পরস্পর-স্বাধীন, একসাথে issue হতে পারে; পরের দল আগেরটির ওপর নির্ভরশীল, তাই পরের cycle-এর আগে নয়। A-র দল: ৩, ২, ১ (এই load-টি miss করে), ৪. B-র দল: ২, ৩, ১ (miss), ২. Miss-এর latency ৫ cycle — load যে cycle-এ issue হয়, তার ৫ cycle পরে নির্ভরশীল দলটি চলতে পারে। Switch penalty S = ২ cycle. ছকে কলাম = cycle, সারি = slot; . = খালি slot, ~ = বদলের সময় নষ্ট slot.

কতগুলো thread লাগবে, আর বদল কখন লাভজনক — সূত্র আর প্রমাণ

একটি সরল মডেল নিন, যা বিশ্ববিদ্যালয়ের পরীক্ষায় আর ইন্টারভিউতে প্রায়ই চাওয়া হয়। N-টি একই রকম thread; প্রতিটি R cycle পূর্ণ গতিতে চলে, তারপর একটি miss-এ L cycle অপেক্ষা; প্রতিটি বদলে S cycle নষ্ট। এখানে “utilisation” মানে যত cycle-এ core কাজের instruction চালাচ্ছে তার ভগ্নাংশ (cycle-এর ভেতরের horizontal waste আলাদা হিসাব)।

যুক্তি। Steady state-এ thread-গুলো পালা করে চলে: A চলে R, বদল S, B চলে R, বদল S, … তারপর আবার A. A-র miss শুরু হয় তার R শেষে, আর পরের বার A চলা শুরু করতে পারে তখনই, যখন (১) অন্য N − ১টি thread-এর পালা শেষ, এবং (২) A-র ডেটা এসে গেছে, আর তারপর বদলের S. প্রথম শর্তে A-র দুটি শুরুর মাঝে সময় N·(R + S); দ্বিতীয় শর্তে অন্তত R + L + S (চলা R, অপেক্ষা L, তারপর বদল S). তাই একটি পূর্ণ চক্রের দৈর্ঘ্য P = max(N·(R + S), R + L + S), আর প্রতি চক্রে N·R cycle কাজ — এখান থেকে U_N. প্রথম রাশিটি বড় হলে অপেক্ষা পুরো ঢাকা: N·(R + S) ≥ R + L + S ⇔ (N − ১)(R + S) ≥ L ⇔ N ≥ ১ + L ÷ (R + S), আর পূর্ণসংখ্যায় N* = ১ + ⌈L ÷ (R + S)⌉. তখন U = R ÷ (R + S) — আর বাড়ানো যায় না, কারণ প্রতিটি R-এর পরে S দিতেই হবে।

শেষ দাবিটি: N ≥ ২ হলে U_N > U_১ হবে যদি দুটি অসমতাই খাটে — N·R ÷ N(R + S) > R ÷ (R + L), অর্থাৎ L > S; আর N·R ÷ (R + L + S) > R ÷ (R + L), অর্থাৎ (N − ১)(R + L) > S. S < L হলে দ্বিতীয়টি আপনা থেকেই খাটে, কারণ R + L > L > S. তাই শর্ত একটিই: বদলের দাম miss-এর latency-র চেয়ে কম হতে হবে। এজন্যই coarse-grained শুধু লম্বা miss-এ বদলায়, L1 miss বা ছোট hazard-এ নয়। এই সূত্রগুলো একটি cycle-ধরে-চলা simulator দিয়ে মিলিয়ে দেখা হয়েছে (চারটি ভিন্ন R, L, S-এর জন্য ১ থেকে ৫টি thread).

এবার নিচের calculator চালিয়ে দেখুন। তিনটি পরিস্থিতি: DRAM miss আর ছোট refill; একই miss কিন্তু গভীর pipeline-এ বড় refill; আর একটি L2 hit, যার latency বদলের দামের চেয়ে কম।

// Coarse-grained multithreading: does switching on a miss pay off?
// R = cycles a thread runs between misses, L = miss latency, S = switch cost (refill), N = threads
function util(N, R, L, S) {
  if (N === 1) return R / (R + L);                   // one thread: run R, wait L, repeat (no switch)
  return N * R / Math.max(N * (R + S), R + L + S);   // a round of N runs + N switches, or wait for the miss
}
const cases = [
  { name: "DRAM miss, short refill", R: 50, L: 200, S: 10 },
  { name: "deep pipeline refill",    R: 50, L: 200, S: 30 },
  { name: "L2 hit, costly switch",   R: 50, L: 8,   S: 10 }];
for (const c of cases) {
  const need = 1 + Math.ceil(c.L / (c.R + c.S));     // smallest N with (N-1)(R+S) >= L
  const best = c.R / (c.R + c.S), alone = util(1, c.R, c.L, c.S);
  console.log(`${c.name}: R=${c.R} L=${c.L} S=${c.S}`);
  console.log("   N    " + [1, 2, 3, 4, 5, 6].map(n => String(n).padStart(7)).join(""));
  console.log("   util " + [1, 2, 3, 4, 5, 6].map(n => ((100 * util(n, c.R, c.L, c.S)).toFixed(1) + "%").padStart(7)).join(""));
  console.log(`   threads to hide the miss = ${need}, ceiling R/(R+S) = ${(100 * best).toFixed(1)}%` +
    (best < alone ? `  -> worse than one thread (${(100 * alone).toFixed(1)}%): S > L, do not switch` : ""));
}

DRAM miss, short refill: R=50 L=200 S=10
   N          1      2      3      4      5      6
   util   20.0%  38.5%  57.7%  76.9%  83.3%  83.3%
   threads to hide the miss = 5, ceiling R/(R+S) = 83.3%
deep pipeline refill: R=50 L=200 S=30
   N          1      2      3      4      5      6
   util   20.0%  35.7%  53.6%  62.5%  62.5%  62.5%
   threads to hide the miss = 4, ceiling R/(R+S) = 62.5%
L2 hit, costly switch: R=50 L=8 S=10
   N          1      2      3      4      5      6
   util   86.2%  83.3%  83.3%  83.3%  83.3%  83.3%
   threads to hide the miss = 2, ceiling R/(R+S) = 83.3%  -> worse than one thread (86.2%): S > L, do not switch

Coarse-grained-এর সুবিধা: একক thread-এর গতি প্রায় অক্ষুণ্ণ, hardware সরল। সীমাবদ্ধতা: বদলের দাম, আর horizontal waste একটুও কমে না। বাস্তবে IBM-এর কিছু server processor (১৯৯০-এর দশকের শেষে AS/400 আর RS/6000-এর জন্য বানানো “Northstar”/RS64 পরিবার) আর Intel Itanium-এর একটি প্রজন্ম (Montecito, ২০০৬ সালের দিকে) এই ধরনের switch-on-event multithreading ব্যবহার করেছিল বলে জানা যায়।

৪ · Fine-grained multithreading — প্রতি cycle-এ অন্য thread

Fine-grained multithreading-এ (interleaved multithreading) core প্রতি cycle-এ পালা করে অন্য thread-এর instruction issue করে — round-robin. যে thread এখন miss-এর অপেক্ষায়, সাধারণত তাকে বাদ দিয়ে পরের প্রস্তুত thread-কে পালা দেওয়া হয়। বদলের কোনো দাম নেই, কারণ pipeline-এ সব সময়ই কয়েকটি thread-এর instruction মিশে থাকে; প্রতিটি instruction-এর সাথে একটি ছোট thread-নম্বর চলে, যা বলে কোন register set পড়তে বা লিখতে হবে।

এই উপমাতেই fine-grained-এর মূল trade-off: vertical waste প্রায় শূন্য (অন্তত একটি thread প্রস্তুত থাকলেই cycle কাজে লাগে), কিন্তু একক thread-এর গতি কমে — N-টি প্রস্তুত thread থাকলে প্রতিটি পায় প্রতি N cycle-এ একবার। আর একটি cycle-এ মাত্র একটি thread issue করে, তাই horizontal waste থেকেই যায়। নিচের stepper-এ তিনটি thread A, B, C; ৪-wide core; miss latency ৪. A-র দল: ২, ১ (miss), ৩. B-র দল: ১, ২, ১ (miss). C-র দল: ৩, ১, ২.

Barrel processor — চরম fine-grained

Fine-grained-এর সবচেয়ে কঠোর রূপ barrel processor: N-টি thread কঠোরভাবে পালা করে, কোনো thread বাদ যায় না (অপেক্ষমাণ হলে তার পালা খালি যায়)। এর একটি চমৎকার সুবিধা আছে। যদি N ≥ pipeline-এর ধাপের সংখ্যা হয়, তাহলে একই thread-এর পরপর দুটি instruction pipeline-এ কখনো একসাথে থাকে না — আগেরটি শেষ হলে তবে পরেরটি ঢোকে। তখন data hazard নেই, forwarding লাগে না, branch-এর অনুমানও লাগে না (পর্ব ৩৬–৩৭-এর পুরো জটিলতা উধাও)। Pipeline খুব সরল হয়; দাম একক thread-এর গতি — প্রতিটি thread চলে clock-এর ১/N গতিতে।

ইতিহাসে এর কয়েকটি বিখ্যাত উদাহরণ: ১৯৬৪ সালের CDC 6600-এর দশটি “peripheral processor” আসলে একটি ভাগ করা hardware, যা পালা করে দশটি processor-এর অবস্থা ঘুরিয়ে চালাত — ছবিতে একে ঘুরন্ত একটি “barrel” হিসেবে দেখানো হতো, নামটা সেখান থেকেই বলে প্রচলিত। ১৯৮০-এর দশকে Burton Smith-এর Denelcor HEP আর পরে Tera MTA (১৯৯০-এর দশক) প্রতি processor-এ বহু hardware thread রেখে মেমরির latency লুকাত — Tera MTA প্রতি processor-এ ১২৮টি thread রাখত বলে উল্লেখ পাওয়া যায়, আর data cache প্রায় ছিলই না। ২০০৫ সালের দিকে Sun-এর UltraSPARC T1 (“Niagara”) ৮টি সরল in-order core-এর প্রতিটিতে ৪টি thread রেখে fine-grained পদ্ধতিতে চালাত — ওয়েব সার্ভারের মতো কাজে throughput-এর জন্য। এসব নকশার সংখ্যা সূত্রভেদে কিছুটা আলাদা বর্ণিত হয়।

৫ · Simultaneous multithreading (SMT) — একই cycle-এ কয়েকটি thread

Fine-grained vertical waste মোছে, কিন্তু horizontal waste রাখে; superscalar horizontal waste-এর বিরুদ্ধে লড়ে, কিন্তু vertical waste-এ অসহায়। Tullsen আর সহকর্মীদের প্রশ্ন ছিল: দুটো একসাথে কেন নয়? Simultaneous multithreading (SMT)-এ একটি out-of-order superscalar core একই cycle-এ একাধিক thread-এর instruction issue করে। যে slot একটি thread ভরাতে পারছে না, অন্য thread-এর প্রস্তুত instruction তা নেয়।

Out-of-order core-এ এর জন্য খুব বেশি নতুন যন্ত্র লাগে না। পর্ব ৪০-এ দেখেছেন, register renaming প্রতিটি architectural register-কে একটি physical register-এ বসায়, আর issue queue শুধু দেখে কোন instruction-এর operand তৈরি — “কোন thread-এর” প্রশ্নই নেই। তাই SMT-তে মূলত লাগে: প্রতি thread-এ আলাদা PC, আলাদা rename map, আলাদা retire (পর্ব ৩৮-এর precise exception প্রতি thread-এ আলাদা), আর ভাগাভাগির নিয়ম।

নিচের stepper-এ আবার coarse-grained-এর একই দুটি thread A আর B (A: ৩, ২, ১ miss, ৪; B: ২, ৩, ১ miss, ২; miss latency ৫)। প্রতি cycle-এ অগ্রাধিকার পালা করে: জোড় cycle-এ আগে A, বিজোড়-এ আগে B; আগের জন যতটা পারে নেয়, বাকি slot পরের জন। একটি thread এক cycle-এ শুধু তার এখনকার দলটিই issue করতে পারে।

বাস্তবের SMT

Tullsen-দের গবেষণার পর DEC তাদের পরের প্রজন্মের Alpha 21464-এ চারটি thread-এর SMT-র পরিকল্পনা করেছিল, কিন্তু কোম্পানি বিক্রি হওয়ার পর প্রকল্পটি বাতিল হয় (২০০১ সালের দিকে)। প্রথম বাণিজ্যিক SMT আসে Intel-এর কাছ থেকে: Hyper-Threading নামে ২০০২ সালের দিকে Xeon server chip-এ, তারপর একই বছরের শেষে Pentium 4-এ — প্রতি core-এ দুটি hardware thread. IBM ২০০৪ সালের দিকে POWER5-এ দুটি thread-এর SMT আনে; পরে POWER7-এ চারটি (SMT4) আর POWER8 থেকে আটটি (SMT8) পর্যন্ত, আর OS চালু অবস্থাতেই SMT-এর মাত্রা বদলানো যায় বলে জানা যায়। AMD ২০১৭ সালের Zen থেকে দুটি thread-এর SMT দেয়। অন্যদিকে Apple-এর M-series আর অনেক ফোনের ARM core-এ SMT নেই, আর ২০২৪ সালের কিছু Intel ল্যাপটপ chip-এর বড় core থেকেও Hyper-Threading বাদ দেওয়া হয়েছে বলে খবর — কেন, তা ভাবনার প্রশ্ন ৫-এ।

ভাগাভাগি — partition না প্রতিযোগিতা?

SMT-র সবচেয়ে সূক্ষ্ম নকশা-প্রশ্ন হলো ভেতরের সারিগুলো (reorder buffer, issue queue, load/store queue, physical register) কীভাবে ভাগ হবে। দুটি চরম পথ:

Tullsen-দের ১৯৯৬ সালের পরের একটি গবেষণা দেখায়, fetch-এর অগ্রাধিকারই সবচেয়ে কার্যকর লিভার: যে thread-এর কম instruction এখন pipeline-এ আটকে আছে, তাকে আগে fetch করতে দেওয়া (নাম ICOUNT). আজকের chip-গুলোর ঠিক নীতি সাধারণত প্রকাশিত নয়।

৬ · চার নীতি পাশাপাশি — simulator আর throughput বনাম latency

এবার Tullsen-দের বিখ্যাত ছবিটি — চারটি নীতি পাশাপাশি। নিচের ছবি অংশের simulator-এর প্রথম ১০ cycle থেকে আঁকা: তিনটি thread A, B, C, ৪-wide core, miss latency ৬, coarse-grained-এ বদলের দাম ২ cycle. ওপর থেকে নিচে cycle, বাঁ থেকে ডানে ৪টি slot.

নিচের simulator নিজে চালিয়ে দেখুন। প্রতিটি thread-এর instruction-ধারা কয়েকটি দলে লেখা ("3 2 1m 4 2" মানে প্রথমে ৩টি স্বাধীন, তারপর ২টি, তারপর ১টি load যা miss করে, …), আর ধারা শেষ হলে আবার শুরু থেকে ঘোরে। আউটপুটে utilisation, প্রতিটি thread-এর IPC, মোট IPC, খালি cycle (vertical waste) আর ভরা cycle-এর ভেতরের খালি slot (horizontal waste) — সাথে প্রথম ২৪ cycle-এর slot-ছক (কলাম = cycle). Miss latency এখানে ইচ্ছা করে ছোট (৬), যাতে ছকে দেখা যায়; বাস্তবে DRAM miss কয়েকশো cycle.

// Issue-slot simulator: 3 threads on a 4-wide core under 4 policies (single, coarse, fine, SMT)
const W = 4, MISS = 6, SW = 2, CYC = 48, SHOW = 24;  // width, miss latency, coarse switch cost, cycles run / drawn
const prog = { A: "3 2 1m 4 2", B: "1 1m 3 2 1", C: "2 4 1 1 1m" };  // groups of independent instrs; m = cache miss
function run(policy) {
  const T = Object.entries(prog).map(([id, s]) => ({ id, g: s.split(" "), pc: 0, left: parseInt(s), readyAt: 0, done: 0 }));
  const rows = []; let cur = 0, swUntil = 0, rr = 0;
  const issue = (t, c, room) => {                    // issue up to `room` instrs of t's current group
    const k = Math.min(room, t.left); t.left -= k; t.done += k; t.readyAt = c + 1;
    if (t.left === 0) {                              // group finished; next group depends on it
      if (t.g[t.pc].endsWith("m")) t.readyAt = c + MISS;
      t.pc = (t.pc + 1) % t.g.length; t.left = parseInt(t.g[t.pc]);
    }
    return t.id.repeat(k);
  };
  for (let c = 0; c < CYC; c++) {
    let s = "";
    if (policy === "single") { if (T[0].readyAt <= c) s = issue(T[0], c, W); }
    else if (policy === "coarse") {
      if (c < swUntil) s = "~".repeat(W);            // pipeline refill after a switch: dead cycle
      else if (T[cur].readyAt <= c) s = issue(T[cur], c, W);
      else { const nx = [1, 2].map(k => T[(cur + k) % T.length]).find(t => t.readyAt <= c);   // next ready thread, in turn
        if (nx) { cur = T.indexOf(nx); swUntil = c + SW; s = "~".repeat(W); } }
    } else if (policy === "fine") {                  // one thread per cycle, round-robin, skip stalled ones
      for (let k = 0; k < T.length && !s; k++) { const t = T[(rr + k) % T.length]; if (t.readyAt <= c) { s = issue(t, c, W); rr = T.indexOf(t) + 1; } }
    } else {                                         // SMT: fill the slots from every ready thread
      for (let k = 0; k < T.length; k++) { const t = T[(rr + k) % T.length]; if (t.readyAt <= c && s.length < W) s += issue(t, c, W - s.length); }
      rr = (rr + 1) % T.length;
    }
    rows.push(s.padEnd(W, "."));
  }
  const used = T.reduce((a, t) => a + t.done, 0), busy = rows.filter(r => /[A-C]/.test(r));
  console.log(`${policy.padEnd(6)} util ${(100 * used / (W * CYC)).toFixed(1).padStart(5)}%  IPC ${T.map(t => t.id + "=" + (t.done / CYC).toFixed(2)).join(" ")}  total=${(used / CYC).toFixed(2)}  empty cycles=${CYC - busy.length}  empty slots in busy cycles=${busy.join("").split(".").length - 1}`);
  for (let i = 0; i < W; i++) console.log(`   slot${i} ` + rows.slice(0, SHOW).map(r => r[i]).join(""));
}
["single", "coarse", "fine", "smt"].forEach(run);

single util  28.1%  IPC A=1.13 B=0.00 C=0.00  total=1.13  empty cycles=25  empty slots in busy cycles=38
   slot0 AAA.....AAAAA.....AAAAA.
   slot1 AA......AAAA......AAAA..
   slot2 A.......A.A.......A.A...
   slot3 ........A.........A.....
coarse util  33.9%  IPC A=0.63 B=0.35 C=0.38  total=1.35  empty cycles=14  empty slots in busy cycles=71
   slot0 AAA~~BB~~CCCCC~~AAAAA~~B
   slot1 AA.~~..~~CC...~~AAAA.~~B
   slot2 A..~~..~~.C...~~A.A..~~B
   slot3 ...~~..~~.C...~~A....~~.
fine   util  47.4%  IPC A=0.75 B=0.54 C=0.60  total=1.90  empty cycles=0  empty slots in busy cycles=101
   slot0 ABCABCACCCBBABABCABCACAC
   slot1 A.CA.C....BBA.A.CA.CA...
   slot2 A....C....B.A....A.C....
   slot3 .....C......A......C....
smt    util  67.2%  IPC A=1.06 B=0.71 C=0.92  total=2.69  empty cycles=1  empty slots in busy cycles=59
   slot0 ABCACC.BBBBCACCACBBBBBCC
   slot1 ACCCA..BB.ACACAAABB...CC
   slot2 ACC....B..AACA.C.B....AC
   slot3 BAC.......ABCA........AC

Throughput বনাম single-thread latency

এখান থেকে multithreading-এর মূল trade-off পরিষ্কার। পর্ব ০৩-এর ভাষায়: throughput (প্রতি সেকেন্ডে মোট কতটা কাজ) বাড়ে, কিন্তু একটি নির্দিষ্ট কাজের latency (শুরু থেকে শেষ) কমে না — বরং সাধারণত বাড়ে। একটি ওয়েব সার্ভার, যেখানে প্রতি সেকেন্ডে কতগুলো অনুরোধ সামলানো যায় সেটাই মাপকাঠি, এতে লাভবান। কিন্তু একটি খেলা বা একটি real-time নিয়ন্ত্রক, যেখানে একটি নির্দিষ্ট thread-এর দেরিই সমস্যা, সেখানে sibling thread-এর উপস্থিতি ক্ষতিকর হতে পারে। নিচের টেবিলে সারাংশ:

SMT কখন সাহায্য করে, কখন ক্ষতি

SMT-র লাভ নিয়ে সবচেয়ে সৎ উত্তর: কাজের ধরনভেদে খুব আলাদা — বেশ বড় থেকে প্রায় শূন্য, এমনকি ঋণাত্মক। কোনো একটি শতাংশকে “SMT-র লাভ” হিসেবে মনে রাখবেন না। বরং চিনে রাখুন কোন বৈশিষ্ট্যে লাভ হয়:

এজন্য কিছু high-performance computing ক্লাস্টার SMT বন্ধ রাখে বা প্রতি core-এ একটি কাজই চালায়, আবার ডেটাবেস আর ওয়েব সার্ভার সাধারণত চালু রাখে। সবচেয়ে ভালো উপায়: নিজের কাজ SMT চালু ও বন্ধ দুই অবস্থায় মেপে দেখা।

৭ · OS-এর চোখে hardware thread — logical CPU, sibling আর vCPU

OS-এর কাছে প্রতিটি hardware thread একটি পূর্ণ CPU-র মতো দেখায় — একে বলে logical CPU. ৮টি core, প্রতি core-এ ২টি thread — এমন chip-এ Linux-এর nproc বলবে ১৬, Windows-এর Task Manager দেখাবে “Logical processors: 16”. একই core-এর hardware thread-গুলোকে বলে sibling thread. Linux প্রতিটি logical CPU-র জন্য /sys/devices/system/cpu/cpuN/topology/thread_siblings_list ফাইলে লিখে রাখে কারা তার sibling (যেমন 0,8 বা 0-1 — নম্বর দেওয়ার রীতি chip আর firmware-ভেদে আলাদা)।

Scheduler-এর জন্য এই তথ্য জরুরি। দুটি ব্যস্ত task আর দুটি খালি physical core থাকলে, task দুটিকে একই core-এর দুই sibling-এ বসানো বোকামি — তারা slot আর cache নিয়ে লড়বে, অথচ পাশের core অলস। তাই SMT-সচেতন scheduler আগে আলাদা core-এ ছড়ায়, সব core ব্যস্ত হলে তবেই sibling ভরায়। আবার একই core-এর sibling-এর মধ্যে task সরানো প্রায় বিনামূল্যে, কারণ cache একই। Linux এজন্য scheduling domain-এর স্তর সাজায় — sibling, core, socket, NUMA node. OS-এর দিক থেকে পুরো আলোচনা আছে Operating Systems কোর্সের Multiprocessor scheduling পর্বে (multicore আর SMT অংশ), আর software thread-এর মূল ধারণা থ্রেড পর্বে।

Cloud-এ একটি “vCPU” কেনার অর্থও এখান থেকে বোঝা যায়। বড় cloud সেবাগুলোর অনেক x86 instance-এ একটি vCPU সাধারণত একটি hardware thread — অর্থাৎ ২টি vCPU প্রায়ই একটি physical core-এর দুই sibling. তাই “৪ vCPU” মানে প্রায়ই ২টি পূর্ণ core-এর সমান কাজের ক্ষমতা নয়। সেবাভেদে আর instance-ভেদে নিয়ম আলাদা, তাই নির্দিষ্ট সেবার ডকুমেন্টেশন দেখে নেবেন।

যে runner-এ এই পর্বের কোড চলে, সেটি কী দেখায়? নিচের script শুধু logical CPU-র সংখ্যা আর sibling-এর তালিকা ছাপে — কোনো CPU-র নাম, নির্মাতা, flag বা যন্ত্রের পরিচয় নয় (ফাইল থেকে সংখ্যা, কমা আর ড্যাশ ছাড়া সব বাদ দেওয়া হয়):

# Logical CPUs and SMT sibling lists ONLY -- no model name, vendor, flags or host info
echo "nproc (CPUs this process may use): $(nproc 2>/dev/null || echo '?')"
echo "getconf _NPROCESSORS_ONLN (online logical CPUs): $(getconf _NPROCESSORS_ONLN 2>/dev/null || echo '?')"
lists=""; found=0
for f in /sys/devices/system/cpu/cpu[0-9]*/topology/thread_siblings_list; do
    [ -r "$f" ] || continue
    c=${f#/sys/devices/system/cpu/}; c=${c%%/*}       # e.g. cpu0
    s=$(tr -cd '0-9,-' < "$f")                        # keep only digits, commas, dashes
    echo "$c thread_siblings_list: $s"
    lists="$lists $s"; found=$((found + 1))
done
if [ "$found" -eq 0 ]; then
    echo "thread_siblings_list পড়া যায় না (এই container-এ বন্ধ)"; exit 0
fi
count() {   # how many CPUs in a list like 0-1 or 0,4 or 3
    local n=0 part a b
    for part in ${1//,/ }; do
        if [[ $part == *-* ]]; then a=${part%-*}; b=${part#*-}; n=$((n + b - a + 1)); else n=$((n + 1)); fi
    done
    echo "$n"
}
uniq_lists=$(echo $lists | tr ' ' '\n' | sort -u)
cores=$(echo "$uniq_lists" | wc -l)
per=$(count "$(echo "$uniq_lists" | head -1)")
echo "distinct sibling groups (cores as seen): $cores, hardware threads per group: $per"

nproc (CPUs this process may use): 2
getconf _NPROCESSORS_ONLN (online logical CPUs): 2
cpu0 thread_siblings_list: 0-1
cpu1 thread_siblings_list: 0-1
distinct sibling groups (cores as seen): 1, hardware threads per group: 2

এবার দুটি thread একসাথে চালিয়ে দেখা যাক। নিচের C প্রোগ্রাম একই কাজ দুবার করে: প্রথমে একটি thread দুটি কাজ পরপর, তারপর দুটি POSIX thread একসাথে একটি করে। কাজটি একটি নির্ভরশীল গুণ-যোগের শৃঙ্খল — প্রতিটি ধাপ আগের ফলের জন্য অপেক্ষা করে, তাই একটি thread-এর ভেতরে ILP প্রায় নেই। SMT-র জন্য এটি আদর্শ ধরনের কাজ।

// One thread vs two threads doing independent work: wall-time ratio (varies per run and machine)
#include <pthread.h>
#include <stdio.h>
#include <time.h>
#define N 60000000u

static void *work(void *arg) {                 // independent integer work, no shared data
    unsigned x = *(unsigned *)arg;
    for (unsigned i = 0; i < N; i++) x = x * 1103515245u + 12345u;
    *(unsigned *)arg = x;                      // keep the result so the loop is not removed
    return NULL;
}
static double now(void) {
    struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec + t.tv_nsec / 1e9;
}
int main(void) {
    unsigned a = 1, b = 2;
    double t0 = now();
    work(&a); work(&b);                        // one thread does both jobs, one after another
    double one = now() - t0;
    a = 1; b = 2; t0 = now();
    pthread_t ta, tb;                          // two threads, one job each, at the same time
    if (pthread_create(&ta, NULL, work, &a) || pthread_create(&tb, NULL, work, &b)) return 1;
    pthread_join(ta, NULL); pthread_join(tb, NULL);
    double two = now() - t0;
    printf("checksums: %u %u\n", a, b);
    printf("1 thread, 2 jobs : %.2f s\n", one);
    printf("2 threads, 2 jobs: %.2f s\n", two);
    printf("ratio (1 thread / 2 threads): %.2f\n", one / two);
    return 0;
}

checksums: 2514772225 3490176258
1 thread, 2 jobs : 0.22 s
2 threads, 2 jobs: 0.13 s
ratio (1 thread / 2 threads): 1.67

৮ · নিরাপত্তা, GPU আর বড় ছবি

SMT-এর side channel আর প্রতিরক্ষা

SMT-এর সবচেয়ে বড় শক্তি — একই core-এর সব কিছু দুই thread-এর ভাগে — নিরাপত্তার দিক থেকে দুর্বলতা। দুটি sibling যদি আলাদা প্রসেস বা আলাদা virtual machine-এর হয়, তাহলে একজন অন্যজনের কাজের “ছায়া” মাপতে পারে: কোন execution port কতটা ব্যস্ত, L1 cache-এর কোন অংশ সরে গেল, TLB-তে কী আছে। এই ধরনের পরোক্ষ তথ্য-ফাঁসকে বলে side channel. ২০১৮ সালে কয়েকটি গবেষণা দল দেখায়, এমন ভাগ করা resource দিয়ে একই core-এ চলা cryptography কোডের গোপন key-এর আভাস পাওয়া সম্ভব — যেমন execution port-এর প্রতিযোগিতা (PortSmash নামে পরিচিত) আর ভাগ করা TLB (TLBleed). একই বছরের L1TF আর ২০১৯ সালের MDS পরিবারের দুর্বলতায় দেখা গেল, কিছু অবস্থায় sibling thread একে অন্যের L1 বা ভেতরের buffer-এর ডেটার আভাস পেতে পারে। পর্ব ৪১-এ speculative execution-এর আক্রমণ আর প্রতিরক্ষার মূল ধারণা দেখেছেন; এখানে শুধু SMT-এর অংশ।

প্রতিরক্ষার তিনটি স্তর:

1. SMT বন্ধ: সবচেয়ে নিশ্চিত, দামও সবচেয়ে বেশি — logical CPU অর্ধেক। OpenBSD ২০১৮ সালে ডিফল্টে Hyper-Threading বন্ধ করে। Linux-এ boot-এর সময় nosmt বা চালু অবস্থায় /sys/devices/system/cpu/smt/control দিয়ে বন্ধ করা যায় (kernel-এর version-ভেদে)।
2. Core scheduling: একই core-এর sibling-এ শুধু পরস্পর-বিশ্বস্ত task (যেমন একই প্রসেস বা একই VM-এর) একসাথে চলবে; বিশ্বস্ত কেউ না থাকলে sibling অলস থাকবে। Linux-এ ২০২১ সালের দিকে (5.14) এটি যোগ হয়েছে। Hypervisor-গুলোও আলাদা গ্রাহকের vCPU একই core-এর দুই sibling-এ না বসানোর নীতি নেয়।
3. Constant-time কোড আর hardware সংশোধন: cryptography কোড এমনভাবে লেখা যাতে গোপন ডেটার ওপর নির্ভর করে branch বা মেমরি-ঠিকানা না বদলায়; আর নতুন chip ও microcode কিছু buffer ফাঁস বন্ধ করে।

GPU — হাজার হাজার thread দিয়ে latency লুকানো

CPU মেমরির latency-র বিরুদ্ধে লড়ে মূলত তা কমিয়ে — বড় cache, prefetch, out-of-order. GPU পুরো উল্টো পথ নেয়: latency সহ্য করে, অসংখ্য thread দিয়ে ঢেকে। একটি GPU core (NVIDIA-র ভাষায় streaming multiprocessor) একসাথে বহু thread-দলের (warp) অবস্থা register-এ রেখে দেয়, আর প্রায় প্রতি cycle-এ একটি প্রস্তুত দল বেছে issue করে — একটি দল মেমরির অপেক্ষায় থাকলে অন্যটি চলে। এটি বিশাল মাত্রার fine-grained multithreading; দাম — একক thread খুব ধীর। পর্ব ৫৫-এ GPU-র SIMT মডেল বিস্তারিত।

Multithreading, multicore আর multiprocessor

আজকের server-এ তিনটিই একসাথে থাকে। পর্ব ৫৩–৫৪-এ cache coherence আর NUMA আসবে — একই core-এর thread-রা একই L1 দেখে, কিন্তু আলাদা core-এ সেটিই কঠিন প্রশ্ন।

৯ · AI-এর যুগে — multithreading-এর প্রশ্নে AI, আর যাচাইয়ের অভ্যাস

Hardware multithreading নিয়ে AI-এর উত্তর প্রায়ই সাবলীল, কিন্তু কয়েকটি ভুল বারবার দেখা যায় — বিশেষ করে শব্দ গুলিয়ে ফেলা আর বানানো সংখ্যা:

AI-এর দেওয়া multithreading-ব্যাখ্যা হাতে পেলে — চেকলিস্ট

• Software thread আর hardware thread আলাদা করে বলা হয়েছে কি না, দেখেছি
• Coarse, fine আর SMT-এর সংজ্ঞা একটি ছোট issue-slot ছক এঁকে মিলিয়েছি
• Utilisation আর thread-সংখ্যার হিসাব R, L, S দিয়ে হাতে বা simulator-এ আবার করেছি
• “SMT-তে এত % লাভ” দাবির উৎস খুঁজেছি, আর মনে রেখেছি লাভ কাজভেদে বদলায়
• নির্দিষ্ট chip-এর thread-সংখ্যা বা সাল নির্মাতার ডকুমেন্টেশন বা নিজের যন্ত্রের lscpu দিয়ে যাচাই করেছি
• নিরাপত্তার প্রশ্নে শুধু প্রতিরক্ষার দিক নিয়েছি, আর প্রতিটি প্রতিরক্ষার সীমা বুঝেছি