পারফরম্যান্স মাপা — CPU time, CPI, MIPS, Amdahl-এর সূত্র আর benchmark

১ · “দ্রুত” মানে আসলে কী — latency বনাম throughput

দুটি দোকানের কথা ভাবুন। প্রথমটি পাড়ার চায়ের দোকান — একজন মামা, অর্ডার দিলে এক মিনিটে চা হাতে। দ্বিতীয়টি অফিস-পাড়ার বড় ক্যান্টিন — অর্ডার দিলে পাঁচ মিনিট অপেক্ষা, কিন্তু একসাথে দশটি চুলায় রান্না চলে, ঘণ্টায় তিনশো কাপ বের হয়। কোনটি “দ্রুত”?

উত্তর নির্ভর করে আপনি কী জানতে চান তার ওপর। আপনি একা এক কাপ চা চাইলে মামার দোকান দ্রুত। আর অফিসের দুশো জনের চা দরকার হলে ক্যান্টিন দ্রুত। কম্পিউটারেও ঠিক এই দুই মাপকাঠি আছে:

দুটি প্রায়ই একসাথে নড়ে, কিন্তু সবসময় নয়। কয়েকটি উদাহরণ:

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

এই পর্বটি কোর্সের সবচেয়ে বেশি হিসাবের পর্বগুলোর একটি। পর্ব ০১-এ দেখেছেন কম্পিউটার কতগুলো স্তরে সাজানো, আর পর্ব ০২-এ দেখেছেন কেন clock rate একসময় থেমে গেল। এখন প্রশ্ন — কোনো নকশা “ভালো” কি না, সেটা সংখ্যা দিয়ে কীভাবে বলবেন? পরের প্রতিটি মডিউলে (pipeline, cache, multicore) এই পর্বের সূত্রগুলোই বারবার কাজে লাগবে।

২ · Performance = ১ / execution time, আর “n গুণ দ্রুত”-এর সঠিক অর্থ

সময় যত কম, পারফরম্যান্স তত বেশি। তাই সংজ্ঞাটি উল্টো অনুপাতের:

এখন দুটি কম্পিউটার X আর Y তুলনা করতে চাইলে:

উদাহরণ: একটি প্রোগ্রাম কম্পিউটার A-তে ১০ সেকেন্ডে, B-তে ১৫ সেকেন্ডে চলে। তাহলে Time_B / Time_A = 15 / 10 = 1.5 — A, B-এর চেয়ে ১.৫ গুণ দ্রুত। একই কথা উল্টো দিক থেকে: B, A-এর চেয়ে ১.৫ গুণ ধীর।

কোন “সময়” মাপছি?

একটি প্রোগ্রাম চালালে ঘড়ির কাঁটা যতটা ঘোরে, তাকে বলে wall-clock time (elapsed time) — এতে disk থেকে পড়ার অপেক্ষা, নেটওয়ার্কের অপেক্ষা, অন্য প্রোগ্রামের পালা — সব ঢুকে যায়। আর CPU আসলে এই প্রোগ্রামের কাজে যতক্ষণ ব্যস্ত ছিল, তাকে বলে CPU time. CPU time-কে আবার দুই ভাগ করা হয় — প্রোগ্রামের নিজের কোডে (user CPU time) আর প্রোগ্রামের হয়ে OS-এর কাজে (system CPU time). প্রসেসরের নকশা তুলনা করতে আমরা মূলত CPU time নিয়েই কাজ করব; ব্যবহারকারীর কাছে অবশ্য শেষ বিচারে wall-clock time-ই সত্য। অংশ ৯-এ দুটোই নিজের হাতে মেপে দেখবেন।

৩ · Clock আর CPU time-এর লৌহসূত্র

প্রসেসরের ভেতরে সবকিছু চলে একটি clock-এর তালে — একটি সংকেত যা নির্দিষ্ট ছন্দে 0 থেকে 1, আবার 1 থেকে 0 হয়। রেলস্টেশনের সিগন্যালের মতো: প্রতিটি “টিক”-এ সব register একসাথে নতুন মান নেয়। এক টিক থেকে পরের টিক পর্যন্ত সময় হলো একটি clock cycle; তার দৈর্ঘ্যকে বলে clock period বা cycle time (T_c), আর প্রতি সেকেন্ডে কতগুলো cycle — সেটি clock rate বা frequency (f).

এককগুলো মনে রাখুন: ১ GHz = ১০^৯ Hz, ১ ns = ১০^−৯ s, ১ ps = ১০^−১২ s. তাই ২.৫ GHz-এর cycle time = ১ / (২.৫ × ১০^৯) = ০.৪ ns = ৪০০ ps.

তিন গুণকের সূত্র

একটি প্রোগ্রাম চালাতে CPU-র মোট কতগুলো clock cycle লাগল, সেটিকে cycle time দিয়ে গুণ করলেই CPU time:

এখন clock cycle কোথা থেকে আসে? প্রোগ্রাম চালায় কিছু সংখ্যক instruction — একে বলে instruction count (IC). প্রতিটি instruction গড়ে কতগুলো cycle নেয়, সেটি CPI (cycles per instruction). তাহলে মোট cycle = IC × CPI. বসিয়ে দিলে পাওয়া যায় কম্পিউটার আর্কিটেকচারের সবচেয়ে বিখ্যাত সূত্রটি — অনেকে একে বলেন পারফরম্যান্সের লৌহসূত্র (iron law):

এককগুলো মিলিয়ে দেখলে সূত্রটি নিজেই নিজেকে প্রমাণ করে:

seconds/program = (instructions/program) × (cycles/instruction) × (seconds/cycle)

কোন গুণককে কে প্রভাবিত করে

এই টেবিলটি পরীক্ষায় খুব আসে, আর বাস্তবেও কাজের — কোনো পরিবর্তনের প্রভাব কোথায় পড়বে তা আগে থেকে অনুমান করা যায়:

* মেমরি আর CPU-র গতি আলাদা হারে বদলালে cycle-এ মাপা memory latency বদলে যায়, তাই বাস্তবে CPI-ও কিছুটা বদলায় — পর্ব ৪৭-এ cache-এর হিসাবে দেখবেন।

একটি ক্লাসিক হিসাব: clock কত হলে চলবে?

একটি প্রোগ্রাম ২ GHz-এর কম্পিউটার A-তে ১০ সেকেন্ডে চলে। নকশাকারী চান নতুন কম্পিউটার B-তে এটি ৬ সেকেন্ডে চলুক। B-এর clock বাড়ানো যাবে, কিন্তু তার ফলে একই প্রোগ্রামে A-র চেয়ে ১.২ গুণ বেশি clock cycle লাগবে। B-এর clock rate কত হতে হবে?

1. A-র cycle = time × rate = ১০ × ২ × ১০^৯ = ২০ × ১০^৯.
2. B-এর cycle = ১.২ × ২০ × ১০^৯ = ২৪ × ১০^৯.
3. B-এর rate = cycle / time = ২৪ × ১০^৯ / ৬ = ৪ × ১০^৯ = ৪ GHz.

অর্থাৎ ১.৬৭ গুণ দ্রুত হতে clock দ্বিগুণ করতে হচ্ছে — কারণ বাড়তি cycle-এর দাম দিতে হয়েছে।

৪ · CPI আর instruction mix — ধাপে ধাপে হিসাব

প্রথমে সবচেয়ে সরল তুলনা: একই ISA-র দুটি machine, একই প্রোগ্রাম, তাই IC একই। একটির clock দ্রুত, অন্যটির CPI কম। কে জিতবে? “পরে” চাপুন:

Instruction mix থেকে weighted CPI

বাস্তবে সব instruction সমান cycle নেয় না। যোগ-বিয়োগ (ALU) হয়তো ১ cycle-এ, মেমরি থেকে load করতে বেশি, শাখা (branch) মাঝামাঝি। প্রোগ্রামে কোন ধরনের instruction কত ভাগ — সেটিকে বলে instruction mix. তখন CPI হলো প্রতিটি class-এর CPI-এর ভারযুক্ত গড়:

কেন এটা ঠিক? মোট cycle = প্রতিটি class-এর (instruction সংখ্যা × সেই class-এর CPI)-এর যোগফল। দুই পাশকে IC দিয়ে ভাগ করলে বাঁ পাশে আসে CPI-এর সংজ্ঞা (cycle/IC), আর ডান পাশে প্রতিটি IC_i/IC হয়ে যায় ভগ্নাংশ F_i. তাই weighted CPI কোনো আনুমানিক কৌশল নয় — এটি সংজ্ঞা থেকেই আসা একটি অভেদ।

নিচের mix-টি একটি সরল multi-cycle প্রসেসরের মতো ধরা (load ধীর, কারণ মেমরিতে যেতে হয়)। ধাপে ধাপে যোগফল দেখুন:

পরীক্ষার ক্লাসিক: দুই compiler, কে দ্রুত?

একটি ২ GHz machine-এ তিন class-এর instruction: A (CPI ১), B (CPI ২), C (CPI ৩)। একই C প্রোগ্রাম দুটি compiler দুইভাবে অনুবাদ করল (সংখ্যা ১০^৯ এককে):

Compiler 2 বেশি instruction দিয়েছে (৬ বনাম ৫), তবু কম cycle লেগেছে, কারণ সে দামি C-class instruction কম ব্যবহার করেছে। Compiler 2-এর কোড ৫.০ / ৪.৫ ≈ ১.১১ গুণ দ্রুত। শিক্ষা: IC কম মানেই দ্রুত নয়।

নিচের simulator লৌহসূত্র দিয়ে কয়েকটি পরিস্থিতি হিসাব করে — CPU time, effective CPI, MIPS (পরের অংশে ব্যাখ্যা) আর “কতগুণ দ্রুত”। শেষ দুটি পরিস্থিতি খেয়াল করুন। Run চাপুন, সংখ্যা বদলে নিজের প্রশ্নও চালান:

// Iron law: CPU time = IC x CPI / clock rate. mix = [[count in 1e9, CPI], ...]
function run(name, mix, clockGHz) {
  let ic = 0, cycles = 0;
  for (const [n, cpi] of mix) { ic += n * 1e9; cycles += n * 1e9 * cpi; }
  const time = cycles / (clockGHz * 1e9);            // seconds
  const cpi = cycles / ic, mips = ic / (time * 1e6);
  console.log(`  ${name.padEnd(11)} IC=${(ic / 1e9).toFixed(1)}e9  CPI=${cpi.toFixed(3)}` +
              `  time=${time.toFixed(3)} s  MIPS=${mips.toFixed(0)}`);
  return { name, time, mips };
}
function compare(a, b) {
  const [fast, slow] = a.time <= b.time ? [a, b] : [b, a];
  const byMips = a.mips >= b.mips ? a : b;
  console.log(`  -> ${fast.name} is ${(slow.time / fast.time).toFixed(3)} times faster;` +
              ` higher MIPS: ${byMips.name}` + (byMips === fast ? " (agrees)" : "  <-- MIPS is WRONG"));
}
console.log("1) Same program, same ISA: A = 4 GHz CPI 2.0, B = 2 GHz CPI 1.2");
compare(run("Machine A", [[1, 2.0]], 4), run("Machine B", [[1, 1.2]], 2));
console.log("2) Two compilers on a 2 GHz machine, classes A/B/C have CPI 1/2/3");
compare(run("Compiler 1", [[2, 1], [1, 2], [2, 3]], 2), run("Compiler 2", [[4, 1], [1, 2], [1, 3]], 2));
console.log("3) Two compilers on a 4 GHz machine, same CPI 1/2/3");
compare(run("Compiler X", [[5, 1], [1, 2], [1, 3]], 4), run("Compiler Y", [[10, 1], [1, 2], [1, 3]], 4));
console.log("4) Different ISAs, both 3 GHz: simple ISA needs more instructions");
compare(run("Simple ISA", [[1.5, 1.0]], 3), run("Rich ISA", [[1.0, 1.2]], 3));

1) Same program, same ISA: A = 4 GHz CPI 2.0, B = 2 GHz CPI 1.2
  Machine A   IC=1.0e9  CPI=2.000  time=0.500 s  MIPS=2000
  Machine B   IC=1.0e9  CPI=1.200  time=0.600 s  MIPS=1667
  -> Machine A is 1.200 times faster; higher MIPS: Machine A (agrees)
2) Two compilers on a 2 GHz machine, classes A/B/C have CPI 1/2/3
  Compiler 1  IC=5.0e9  CPI=2.000  time=5.000 s  MIPS=1000
  Compiler 2  IC=6.0e9  CPI=1.500  time=4.500 s  MIPS=1333
  -> Compiler 2 is 1.111 times faster; higher MIPS: Compiler 2 (agrees)
3) Two compilers on a 4 GHz machine, same CPI 1/2/3
  Compiler X  IC=7.0e9  CPI=1.429  time=2.500 s  MIPS=2800
  Compiler Y  IC=12.0e9  CPI=1.250  time=3.750 s  MIPS=3200
  -> Compiler X is 1.500 times faster; higher MIPS: Compiler Y  <-- MIPS is WRONG
4) Different ISAs, both 3 GHz: simple ISA needs more instructions
  Simple ISA  IC=1.5e9  CPI=1.000  time=0.500 s  MIPS=3000
  Rich ISA    IC=1.0e9  CPI=1.200  time=0.400 s  MIPS=2500
  -> Rich ISA is 1.250 times faster; higher MIPS: Simple ISA  <-- MIPS is WRONG

৫ · MIPS আর MFLOPS — সহজ সংখ্যা, কিন্তু ফাঁদ

CPU time-এর হিসাবে তিনটি সংখ্যা লাগে, অথচ বিজ্ঞাপনে মানুষ একটি সংখ্যা চায়। তাই একসময় খুব জনপ্রিয় ছিল MIPS — million instructions per second (প্রতি সেকেন্ডে কত দশ লক্ষ instruction; ১ MIPS = ১০^৬ instruction/s). সতর্কতা: এখানে MIPS একটি মাপকাঠি, MIPS নামের ISA (পর্ব ২৫-এ দেখবেন) নয়।

দ্বিতীয় রূপটি দেখলেই সমস্যা ধরা পড়ে: MIPS-এ IC নেই! অথচ CPU time = IC / (MIPS × ১০^৬)। তিনটি কারণে MIPS ভুল রায় দিতে পারে:

1. ভিন্ন ISA-র তুলনা চলে না। একটি জটিল instruction যে কাজ করে, সরল ISA-তে তার জন্য তিনটি লাগতে পারে। “বেশি instruction প্রতি সেকেন্ড” তখন “বেশি কাজ প্রতি সেকেন্ড” নয়।
2. একই machine-এও প্রোগ্রাম ভেদে MIPS বদলায়। Instruction mix বদলালে CPI বদলায়, তাই কোনো machine-এর “একটি MIPS সংখ্যা” হয় না।
3. MIPS পারফরম্যান্সের উল্টো দিকে যেতে পারে। উপরের পরিস্থিতি ৩-এর মতো — সস্তা instruction যোগ করে MIPS বাড়ানো যায়, অথচ সময় বাড়ে।

এজন্য রসিকতা করে MIPS-এর পূর্ণরূপ বলা হতো “Meaningless Indicator of Processor Speed”. তবে একই ISA, একই compiler আর একই প্রোগ্রামে MIPS দিয়ে তুলনা চলে — তখন IC স্থির, আর MIPS সময়ের উল্টো অনুপাতে চলে।

MFLOPS আর peak FLOPS

বিজ্ঞান ও AI-এর কাজে মাপা হয় MFLOPS — প্রতি সেকেন্ডে কত মিলিয়ন floating-point operation (ভগ্নাংশসহ সংখ্যার যোগ-গুণ)। এখানেও ফাঁদ আছে: যোগ আর ভাগের খরচ এক নয়, ভিন্ন machine-এ ভিন্ন operation আছে, আর বিজ্ঞাপনের সংখ্যাটি প্রায়ই peak — তাত্ত্বিক সর্বোচ্চ:

ধরা যাক ৮ core, ৩ GHz, আর প্রতিটি core প্রতি cycle-এ ১৬টি double-precision (৬৪-বিট) FLOP করতে পারে (যেমন দুটি ২৫৬-bit FMA (গুণ আর যোগ এক ধাপে) unit: ২ × ৪ সংখ্যা × ২ operation). তাহলে peak = ৮ × ৩ × ১০^৯ × ১৬ = ৩৮৪ GFLOPS. বাস্তব প্রোগ্রাম এর কাছাকাছি পৌঁছায় কেবল তখনই, যখন ডেটা ঠিক সময়ে cache থেকে আসে আর কোড SIMD (পর্ব ৪২) ব্যবহার করে। সাধারণ প্রোগ্রামে sustained (টানা যা পাওয়া যায়) গতি এর অনেক নিচে থাকে।

৬ · Benchmark — SPEC, geometric mean আর সাধারণ ভুল

সবচেয়ে সৎ মাপ হলো আপনার নিজের প্রোগ্রাম চালিয়ে দেখা। কিন্তু কেনার আগে সব প্রোগ্রাম চালানো সম্ভব নয়। তাই তৈরি হয়েছে benchmark — বাস্তব প্রোগ্রাম থেকে বাছাই করা একটি সংগ্রহ, যা সবাই একই নিয়মে চালায়।

SPEC CPU

১৯৮৮ সালে কয়েকটি কম্পিউটার কোম্পানি মিলে অলাভজনক সংস্থা SPEC (Standard Performance Evaluation Corporation) গঠন করে। এর CPU benchmark (বহু বছর ধরে প্রচলিত সংস্করণ SPEC CPU 2017) দুই ভাগে: integer (compiler, compression, chess engine, XML প্রক্রিয়ার মতো প্রোগ্রাম) আর floating point (আবহাওয়া, পদার্থবিজ্ঞান, molecular dynamics-এর মতো বৈজ্ঞানিক প্রোগ্রাম)। প্রতিটি আবার দুইভাবে চালানো হয় — “speed” (একটি কাজ কত দ্রুত — latency) আর “rate” (একসাথে অনেক কপি — throughput).

প্রতিটি প্রোগ্রামের জন্য হিসাব করা হয় একটি অনুপাত: SPECratio = reference machine-এর সময় / আপনার machine-এর সময়. তারপর সব অনুপাতের geometric mean নেওয়া হয়:

কেন geometric mean, arithmetic নয়?

কারণ অনুপাতের গাণিতিক গড় (arithmetic mean) নির্ভর করে কোন machine-কে reference ধরা হলো তার ওপর — reference বদলালে রায়ও উল্টে যেতে পারে। Geometric mean-এ এই সমস্যা নেই: GM(Tref/TX) / GM(Tref/TY) = GM(TY/TX), অর্থাৎ ভাগ করলে reference-এর সময় কেটে যায়। একটি ছোট উদাহরণ — দুটি প্রোগ্রাম P1, P2; X-এ সময় ১০ s ও ৫০ s, Y-এ ২০ s ও ২৫ s:

একই দুটি machine, একই মাপা সময় — শুধু reference বদলাতেই arithmetic mean রায় উল্টে দিল, আর geometric mean স্থির থাকল। (তবে মনে রাখুন, geometric mean মোট সময়ের সাথে মেলে না; নিজের নির্দিষ্ট কাজের মিশ্রণ জানা থাকলে ভারযুক্ত মোট সময়ই সবচেয়ে অর্থপূর্ণ।)

অন্যান্য benchmark

• Geekbench — ফোন আর ল্যাপটপের রিভিউতে খুব দেখা যায়; কয়েকটি ছোট কাজ (যেমন compression, ছবি প্রক্রিয়া) মিলিয়ে একটি single-core আর একটি multi-core স্কোর দেয়। তুলনার জন্য সুবিধাজনক, তবে কাজগুলো ছোট বলে বড় প্রোগ্রামের memory আচরণ পুরোপুরি ধরা পড়ে না বলে সমালোচনা আছে।
• MLPerf — MLCommons নামের একটি consortium-এর benchmark, machine learning-এর training আর inference মাপে; AI accelerator (পর্ব ৫৫) তুলনায় ব্যবহৃত হয়।
• LINPACK / HPL — বিশাল ম্যাট্রিক্স সমীকরণ সমাধান; বিশ্বের সুপারকম্পিউটারের TOP500 তালিকা এটি দিয়ে সাজানো হয়।

সাধারণ ভুল ও ফাঁদ

• Synthetic benchmark: Dhrystone-এর মতো ছোট কৃত্রিম প্রোগ্রাম বাস্তব কাজের প্রতিনিধি নয়, আর compiler বিশেষ কৌশলে এদের প্রায় “উড়িয়ে” দিতে পারে।
• Peak বনাম sustained: তাত্ত্বিক সর্বোচ্চ (peak) প্রায় কখনো টানা পাওয়া যায় না। দাবি দেখলে জিজ্ঞেস করুন — কোন প্রোগ্রামে, কতক্ষণ?
• সূত্রের একটি অংশ দিয়ে বিচার: শুধু GHz, শুধু core সংখ্যা, বা শুধু MIPS — লৌহসূত্রের তিন গুণকের একটি দিয়ে রায় দেওয়া সবচেয়ে প্রচলিত ভুল।
• Benchmark-এর জন্য বিশেষ tuning: কোম্পানি চাইলে compiler-কে নির্দিষ্ট benchmark চিনে বিশেষ কৌশল প্রয়োগ করাতে পারে। SPEC-এর নিয়মে এমন benchmark-নির্দিষ্ট optimization নিষিদ্ধ, আর ফলাফলের সাথে compiler flag প্রকাশ করতে হয়।
• এক প্রোগ্রামের উন্নতিকে সবখানে ধরে নেওয়া: একটি অংশ দ্রুত হলে পুরো প্রোগ্রাম ততটা দ্রুত হয় না — ঠিক পরের অংশের বিষয়।

৭ · Amdahl-এর সূত্র — যে অংশ দ্রুত হয়নি, সেটিই সীমা

ধরুন ঢাকা থেকে কক্সবাজার যাবেন। প্লেনে ঢাকা–কক্সবাজার এক ঘণ্টা, কিন্তু বাসা থেকে বিমানবন্দরে যেতে, চেক-ইন আর অপেক্ষায় লাগে আরও তিন ঘণ্টা। এখন প্লেন দ্বিগুণ দ্রুত হলেও মোট যাত্রা চার ঘণ্টা থেকে মাত্র সাড়ে তিন ঘণ্টায় নামে। প্লেন অসীম দ্রুত হলেও তিন ঘণ্টার নিচে নামবে না। এই সাধারণ সত্যটির নামই Amdahl-এর সূত্র — ১৯৬৭ সালে IBM-এর প্রকৌশলী Gene Amdahl এই যুক্তি দেন।

প্রমাণ (derivation)

পুরোনো execution time-কে ১ ধরুন। এর মধ্যে f ভগ্নাংশ (০ ≤ f ≤ ১) এমন অংশ, যা আমরা s গুণ দ্রুত করতে পারি; বাকি (১ − f) অংশ যেমন ছিল তেমন থাকে।

1. অপরিবর্তিত অংশের নতুন সময় = (১ − f) × ১ = ১ − f.
2. উন্নত অংশের নতুন সময় = f / s (s গুণ দ্রুত মানে সময় s ভাগের এক)।
3. নতুন মোট সময় = (১ − f) + f / s.
4. Speedup = পুরোনো সময় / নতুন সময় = ১ / ((১ − f) + f/s).

সীমার যুক্তি: s যত বড়ই হোক, f/s > ০, তাই হর সবসময় (১ − f)-এর চেয়ে বড় — speedup কখনো ১/(১ − f) ছোঁয় না, শুধু তার দিকে এগোয়। আর s বাড়লে হর কমে, তাই speedup s-এর সাথে বাড়তে থাকে কিন্তু ক্রমশ কম হারে (diminishing returns).

উদাহরণ ১: একটি প্রোগ্রামের ৮০% সময় একটি অংশে যায়, সেটিকে ৪ গুণ দ্রুত করলেন। Speedup = ১ / (০.২ + ০.৮/৪) = ১ / (০.২ + ০.২) = ১ / ০.৪ = ২.৫ — ৪ নয়।
উদাহরণ ২: একই অংশকে অসীম দ্রুত করলেও (সময় শূন্য) speedup = ১ / ০.২ = ৫, তার বেশি কখনো নয়।

নিচের stepper-এ f = ০.৯ (৯০% অংশ দ্রুত করা যায়) রেখে s ধাপে ধাপে বাড়ানো হয়েছে। ▓ = অপরিবর্তিত অংশের সময়, ░ = দ্রুত হওয়া অংশের সময় (২০ ঘর = পুরোনো মোট সময়):

Multicore রূপ: serial অংশ সমান্তরালতার সীমা টানে

N টি core-এ প্রোগ্রামের সমান্তরাল অংশ (১ − s_f) আদর্শভাবে N ভাগ হয়, আর serial ভগ্নাংশ s_f (এক core-এ মাপা মূল সময়ের ভাগ) একটি core-এই চলে। তাহলে Amdahl-এ s = N বসিয়ে:

মাত্র ৫% serial অংশ থাকলে ১০০০ core দিয়েও speedup ২০-এর নিচে থাকবে। আর বাস্তবে core-দের মধ্যে যোগাযোগ, lock আর cache coherence (পর্ব ৫৩)-এর বাড়তি খরচ এটিকে আরও কমায়।

Gustafson-এর পাল্টা যুক্তি: সমস্যাও বড় হয়

১৯৮৮ সালে John Gustafson লক্ষ করেন, বাস্তবে বেশি core পেলে মানুষ একই ছোট সমস্যা দ্রুত শেষ করে না — বরং বড় সমস্যা (বেশি রেজোলিউশনের আবহাওয়ার মডেল, বড় AI মডেল) একই সময়ে চালায়। তখন serial অংশ মোটামুটি একই থাকে আর সমান্তরাল অংশ N-এর সাথে বাড়ে। এই “scaled speedup” হলো:

এখানে s_f হলো সমান্তরাল machine-এ মাপা সময়ের serial ভগ্নাংশ। দুটি সূত্র পরস্পরবিরোধী নয় — Amdahl প্রশ্ন করেন “নির্দিষ্ট কাজ কত দ্রুত হবে?”, Gustafson প্রশ্ন করেন “নির্দিষ্ট সময়ে কত বড় কাজ হবে?”। নিচের simulator দুটিকেই পাশাপাশি হিসাব করে:

// Amdahl: speedup = 1 / ((1 - f) + f / s); s = Infinity gives the limit 1 / (1 - f)
const amdahl = (f, s) => 1 / ((1 - f) + f / s);
const S = [2, 4, 16, Infinity];
console.log("f       " + S.map(s => ("s=" + (s === Infinity ? "inf" : s)).padStart(8)).join(""));
for (const f of [0.5, 0.8, 0.9, 0.95, 0.99])
  console.log(f.toFixed(2).padEnd(8) + S.map(s => amdahl(f, s).toFixed(3).padStart(8)).join(""));

console.log("\nN cores   Amdahl 5%  Amdahl 10%  Gustafson 5%  Gustafson 10%");
for (const N of [1, 2, 4, 8, 16, 32, 64]) {
  const a = sf => (1 / (sf + (1 - sf) / N)).toFixed(2);   // fixed problem size
  const g = sf => (N - sf * (N - 1)).toFixed(2);          // problem grows with N
  console.log(String(N).padStart(7) + a(0.05).padStart(12) + a(0.10).padStart(12) +
              g(0.05).padStart(14) + g(0.10).padStart(15));
}
console.log("\nlimit with 1000000 cores: Amdahl 5% = " + amdahl(0.95, 1e6).toFixed(2) +
            ", Amdahl 10% = " + amdahl(0.90, 1e6).toFixed(2));

f            s=2     s=4    s=16   s=inf
0.50       1.333   1.600   1.882   2.000
0.80       1.667   2.500   4.000   5.000
0.90       1.818   3.077   6.400  10.000
0.95       1.905   3.478   9.143  20.000
0.99       1.980   3.883  13.913 100.000

N cores   Amdahl 5%  Amdahl 10%  Gustafson 5%  Gustafson 10%
      1        1.00        1.00          1.00           1.00
      2        1.90        1.82          1.95           1.90
      4        3.48        3.08          3.85           3.70
      8        5.93        4.71          7.65           7.30
     16        9.14        6.40         15.25          14.50
     32       12.55        7.80         30.45          28.90
     64       15.42        8.77         60.85          57.70

limit with 1000000 cores: Amdahl 5% = 20.00, Amdahl 10% = 10.00

৮ · Power আর energy — দ্রুত হওয়াই একমাত্র লক্ষ্য নয়

ফোনে চার্জ কতক্ষণ থাকবে, ল্যাপটপ কতটা গরম হবে, ডেটা সেন্টারের বিদ্যুৎ বিল কত — আজকের নকশায় এগুলো গতির মতোই গুরুত্বপূর্ণ। দুটি শব্দ আলাদা করে বুঝুন:

• Power (ক্ষমতা): প্রতি সেকেন্ডে কত energy খরচ হচ্ছে, একক watt (W = J/s). এটি ঠিক করে chip কতটা গরম হবে আর কতটা ঠান্ডা করার ব্যবস্থা লাগবে।
• Energy (শক্তি): একটি কাজ শেষ করতে মোট কত খরচ, একক joule (J). ব্যাটারির চার্জ আর বিদ্যুৎ বিল এটিই ঠিক করে।

CMOS chip-এর dynamic power মোটামুটি α × C × V² × f-এর সমানুপাতিক — voltage আর frequency কমালে power অনেক কমে; এর বিস্তারিত আর “power wall”-এর গল্প আছে পর্ব ০২-এ, আর embedded প্রসঙ্গে পর্ব ৫৬-এ।

Data center আর ফোন — দুই জায়গাতেই এখন বড় মাপকাঠি performance per watt: প্রতি watt-এ কত কাজ, অথবা সমার্থকভাবে প্রতি joule-এ কতগুলো কাজ।

Race-to-idle: দ্রুত শেষ করে ঘুমিয়ে পড়া

অবাক করা একটি কৌশল হলো race-to-idle: বেশি power-এ কাজটি দ্রুত শেষ করে chip-কে গভীর ঘুমে (খুব কম power) পাঠানো। কারণ chip চালু থাকলেই memory, clock আর leakage (transistor বন্ধ থাকলেও চুইয়ে যাওয়া current)-এর একটি স্থির খরচ চলতে থাকে — দ্রুত শেষ করলে সেই স্থির খরচ কম সময় ধরে দিতে হয়। একটি ১০ সেকেন্ডের সময়-জানালায় একই কাজের তিনটি কাল্পনিক উদাহরণ:

অর্থাৎ race-to-idle সবসময় জেতে না — দ্রুত মোডে power কতটা বাড়ে আর ঘুমের অবস্থা কতটা গভীর, তার ওপর নির্ভর করে। বাস্তবে OS আর firmware এই সিদ্ধান্ত নেয় DVFS (voltage-frequency বদলানো) দিয়ে, আর সঠিক কৌশল chip ও কাজ ভেদে আলাদা — তাই মেপে দেখাই একমাত্র নিশ্চিত উপায়।

৯ · আসল প্রোগ্রাম মাপা — wall time, CPU time, time আর performance counter

তত্ত্ব যথেষ্ট, এবার নিজের হাতে মাপি। C-তে দুটি ঘড়ি আছে: clock_gettime(CLOCK_MONOTONIC) দেয় wall-clock সময় (দেয়ালের ঘড়ি, যা কখনো পেছনে যায় না), আর clock() দেয় এই process-এর ব্যবহার করা CPU time. নিচের প্রোগ্রাম প্রথমে একটি হিসাবের loop চালায়, তারপর ০.৩ সেকেন্ড ঘুমায় — দুটি ঘড়ি দুই ক্ষেত্রে কী বলে দেখুন:

#define _POSIX_C_SOURCE 199309L
#include <stdio.h>
#include <stdint.h>
#include <time.h>

static double wall(void) {                       /* wall-clock seconds */
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return (double)t.tv_sec + (double)t.tv_nsec / 1e9;
}
static double cpu(void) { return (double)clock() / CLOCKS_PER_SEC; }  /* CPU seconds */

int main(void) {
    const uint64_t N = 200000000u;               /* 2 x 10^8 iterations */
    volatile uint64_t x = 1;                     /* volatile: loop is not optimized away */
    double w0 = wall(), c0 = cpu();
    for (uint64_t i = 0; i < N; i++)
        x = x * 6364136223846793005u + 1442695040888963407u;
    double w1 = wall(), c1 = cpu();
    struct timespec nap = {0, 300000000L};       /* sleep 0.3 s: waiting, not computing */
    nanosleep(&nap, NULL);
    double w2 = wall(), c2 = cpu();
    printf("loop : wall %.2f s, cpu %.2f s\n", w1 - w0, c1 - c0);
    printf("sleep: wall %.2f s, cpu %.2f s\n", w2 - w1, c2 - c1);
    printf("about %.1f ns per iteration (varies per run and machine)\n", (w1 - w0) / (double)N * 1e9);
    printf("check value: %llu\n", (unsigned long long)(x % 1000u));
    return 0;
}

loop : wall 0.85 s, cpu 0.38 s
sleep: wall 0.31 s, cpu 0.00 s
about 4.2 ns per iteration (varies per run and machine)
check value: 465

Shell-এর time: real, user, sys

যেকোনো কমান্ডের আগে time লিখলে তিনটি সংখ্যা পাবেন: real = wall-clock সময়, user = প্রোগ্রামের নিজের কোডে CPU time, sys = প্রোগ্রামের হয়ে kernel-এর কাজে CPU time. নিয়মগুলো এই:

• একটি thread, পুরোটা হিসাব: real ≈ user + sys.
• অপেক্ষা (sleep, disk, নেটওয়ার্ক) থাকলে: real > user + sys.
• কয়েকটি core একসাথে কাজ করলে: user + sys > real হতে পারে — কারণ CPU time সব core-এর যোগফল।

# bash 'time' keyword: real = wall clock, user/sys = CPU time used by the commands
TIMEFORMAT='   real %3Rs   user %3Us   sys %3Ss'
work() { local s=0 i; for ((i = 0; i < 200000; i++)); do s=$((s + i)); done; }
echo "cores available: $(nproc 2>/dev/null || echo unknown)"
echo "1) CPU-bound bash loop (200000 additions):"
{ time work; } 2>&1
echo "2) sleep 0.5 (only waiting):"
{ time sleep 0.5; } 2>&1
echo "3) the same loop twice, in parallel:"
{ time { work & work & wait; }; } 2>&1
if command -v gcc >/dev/null 2>&1; then
  printf 'int main(void){volatile unsigned long x=0;for(unsigned long i=0;i<300000000UL;i++)x+=i;return 0;}\n' > t.c
  if gcc -O1 t.c -o t 2>/dev/null; then
    echo "4) compiled C loop (3 x 10^8 additions):"
    { time ./t; } 2>&1
  else echo "4) gcc found but compile failed - skipped"; fi
else
  echo "4) gcc not available here - compiled test skipped"
fi

cores available: 2
1) CPU-bound bash loop (200000 additions):
   real 3.921s   user 1.058s   sys 0.017s
2) sleep 0.5 (only waiting):
   real 0.523s   user 0.002s   sys 0.002s
3) the same loop twice, in parallel:
   real 7.198s   user 2.421s   sys 0.483s
4) compiled C loop (3 x 10^8 additions):
   real 1.288s   user 0.425s   sys 0.008s

Performance counter: cycle আর instruction সরাসরি গোনা

আধুনিক CPU-র ভেতরে কিছু বিশেষ register আছে, যারা গোনে কতগুলো cycle গেল, কতগুলো instruction শেষ হলো, কতবার cache miss বা branch mispredict হলো — এদের বলে hardware performance counter. Linux-এ perf stat এগুলো পড়ে দেয়। এই পাতার runner-এ perf চালানো যায় না (container-এ counter পড়ার অনুমতি থাকে না), তাই নিচেরটি শুধু উদাহরণ — একটি কাল্পনিক ম্যাট্রিক্স-গুণের প্রোগ্রামে আউটপুট দেখতে মোটামুটি এমন:

# উদাহরণ (চালানো হয়নি) — সংখ্যাগুলো দেখানোর জন্য বানানো
$ perf stat -e cycles,instructions ./matmul

 Performance counter stats for './matmul':

     6,012,345,678      cycles
     9,018,518,517      instructions              #    1.50  insn per cycle

       2.004123456 seconds time elapsed
       1.998000000 seconds user
       0.004000000 seconds sys

এখান থেকে লৌহসূত্রের প্রতিটি গুণক পড়ে নেওয়া যায়: IPC (instructions per cycle) = ৯,০১৮,৫১৮,৫১৭ / ৬,০১২,৩৪৫,৬৭৮ = ১.৫০, তাই CPI = 1 / IPC ≈ 0.667; গড় clock ≈ ৬.০১ × ১০^৯ cycle / ২.০০৪ s ≈ ৩.০ GHz. CPI ১-এর কম কেন? কারণ আধুনিক core প্রতি cycle-এ একাধিক instruction শেষ করতে পারে (superscalar, পর্ব ৩৯)। অপ্টিমাইজ করার পর আবার মাপলে বোঝা যায় উন্নতিটা IC কমিয়ে এসেছে, নাকি CPI কমিয়ে — অনুমানের দরকার হয় না।

OS-এর দিক থেকে top, vmstat, perf দিয়ে পুরো সিস্টেমের তদন্ত কীভাবে করা হয়, তা বিস্তারিত আছে Operating Systems কোর্সের পারফরম্যান্স আর observability পর্বে।

১০ · AI-এর যুগে — পারফরম্যান্সের হিসাব AI দিয়ে, যাচাই নিজে

“এই দুই CPU-র মধ্যে কোনটি দ্রুত?” বা “CPI কত হবে?” — এমন প্রশ্নে AI খুব দ্রুত উত্তর দেয়, আর প্রায়ই আত্মবিশ্বাসের সাথে ভুল দেয়। এই পর্বের বিষয়ে AI-এর সাধারণ ভুলগুলো:

• একক গুলিয়ে ফেলা — ps, ns, GHz, MHz মেলাতে গিয়ে ১০^৩ গুণ ভুল; “৫০% দ্রুত” আর “৫০% কম সময়” গুলিয়ে ফেলা।
• Instruction mix-এ ভগ্নাংশের যোগফল ১ কি না না দেখা, বা IC বদলেছে অথচ শুধু CPI তুলনা করা।
• Amdahl-এ f আর s উল্টে বসানো, বা “৮০% অংশ ৪ গুণ দ্রুত” থেকে সরাসরি “৩.২ গুণ” (০.৮ × ৪) বলে দেওয়া।
• MIPS বা GHz দিয়ে ভিন্ন ISA-র CPU তুলনা করা; চিপের spec (cache, clock, core সংখ্যা) বানিয়ে বলা।
• Benchmark স্কোরের উৎস, সংস্করণ বা পরীক্ষার শর্ত না বলে সংখ্যা দেওয়া।

AI-এর দেওয়া পারফরম্যান্স-হিসাব যাচাইয়ের চেকলিস্ট

• প্রতিটি সংখ্যার একক মিলিয়েছি — cycle × (s/cycle) = s; GHz-কে ১০^৯ ধরেছি
• ভগ্নাংশের যোগফল ১, আর IC বদলালে তিনটি গুণকই গুণ করা হয়েছে
• Amdahl-এর উত্তর কখনো ১/(১ − f)-এর বেশি নয় — এই sanity check করেছি
• উত্তরটি নিজে একটি ছোট স্ক্রিপ্ট (যেমন উপরের simulator) দিয়ে আবার হিসাব করেছি
• চিপের spec বা benchmark স্কোর নির্মাতার datasheet বা প্রকাশিত ফলাফলে মিলিয়েছি, আর সম্ভব হলে নিজের machine-এ time/perf দিয়ে মেপেছি