Benchmarking Methodology — যেখানে ভুল দাবি জন্ম নেয়, আর যেভাবে ঠেকানো যায়

সঠিক benchmarking একটা নিয়মশৃঙ্খলা, একটা একক টুল না — সাতটা পুনরাবৃত্ত ভুল, আর প্রতিটার নির্দিষ্ট প্রতিকার।

সমস্যা ১ — Warm-up: প্রথম run মিথ্যা বলে

প্রথমবার একটা function চালালে সেটা প্রায় সবসময় ধীরতম run — তিনটা ভিন্ন কারণে, ভিন্ন layer-এ:

১. JIT compilation (managed language-এ)। JVM, V8 (JavaScript), .NET-এর মতো runtime প্রথমে bytecode interpret করে — ধীর। একটা function যথেষ্টবার call হলে (একটা “hot” threshold পার হলে) JIT compiler সেটা native machine code-এ কম্পাইল করে — তারপর হঠাৎ কয়েকগুণ দ্রুত হয়ে যায়। প্রথম কয়েকশ call এই ধীর interpreted পর্যায়ে কাটে।

২. Cache warming। Cache hierarchy লেসনের সেই সংখ্যাগুলো মনে করুন — একটা cold cache miss মানে ~২০০ cycle DRAM latency। কোনো data structure প্রথমবার access করলে প্রতিটা access-ই প্রায় cold miss। দ্বিতীয়বার একই data access করলে তা L1/L2/L3-এ থেকে যায় — বহুগুণ দ্রুত। একটা “প্রথম call ধীর” আসলে অনেক সময় শুধুই এই cache warming-এর প্রভাব, algorithm-এর কোনো দোষ না।

৩. CPU frequency scaling / turbo boost। এটা সবচেয়ে পাল্টাপাল্টি — দুই দিকেই যেতে পারে:

• Idle অবস্থা থেকে হঠাৎ কাজ শুরু করলে, thermal headroom থাকায় CPU turbo boost frequency-তে চলে (datasheet base clock-এর চেয়ে বেশি) — প্রথম কয়েক সেকেন্ড বেশি দ্রুত, তারপর তাপ জমতে থাকলে sustained frequency-তে নেমে আসে (throttling)।
• উল্টোদিকে, powersave/schedutil CPU governor ব্যবহার করা সিস্টেমে idle থেকে কাজ শুরু করলে clock কম frequency-তে শুরু হয়, ধীরে ধীরে বাড়ে — প্রথম কয়েক iteration কম দ্রুত।

প্রতিকার — warm-up iteration আলাদা করা:

warm-up phase:   N বার চালান, ফলাফল সম্পূর্ণ বাতিল করুন
measured phase:  তারপর M বার চালান, শুধু এগুলোই report করুন

N-এর একটা ভালো নিয়ম: যতক্ষণ না সাম্প্রতিক কয়েকটা run-এর সময় স্থিতিশীল হয় (একটা plateau-তে পৌঁছায়), ততক্ষণ warm-up চালিয়ে যান — একটা নির্দিষ্ট সংখ্যা (যেমন “৫ বার”) অন্ধভাবে বিশ্বাস করবেন না।

সমস্যা ২ — Wall-clock time বনাম CPU time

দুইটা সম্পূর্ণ ভিন্ন জিনিস, প্রায়ই গুলিয়ে ফেলা হয়:

• Wall-clock time — real, elapsed সময়। Dorওয়ালে ঝোলানো ঘড়ি যা দেখাবে, সেই সময়। এতে অন্তর্ভুক্ত: actual কাজ + I/O-এর জন্য block হয়ে থাকা সময় + scheduler অন্য প্রসেসকে সময় দেওয়ার সময়।
• CPU time — process-টা আসলে CPU-তে executing ছিল এমন সময়টুকু। user (application code) + sys (kernel-এ syscall চলাকালীন) সময়ের যোগফল। Block হয়ে থাকার সময় এখানে ধরা হয় না।

$ time ./download_and_process large_file.json
real    0m8.421s     ← wall-clock
user    0m0.312s     ← CPU time, application code
sys     0m0.089s     ← CPU time, kernel/syscall

এই উদাহরণটা লক্ষ্য করুন — real (৮.৪ সেকেন্ড) আর user+sys (মাত্র 0.4 সেকেন্ড)-এর মধ্যে বিশাল ফাঁক। কারণ প্রোগ্রামটা বেশিরভাগ সময় নেটওয়ার্ক থেকে file download হওয়ার জন্য অপেক্ষা করছিল — সেই সময় CPU সম্পূর্ণ idle বা অন্য কাজ করছিল, কিন্তু user-এর কাছে তা এখনো ৮.৪ সেকেন্ডের অপেক্ষা।

যদি আপনি এখানে শুধু CPU time রিপোর্ট করেন (“প্রোগ্রামটা মাত্র ০.৪ সেকেন্ডে চলে!”) — এটা কারিগরিভাবে সত্য কিন্তু user-এর বাস্তব অভিজ্ঞতাকে সম্পূর্ণ ভুলভাবে উপস্থাপন করে। যদি উল্টোটা করেন — একটা CPU-heavy, multi-threaded compute-এ শুধু wall-clock দেখান, তাহলে কতটা কাজ আসলে হলো তার হিসাব বিভ্রান্তিকর হয় (৮টা thread ১ সেকেন্ড wall-clock-এ চললে সেটা 8 সেকেন্ড CPU-time কাজ করেছে — দুইটা সংখ্যাই দরকার, ভিন্ন প্রশ্নের উত্তরের জন্য)।

সমস্যা ৩ — একটা run প্রমাণ করে না, distribution লাগে

একটা function ২০ বার চালিয়ে সময় মাপলে (warm-up-এর পর), বাস্তব ফলাফল সাধারণত এরকম দেখায়:

Run    Time (ms)
  1        11.8
  2        12.1
  3        11.9
  4        12.3
  5        12.0
  6        45.2   ← outlier (GC pause / OS interrupt)
  7        11.7
  8        12.2
  9        11.9
 10        12.4
 11        12.0
 12        38.7   ← outlier (background cron job কেড়ে নিলো CPU)
 13        11.8
 14        12.1
 15        11.9

Mean (গড়): 16.0 ms — দুইটা outlier-এর কারণে বাস্তবের চেয়ে ৩৩% বেশি দেখাচ্ছে।

Median (মধ্যক): 12.0 ms — বাকি ১৩টা “স্বাভাবিক” run-এর সাথে সঠিকভাবে মেলে, outlier-এর প্রভাব প্রায় শূন্য।

কেন median outlier-এর প্রতি resistant, mean না — mean প্রতিটা মানের সমষ্টি নেয়, তাই একটা চরম মান পুরো ফলাফল টেনে নিতে পারে। Median শুধু “মাঝের মান”-টা নেয় — কতগুলো মান কত চরম তা গুরুত্বপূর্ণ না, শুধু তাদের অবস্থান (rank) গুরুত্বপূর্ণ।

নিয়ম: বেঞ্চমার্কে সবসময় median রিপোর্ট করুন, mean নয় — যদি না আপনি নিশ্চিত হন যে distribution outlier-মুক্ত।

সমস্যা ৪ — Percentile: কেন শুধু median-ও যথেষ্ট না

উপরের একই dataset-এ median (12.0 ms) বলে “typical run ভালো।” কিন্তু এটা 38.7 আর 45.2 ms-এর মতো spike সম্পূর্ণভাবে আড়াল করে দেয়।

যদি এটা একটা web service-এর response time হতো, আর এই distribution-এর মতো প্রতি ১৫টা request-এর ২টা ~40ms-এ গিয়ে ঠেকতো (median-এর প্রায় ৩.৫ গুণ), তাহলে সেই ২/১৫ ≈ ১৩% user একটা লক্ষণীয়ভাবে ধীর অভিজ্ঞতা পাচ্ছেন — যা শুধু median দেখে সম্পূর্ণ অদৃশ্য।

Percentile এই তথ্যটা উদ্ধার করে:

$p_{95} = \text{সেই মান, যার নিচে } 95\% \text{ observation পড়ে}$

উপরের ১৫টা sample-এ (sorted): p95 (উপরের ৫%) outlier range-এর কাছাকাছি পড়বে (~39-45 ms), স্পষ্টভাবে দেখাবে “খারাপ ক্ষেত্রে” ব্যবহারকারীর অভিজ্ঞতা কেমন।

সমস্যা ৫ — System noise নিয়ন্ত্রণ

Run-to-run variance-এর একটা বড় অংশ আসে benchmark-এর বাইরের কারণ থেকে:

• প্রতিযোগী প্রসেস — অন্য কোনো process cache/core-এর জন্য প্রতিযোগিতা করলে আপনার benchmark-এর cache line evict হয়ে যেতে পারে, অথবা scheduler আপনার thread-কে সাময়িকভাবে সরিয়ে অন্য প্রসেসকে সময় দিতে পারে। প্রতিকার: benchmark চালানোর সময় অপ্রয়োজনীয় সব প্রসেস বন্ধ রাখুন, বা taskset/sched_setaffinity দিয়ে আপনার প্রসেসকে নির্দিষ্ট core-এ pin করুন, যাতে অন্তত সেই core-গুলো একচেটিয়া থাকে।
• Thermal throttling — দীর্ঘ, sustained heavy load ধাপে ধাপে CPU গরম করে, আর একটা নির্দিষ্ট তাপমাত্রার পরে hardware নিজে থেকেই clock speed কমিয়ে দেয় (thermal throttling) — চাহিদা না কমলেও। একটা দীর্ঘ benchmark-এ throughput সময়ের সাথে ধীরে ধীরে কমে যেতে পারে শুধু এই কারণে, algorithm-এর কোনো দোষ ছাড়াই। প্রতিকার: পুরো run জুড়ে CPU frequency/temperature monitor করুন (/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq বা turbostat), আর throttling ধরা পড়লে হয় cooldown period দিন, নয়তো ফলাফলে সেটা স্পষ্টভাবে উল্লেখ করুন।
• NUMA placement — NUMA লেসনে আমরা দেখেছি remote-node memory access local-এর চেয়ে ধীর। যদি benchmark thread একটা NUMA node-এর core-এ চলে কিন্তু তার memory ভিন্ন node-এ allocate হয়ে যায় (OS scheduler-এর এলোমেলো সিদ্ধান্তে), ফলাফল আসলে algorithm না, placement-এর দুর্ঘটনা মাপছে। প্রতিকার: numactl --cpunodebind=0 --membind=0 দিয়ে CPU আর memory একই node-এ pin করুন — অথবা, যদি cross-node আচরণই আপনার লক্ষ্য হয়, সেটা explicitly করুন আর স্পষ্টভাবে বলুন যে সেটাই মাপা হচ্ছে।

সমস্যা ৬ — Confidence interval: একটা সংখ্যার চেয়ে বেশি বলা

n টা measured run থেকে শুধু একটা median/mean রিপোর্ট করাও পুরো ছবি দেয় না — সেই সংখ্যাটার উপর কতটা আস্থা রাখা যায় তা বলে না।

Standard error থেকে একটা approximate 95% confidence interval:

$SE = \frac{s}{\sqrt{n}}, \qquad CI_{95\%} \approx \bar{x} \pm 1.96 \times SE$

যেখানে s = sample standard deviation, n = sample সংখ্যা, x̄ = sample mean।

উদাহরণ — দুইটা version তুলনা:

দুইটা interval overlap করে ([10.08, 10.42]) — অর্থাৎ, এই data দিয়ে আত্মবিশ্বাসের সাথে বলা যায় না যে A দ্রুত, যদিও A-এর sample mean সংখ্যাগতভাবে ছোট। পার্থক্যটা noise-এর মধ্যেই পড়ে যেতে পারে।

কত sample যথেষ্ট — statistical power-এর সংক্ষিপ্ত ধারণা

SE = stddev / sqrt(n) সমীকরণটা লক্ষ্য করুন — sample সংখ্যা (n) বাড়ালে SE কমে, কিন্তু √n-এর হারে, n-এর হারে না। এর একটা ব্যবহারিক তাৎপর্য আছে যা প্রায়ই ভুল বোঝা হয়।

CI-কে অর্ধেক ছোট করতে (দ্বিগুণ নির্ভুলতা পেতে), sample সংখ্যা দ্বিগুণ না, চারগুণ করতে হয়:

$\frac{SE_{new}}{SE_{old}} = \sqrt{\frac{n_{old}}{n_{new}}} = \frac{1}{2} \Rightarrow n_{new} = 4 \times n_{old}$

ব্যবহারিক ফলাফল — diminishing returns। 30 থেকে 120 run-এ যাওয়া CI অর্ধেক করে (ভালো বিনিয়োগ)। কিন্তু 120 থেকে 480-এ যেতে ৪ গুণ বেশি সময় ব্যয় করে একই অনুপাতে (আরেকবার অর্ধেক) উন্নতি পাওয়া যায়। একটা point-এর পর বেশি run চালানো সময়ের অপচয় — সেই সময়টা বরং আসল সমস্যা (noise-এর উৎস কমানো, যেমন CPU pinning) সমাধানে ব্যয় করা ভালো।

সমস্যা ৭ — Dead-code elimination: microbenchmark যা কিছুই মাপে না

এই লেসনের ভূমিকার গল্পটা এই সমস্যা থেকেই এসেছে, আর এটা সবচেয়ে বিপজ্জনক কারণ ফলাফল প্রায়ই বিশ্বাসযোগ্য দেখায় — শুধু ভুলভাবে দ্রুত।

// একটা "microbenchmark" — কিন্তু একটা মারাত্মক bug সহ
#include \<time.h>

int main(void) {
    double result = 0.0;
    struct timespec t0, t1;
    clock_gettime(CLOCK_MONOTONIC, &t0);

    for (long i = 0; i \< 100000000; i++) {
        result = result * 1.0000001 + 0.0000001;   // "কাজ"
    }

    clock_gettime(CLOCK_MONOTONIC, &t1);
    double dt = (t1.tv_sec - t0.tv_sec) + (t1.tv_nsec - t0.tv_nsec) / 1e9;
    printf("সময়: %f সেকেন্ড\n", dt);
    // লক্ষ্য করুন — `result` এখানে আর কোথাও ব্যবহৃত হয়নি!
    return 0;
}

gcc -O2 -o dce_bug dce_bug.c && ./dce_bug
সময়: 0.000000 সেকেন্ড

শূন্য সেকেন্ড। -O2 optimizer একটা সহজ observation করেছে: result-এর চূড়ান্ত মান কোথাও পড়া হচ্ছে না, print হচ্ছে না, কোনো global-এ যাচ্ছে না — অর্থাৎ পুরো for loop-টার কোনো observable প্রভাব নেই প্রোগ্রামের বাকি অংশে। যেহেতু compiler প্রমাণ করতে পারে loop-টা মুছে দিলেও প্রোগ্রামের আচরণ (as observed) অভিন্ন থাকবে, C standard-এর “as-if rule” অনুযায়ী পুরো loop-টা সম্পূর্ণ মুছে ফেলা সম্পূর্ণ বৈধ — আর compiler ঠিক তাই করে।

ফলাফল: আপনি ভেবেছিলেন 10⁸ টা FMA operation মাপছেন। আসলে মেপেছেন “কিছুই না করার সময়”।

আপনি লিখেছেন:          compiler as-if rule প্রয়োগ করার পর:
┌─────────────────┐    ┌─────────────────┐
│ for (...) {      │    │                  │
│   result = ...   │ →  │  (কিছুই নেই —    │
│ }                 │    │   loop মুছে গেছে)│
│ // result unused  │    │                  │
└─────────────────┘    └─────────────────┘
      "১০ কোটি iteration"      "০ instruction"

প্রতিকার — compiler-কে বলুন ফলাফলটা “escape” করতে পারে বলে ধরে নিতে (black_box / opaque-use)।

Rust-এ, standard, portable উপায়:

use std::hint::black_box;

let mut result = 0.0_f64;
for _ in 0..100_000_000 {
    result = black_box(result) * 1.0000001 + 0.0000001;
}
black_box(result);   // চূড়ান্ত মানও escape করাতে হবে

black_box একটা identity function — যা পায় তাই ফেরত দেয় — কিন্তু compiler-কে এর ভেতরটা দেখতে দেয় না। ফলে compiler ধরে নিতে বাধ্য হয় এই মানটা সত্যিই কোথাও ব্যবহৃত হতে পারে, তাই পুরো computation মুছে ফেলা যাবে না। ভেতরে বাস্তবে কোনো real instruction যোগ হয় না (শুধু একটা compiler-level optimization barrier) — তাই measured সময়ে প্রায় শূন্য অতিরিক্ত খরচ যোগ হয়।

C/C++-এ সমতুল্য কৌশল (কোনো official standard library helper না থাকায় hand-rolled trick লাগে):

// একটা inline-asm compiler barrier — "escape hatch"
static inline void do_not_optimize(double x) {
    asm volatile("" : : "r"(x) : "memory");
}

int main(void) {
    double result = 0.0;
    for (long i = 0; i \< 100000000; i++) {
        result = result * 1.0000001 + 0.0000001;
        // (চাইলে loop-এর বাইরে একবারও যথেষ্ট, নিচে দেখুন)
    }
    do_not_optimize(result);   // compiler এখন এটা মুছতে পারবে না
    return 0;
}

gcc -O2 -o dce_fixed dce_fixed.c && ./dce_fixed
# এখন সময় বাস্তবসম্মত — শূন্য নয়

C++-এ Google Benchmark library এই একই কৌশল একটা পোর্টেবল, প্রস্তুত ফাংশনে মুড়ে দিয়েছে: benchmark::DoNotOptimize(result) আর benchmark::ClobberMemory()।