NumPy-র গতি — memory, dtype, view আর কখন loop-ই ঠিক

মডিউল ৩-এর আগের পর্বগুলোতে NumPy-র array, indexing, vectorization আর broadcasting দেখেছেন (পর্ব ১৩ থেকে পর্ব ১৮)। সেখানে মূল কথা ছিল: Python-এর loop-এর বদলে পুরো array-এর ওপর একবারে কাজ চালালে কোড অনেক দ্রুত হয়। পর্ব ৯-এ এক run-এ সেই পার্থক্য প্রায় ৫০ গুণ দেখেছিলেন। কিন্তু বাস্তবে দুটি NumPy কোড, দেখতে প্রায় এক, গতিতে দশ গুণ আলাদা হতে পারে। কেউ ১৬ GB RAM-এর ল্যাপটপে “MemoryError” পান, অথচ ডেটা মাত্র ৩ GB. এই পর্ব সেই রহস্যগুলোর: মেমরিতে array কীভাবে বসে, dtype কী বদলায়, কোথায় লুকিয়ে নতুন array তৈরি হয়, আর কখন loop-ই সবচেয়ে সৎ সমাধান। গতির সাধারণ নিয়ম (Big-O, profiling-এর মূল ধারণা) আছে Python কোর্সের পারফরম্যান্স পর্বে; এখানে শুধু NumPy-র দিকটি।

১ · ঠিকভাবে মাপা — perf_counter, timeit, warm-up আর median

বাসা থেকে অফিসে রিকশায় কত সময় লাগে? একদিন মেপে “১৮ মিনিট” বললে ভুল হতে পারে: সেদিন হয়তো হরতাল ছিল, রাস্তা ফাঁকা। আরেকদিন জ্যামে ৪০ মিনিট। ঠিক উত্তর পেতে কয়েক দিন মাপতে হয়, আর মাঝের মানটি (median) নিতে হয়, যাতে একদিনের অস্বাভাবিক জ্যাম পুরো হিসাব নষ্ট না করে। কোডের সময় মাপাও ঠিক তেমন। একই কোড একই যন্ত্রে দুবার চালালে সময় আলাদা আসে, কারণ পেছনে অন্য program চলে, CPU-র গতি তাপমাত্রা আর বিদ্যুৎ-সাশ্রয়ের নিয়মে ওঠানামা করে, আর প্রথমবার চালানোর খরচ বাকিগুলোর চেয়ে আলাদা।

নির্ভরযোগ্য মাপজোকের (benchmark) চারটি নিয়ম:

1. সঠিক ঘড়ি: time.perf_counter(), যা ছোট সময় মাপার জন্য সবচেয়ে সূক্ষ্ম ঘড়ি। time.time() দেয়ালের ঘড়ি; যন্ত্রের সময় ঠিক করা হলে সেটি লাফাতে পারে।
2. Warm-up: প্রথম run প্রায়ই ধীর। Module import, মেমরি প্রথমবার ছোঁয়া, Numba-র মতো টুলের compile, সব খরচ প্রথমবারেই পড়ে। প্রথম run বাদ দিন, অথবা আলাদা করে লিখুন।
3. কয়েকবার, তারপর median বা min: ৫–৭ বার চালিয়ে median দিন। Python-এর timeit-এর অফিসিয়াল নথি আবার min-কে বেশি গুরুত্ব দেয়, কারণ বেশি সময়গুলো সাধারণত অন্য program-এর হস্তক্ষেপ। Median বলে “সাধারণত কত”, min বলে “সবচেয়ে ভালো অবস্থায় কত”। দুটিই বৈধ; কোনটি দিচ্ছেন, সেটি লিখে দিন।
4. একই input, একই ফল: দুটি সংস্করণ একই ডেটায় চালান, আর ফল সমান কি না np.allclose বা np.array_equal দিয়ে মিলিয়ে নিন। দ্রুত কিন্তু ভুল কোড দ্রুত নয়, ভুল।

Python-এর সঙ্গে আসা timeit এই কাজগুলো নিজেই করে: কোডটি অনেকবার চালায়, কয়েক দফায় ভাগ করে। Terminal থেকে লেখকের ল্যাপটপে একটি সত্যিকারের run (Python 3.14.4, NumPy 2.5.4):

~/bazarghar-ai$ python -m timeit -s "import numpy as np; a = np.random.default_rng(42).random(1_000_000)" "a.sum()"
1000 loops, best of 5: 227 usec per loop

-s-এর অংশ (setup) একবার চলে, সময়ে ধরা হয় না; মূল কোড ১০০০ বার করে পাঁচ দফা চলেছে, আর সেরা দফার গড় দেখানো হয়েছে: ১০ লাখ float-এর যোগ প্রায় ০.২৩ মিলিসেকেন্ডে। Jupyter-এ একই কাজ করে %timeit a.sum(), যা পর্ব ৮-এর line magic; সেটি গড় ± standard deviation দেখায়। এই পাতায় প্রতিটি মাপ time.perf_counter দিয়ে, কারণ ব্রাউজারের Python-এ ছোট আর স্পষ্ট কোডই সবচেয়ে ভালো শেখায়।

২ · মেমরিতে array কীভাবে বসে — C order, Fortran order আর strides

কম্পিউটারের মেমরি একটি লম্বা সারির ঘর, প্রতিটির একটি ঠিকানা, যেন একটি রেলগাড়ির বগির সারি। সেখানে “সারি আর কলাম” বলে কিছু নেই। তাহলে একটি দুই-মাত্রার (2D) array সেখানে বসে কীভাবে? উত্তর: তাকে একটি লম্বা ফিতায় খুলে রাখতে হয়। খোলার দুটি প্রচলিত পথ। একটিতে প্রথম সারির সব ঘর, তারপর দ্বিতীয় সারির সব: একে বলে row-major বা C order, কারণ C ভাষা এভাবে রাখে, আর NumPy-র default এটিই। অন্যটিতে প্রথম কলামের সব ঘর, তারপর দ্বিতীয় কলামের: column-major বা Fortran order, কারণ Fortran (আর MATLAB, R) এভাবে রাখে। এই বিন্যাসকে বলে memory layout.

NumPy কীভাবে জানে কোন ঘর কোথায়? প্রতিটি array-এর সঙ্গে থাকে strides: প্রতিটি মাত্রায় এক ধাপ এগোতে কত byte লাফাতে হবে। ছবির C-order array-এ a.strides == (32, 8): পরের সারিতে যেতে ৩২ byte (৪টি ঘর × ৮ byte), পরের কলামে যেতে ৮ byte. তাই ঘর a[i, j]-এর ঠিকানা হলো শুরুর ঠিকানা থেকে

offset = i × strides[0] + j × strides[1] = 32·i + 8·j

যেমন a[2, 1]: 32·2 + 8·1 = 72 byte দূরে, মানে ফিতার দশম ঘর (৭২ / ৮ = ৯, শূন্য থেকে গুনলে), যার মান 9. নিচের ধাপে একটি সারি আর একটি কলাম ধরে হেঁটে দেখুন, কোথায় লাফ ছোট, কোথায় বড়।

1a = np.arange(12, dtype=np.int64).reshape(3, 4)2a.strides                  # (32, 8)3row = a[1, :]              # strides (8,)4col = a[:, 2]              # strides (32,)5big[:, j] on 6000 x 6000   # strides (48000,)

দুটি শব্দ পরিষ্কার করে নিই। যে array-এর সব ঘর মেমরিতে কোনো ফাঁক ছাড়াই পাশাপাশি, সে contiguous. NumPy এটি জানায় flags দিয়ে: a.flags.c_contiguous (C order-এ টানা) আর a.flags.f_contiguous (Fortran order-এ টানা)। একটি C-order array-এর transpose a.T নতুন কোনো মেমরি নেয় না; NumPy শুধু strides উল্টে দেয়, (8, 32), ফলে a.T হয়ে যায় F-contiguous. আর a[:, 2] বা a[:, ::2] হলো non-contiguous: মাঝে ফাঁক রেখে ঘর বাছা। এগুলো view, অর্থাৎ মূল array-এর মেমরির দিকেই তাকানো (পর্ব ১৪-এ দেখেছেন), কিন্তু হাঁটতে বেশি লাফাতে হয়।

৩ · সারি বনাম কলাম — cache আর বড় array-তে লাফানোর দাম

মুদি দোকানদার গুদাম থেকে একটি চালের বস্তা আনতে গেলে একসঙ্গে পাশের কয়েকটি বস্তাও নিয়ে আসেন, কারণ যাওয়া-আসাতেই আসল সময় যায়। CPU-ও এমন করে। মূল মেমরি (RAM) CPU-র তুলনায় অনেক ধীর, তাই CPU-র গায়ে ছোট আর খুব দ্রুত একটি মেমরি থাকে, যার নাম cache. RAM থেকে কিছু আনতে হলে CPU একটি ঘর নয়, একটি পুরো টুকরো আনে, যাকে বলে cache line; আজকের বেশির ভাগ x86 আর অনেক ARM প্রসেসরে এটি ৬৪ byte. পরের দরকারি ঘর যদি সেই টুকরোতেই থাকে, সেটি প্রায় বিনা খরচে মেলে। Cache কীভাবে কাজ করে, তার পুরো গল্প আছে Computer Architecture কোর্সের cache-এর মূল কথা আর cache-সচেতন প্রোগ্রামিং পর্বে।

তাই C-order array-তে সারি ধরে হাঁটা মানে একটি টুকরো আনলেই আটটি float64 পাওয়া। কলাম ধরে হাঁটা মানে প্রতিটি সংখ্যার জন্য নতুন টুকরো। ছোট array পুরোটাই cache-এ এঁটে যায়, তখন পার্থক্য প্রায় চোখে পড়ে না। বড় array-তে পড়ে। লেখকের ল্যাপটপে একটি ৬০০০ × ৬০০০ float64 array (২৮৮ MB) নিয়ে সত্যিকারের run (Python 3.14.4, NumPy 2.5.4, প্রতিটি সারিতে warm-up-এর পর ৭ বারের median):

~/bazarghar-ai$ python layout_bench.py
Python 3.14.4 | NumPy 2.5.4
shape (6000, 6000) dtype float64 MB 288.0
strides (48000, 8) C? True F? False
row slices   median     22.9 ms  (min    22.1, max    29.0)
col slices   median    215.8 ms  (min   214.0, max   223.8)
sum(axis=1)  median     19.1 ms  (min    18.9, max    26.4)
sum(axis=0)  median     14.1 ms  (min    13.5, max    14.8)
F copy strides (8, 48000) C? False F? True
F col slices median     22.1 ms
same totals: True True

প্রথম দুটি লাইন হুবহু একই কাজ: ৬০০০টি টুকরোর প্রতিটির যোগফল, Python-এর একটি loop দিয়ে। a[i, :].sum() (সারি) প্রায় ২৩ ms, a[:, j].sum() (কলাম) প্রায় ২১৬ ms, মানে এই run-এ প্রায় ৯ গুণ ধীর। একই array-কে np.asfortranarray দিয়ে Fortran order-এ কপি করলে কলামই হয়ে যায় টানা, আর কলাম-loop নেমে আসে প্রায় ২২ ms-এ। অর্থাৎ ধীরতার কারণ “কলাম” নয়, “মেমরিতে লাফানো”।

কিন্তু তৃতীয় আর চতুর্থ লাইন একটি গুরুত্বপূর্ণ সূক্ষ্মতা দেখায়। NumPy-কে পুরো কাজটি একবারে দিলে (a.sum(axis=0), প্রতিটি কলামের যোগফল) সে নিজেই বুদ্ধি খাটায়: কলাম ধরে না হেঁটে সারির পর সারি টানা পড়ে, আর ৬০০০টি চলমান যোগফল একসঙ্গে বাড়ায়। তাই এখানে axis=0 মোটেই ধীর নয়, এই run-এ বরং একটু দ্রুত। শিক্ষাটি তাই দুই ভাগে: (১) নিজের loop-এ বড় array-এর টুকরো হাঁটতে হলে মেমরির ক্রম মেনে হাঁটুন; (২) সম্ভব হলে পুরো কাজটি NumPy-কে একবারে দিন, কারণ সে মেমরির ক্রম আপনার চেয়ে ভালো জানে।

এবার ব্রাউজারে একটি মাঝারি (২০০০ × ২০০০, ৩২ MB) array নিয়ে একই পরীক্ষা চালিয়ে দেখুন। প্রথমবার চালালে NumPy নামাতে কয়েক সেকেন্ড লাগতে পারে।

import time
import numpy as np

a = np.random.default_rng(42).random((2000, 2000))   # C order, float64
print("a strides:", a.strides, "| C:", a.flags.c_contiguous,
      "F:", a.flags.f_contiguous)
print("a[:, 0] strides:", a[:, 0].strides, "| C:", a[:, 0].flags.c_contiguous)
print("a.T strides:", a.T.strides, "| F:", a.T.flags.f_contiguous)

def rows():
    return [a[i, :].sum() for i in range(a.shape[0])]

def cols():
    return [a[:, j].sum() for j in range(a.shape[1])]

def median_ms(f, repeat=5):
    f()                                   # warm-up: প্রথম run বাদ
    times = []
    for _ in range(repeat):
        t0 = time.perf_counter()
        f()
        times.append(time.perf_counter() - t0)
    times.sort()
    return times[len(times) // 2] * 1000  # মাঝের মান

r, c = median_ms(rows), median_ms(cols)
print(f"সারি ধরে : {r:6.1f} ms")
print(f"কলাম ধরে: {c:6.1f} ms  (প্রায় {c / r:.1f} গুণ)")
print("ফল এক?", np.allclose(rows(), a.sum(axis=1)),
      np.allclose(cols(), a.sum(axis=0)))

a strides: (16000, 8) | C: True F: False
a[:, 0] strides: (16000,) | C: False
a.T strides: (8, 16000) | F: True
সারি ধরে :    5.6 ms
কলাম ধরে:   18.2 ms  (প্রায় 3.2 গুণ)
ফল এক? True True

৪ · dtype বাছাই — float32 বনাম float64, আর integer overflow

প্রতিটি NumPy array-এর একটি dtype থাকে: প্রতিটি ঘরে কোন ধরনের সংখ্যা, কত byte-এ। float64 (Python-এর সাধারণ float-এর সমান) প্রতি সংখ্যায় ৮ byte নেয় আর প্রায় ১৫–১৬টি দশমিক অঙ্ক পর্যন্ত নির্ভুল। float32 নেয় ৪ byte, নির্ভুলতা প্রায় ৭টি অঙ্ক। ফিতা যত সরু, একই cache line-এ তত বেশি সংখ্যা ধরে, আর RAM থেকে তত কম আনতে হয়। লেখকের ল্যাপটপে ২ কোটি সংখ্যা নিয়ে একটি সত্যিকারের run (warm-up-এর পর ৭ বারের median):

~/bazarghar-ai$ python dtype_bench.py
MB float64 160.0 | float32 80.0
sum f64    median    10.1 ms
sum f32    median     6.4 ms
x*2+1 f64  median    91.7 ms
x*2+1 f32  median    45.3 ms

মেমরি ঠিক অর্ধেক, আর এই run-এ x * 2 + 1 প্রায় দ্বিগুণ দ্রুত। এমন হিসাবে CPU-র গণনা নয়, মেমরি আনা-নেওয়াই আসল বাধা, তাই অর্ধেক byte মানে প্রায় অর্ধেক সময়। Deep learning-এ এ কারণেই float32 (আর আরও ছোট float16 বা bfloat16) প্রচলিত; ছবির pixel বা মডেলের weight-এর জন্য ৭ অঙ্কই যথেষ্ট। কিন্তু দাম আছে: ভুল জমে। ধাপে ধাপে দেখুন, float32-এ বারবার 0.1 যোগ করলে কী হয়।

1s = np.float32(0)2for k in range(n):3    s = s + np.float32(0.1)

শেষ ধাপের পার্থক্যটি NumPy-র অফিসিয়াল নথিতেও লেখা: float-এর np.sum অনেক ক্ষেত্রে pairwise summation ব্যবহার করে (বিশেষত axis না দিলে), যা একটির পর একটি যোগের চেয়ে অনেক কম ভুল জমায়। কিন্তু np.cumsum-এর মতো চলমান যোগ, বা নিজের লেখা loop, সেই সুবিধা পায় না। এখন integer-এর দিক। Python-এর int যত বড় চান হয়; NumPy-র integer হয় না। int32-এর সীমা 2,147,483,647, তার বেশি হলে ফল চুপচাপ ঘুরে ঋণাত্মক হয়ে যায়, যাকে বলে integer overflow. Array-এর হিসাবে NumPy এর জন্য কোনো error বা সতর্কবার্তা দেয় না। নিচের কোডে দুটি ফাঁদই দেখুন।

import numpy as np

v32 = np.full(1_000_000, 0.1, dtype=np.float32)
v64 = np.full(1_000_000, 0.1)                     # float64
print("মেমরি:", v32.nbytes, "বনাম", v64.nbytes, "bytes")
print("float32-এ 0.1 আসলে:", f"{float(np.float32(0.1)):.12f}")

run32 = np.cumsum(v32)            # একটির পর একটি যোগ, float32-এ
print("cumsum float32 :", run32[-1])
print("np.sum float32 :", v32.sum())              # pairwise যোগ
print("np.sum float64 :", v64.sum())
print("আসল মান        : 100000")
print("2**21 + 0.1    :", np.float32(2**21) + np.float32(0.1))

qty = np.array([40_000, 50_000], dtype=np.int32)
print("int32 বর্গ:", qty * qty)                    # চুপচাপ উপচে পড়ে
print("int64 বর্গ:", qty.astype(np.int64) ** 2)
print("int32 সীমা:", np.iinfo(np.int32).max)
u = np.array([250, 10], dtype=np.uint8)
print("uint8 + 10:", u + np.uint8(10))            # 260 → 4

মেমরি: 4000000 বনাম 8000000 bytes
float32-এ 0.1 আসলে: 0.100000001490
cumsum float32 : 100958.34
np.sum float32 : 100000.01
np.sum float64 : 100000.00000000003
আসল মান        : 100000
2**21 + 0.1    : 2.097152e+06
int32 বর্গ: [ 1600000000 -1794967296]
int64 বর্গ: [1600000000 2500000000]
int32 সীমা: 2147483647
uint8 + 10: [ 4 20]

৫ · অস্থায়ী array এড়ানো — in-place, out= আর মেমরির হিসাব

রান্নাঘরে প্রতিটি ধাপের জন্য নতুন বাটি নিলে শেষে একগাদা বাটি ধুতে হয়, আর তাকে জায়গাও লাগে। NumPy-র expression-ও প্রতিটি ধাপে নতুন “বাটি” নেয়। c = a * 2 + b লিখলে NumPy আগে a * 2 হিসাব করে একটি নতুন array-এ রাখে, তারপর তার সঙ্গে b যোগ করে আরেকটি নতুন array বানায়, যা c হয়। মাঝের array-টির কোনো নাম নেই, কাজ শেষে ফেলে দেওয়া হয়; একে বলে temporary array. ছোট array-এ এটি নগণ্য। ১০ কোটি সংখ্যার array-এ প্রতিটি temporary ৮০০ MB.

সমাধান in-place operation: নতুন array না বানিয়ে আগের array-এর ঘরেই ফল লেখা। c += b হলো np.add(c, b, out=c), আর প্রতিটি ufunc (NumPy-র ঘরে ঘরে চলা function, যেমন np.add, np.multiply, np.sqrt) out= নিয়ে ঠিক করে দেওয়া array-এ ফল রাখতে পারে। ধাপে ধাপে মেমরির হিসাব দেখুন, ১০ লাখ float64-এর array ধরে (প্রতিটি ৮ MB).

1c = a * 2 + b          # সাধারণ লেখা2c = np.multiply(a, 2)  # একটিই নতুন buffer3c += b                 # সেখানেই যোগ4np.multiply(a, 2, out=buf); np.add(buf, b, out=buf)

এই হিসাব শুধু মনে মনে নয়, মাপা যায়। Python-এর tracemalloc module মেমরি বরাদ্দ গোনে, আর NumPy তার array-এর মেমরি tracemalloc-কে জানায়। নিচের কোড তিনটি পথের চূড়া মাপে; nbytes দিয়ে আগেই অনুমান করুন: প্রতিটি array ৮ MB হলে উত্তর কত হওয়া উচিত?

import tracemalloc
import numpy as np

n = 1_000_000
rng = np.random.default_rng(42)
a, b = rng.random(n), rng.random(n)
print("একটি array:", a.nbytes / 1e6, "MB")

def peak_mb(f):
    tracemalloc.start()
    f()
    peak = tracemalloc.get_traced_memory()[1]
    tracemalloc.stop()
    return peak / 1e6

def out_of_place():
    return a * 2 + b                 # a*2 একটি temporary, তারপর নতুন ফল

def one_buffer():
    c = np.multiply(a, 2)            # একটিই নতুন array
    c += b                           # সেখানেই in-place যোগ
    return c

buf = np.empty_like(a)               # আগে থেকে বানানো buffer
def reuse_out():
    np.multiply(a, 2, out=buf)
    np.add(buf, b, out=buf)
    return buf

for f in (out_of_place, one_buffer, reuse_out):
    print(f"{f.__name__:13s} peak {peak_mb(f):5.1f} MB")
print("ফল এক?", np.array_equal(out_of_place(), reuse_out()))

একটি array: 8.0 MB
out_of_place  peak  16.0 MB
one_buffer    peak   8.0 MB
reuse_out     peak   0.0 MB
ফল এক? True

লেখকের ল্যাপটপে ৫০ লাখ সংখ্যা (প্রতিটি array ৪০ MB) নিয়ে একই মাপ দিয়েছিল চূড়া ৮০ MB বনাম ৪০ MB বনাম প্রায় শূন্য, আর সময়ে a * 2 + b প্রায় ২৩.৫ ms, আগে বানানো buffer-এ out= দিয়ে প্রায় ৬.৬ ms (warm-up-এর পর ৭ বারের median, একটি run). নতুন মেমরি চাওয়া আর প্রথমবার ছোঁয়ারও খরচ আছে, তাই in-place শুধু মেমরিই নয়, প্রায়ই সময়ও বাঁচায়।

৬ · View আর copy — গতির চোখে আবার

পর্ব ১৪-এ দেখেছেন, slicing (a[10:20], a[:, ::2]) একটি view দেয়, যা নতুন মেমরি না নিয়ে শুধু নতুন শুরু-ঠিকানা আর strides দিয়ে মূল array-এর দিকে তাকায়; আর boolean mask বা fancy index (a[[3, 7, 9]]) সবসময় একটি copy দেয়। গতির দিক থেকে এর মানে সোজা: view তৈরি প্রায় বিনা খরচে, array যত বড়ই হোক; copy-র খরচ তার আকারের সমানুপাতিক। কয়েকটি জায়গা যেখানে লুকিয়ে copy হয়:

• reshape আর ravel: contiguous array-এ এরা view দেয়। কিন্তু non-contiguous array-এ (যেমন a.T বা a[:, ::2]) নতুন আকারটি strides দিয়ে বোঝানো না গেলে NumPy চুপচাপ copy বানায়। flatten সবসময় copy.
• np.ascontiguousarray(x): x আগেই C-contiguous হলে সেটিই ফেরত দেয়, না হলে copy. অনেক library (BLAS, C extension, কিছু scikit-learn অংশ) টানা array চায়, আর না পেলে নিজেরাই copy করে নেয়। একবার নিজে বানিয়ে বারবার ব্যবহার করলে বারবারের copy বাঁচে।
• dtype বদলানো: x.astype(np.float32) সবসময় নতুন array (dtype একই হলেও, যদি না copy=False দেন)।
• যাচাই: np.shares_memory(a, b) বলে দুটি array একই মেমরি ভাগ করছে কি না; b.base is a বলে b সরাসরি a-এর view কি না।

উল্টো দিকের ফাঁদও আছে। একটি বিশাল array থেকে ছোট একটি slice রেখে বাকিটা ফেলে দিতে চাইলে, slice-টি view হওয়ায় পুরো মূল array মেমরিতে আটকে থাকে। ৮০০ MB array থেকে ১০টি সারি রাখতে চাইলে small = big[:10].copy() লিখুন, তারপর del big; তখনই ৮০০ MB মুক্ত হয়।

৭ · কখন loop-ই ঠিক — cumsum-এর কৌশল, Numba আর Cython

“NumPy-তে loop লিখবেন না” কথাটি অর্ধেক সত্য। তিন রকম ক্ষেত্রে সাধারণ Python loop পুরোপুরি ঠিক, কখনো সবচেয়ে ভালো:

• ছোট ডেটা: ২০টি জেলা বা ৫০টি পণ্যের ওপর loop কয়েক মাইক্রোসেকেন্ডের কাজ। Vectorize করে লাভ নেই, পড়তে কঠিন হয়। আর প্রতিটি NumPy call-এর নিজের একটি স্থির খরচ আছে, তাই খুব ছোট array-এ সাধারণ Python প্রায়ই দ্রুত।
• আগেভাগে থামা (early exit): “প্রথম যে অর্ডারটি ১০,০০০ টাকা ছাড়ায়” খুঁজতে loop প্রথম মিলেই থামে। np.argmax(x > 10000) পুরো array পরীক্ষা করে, কারণ আগে সম্পূর্ণ boolean array বানায়। মিল যদি সাধারণত শুরুর দিকে থাকে, loop জিততে পারে।
• ধারাবাহিক নির্ভরতা: আজকের মান যদি গতকালের ফলের ওপর নির্ভর করে, আর সেই নির্ভরতায় একটি সিদ্ধান্ত থাকে, তাহলে সব ঘর একসঙ্গে হিসাব করা যায় না।

শেষেরটির একটি বাস্তব উদাহরণ নেওয়া যাক। বাজারঘরের গুদামে একটি পণ্যের স্টক ১০০; প্রতিদিন কিছু বিক্রি হয়। দুই রকম নিয়ম ভাবুন। (ক) প্রতি ৭ দিনে নির্দিষ্ট দিনে নতুন চালান আসে আর স্টক আবার ১০০ হয়। রিসেটের দিনগুলো আগে থেকেই জানা। (খ) স্টক ২০-এর নিচে নামলেই সঙ্গে সঙ্গে ১০০-তে ভরা হয়। এখানে কবে রিসেট হবে, তা নির্ভর করে আগের দিনের স্টকের ওপর।

(ক)-কে vectorize করা যায়, যদিও প্রথম দেখায় ধারাবাহিক মনে হয়। চাবি হলো cumulative sum: np.cumsum(sales) শুরু থেকে প্রতিটি দিন পর্যন্ত মোট বিক্রি দেয়। প্রতিটি অংশের (দুই চালানের মাঝের দিনগুলো) বিক্রি বের করতে মোট থেকে অংশ শুরুর আগের মোট বাদ দিলেই হয়। আর “আমার অংশ কোন দিন শুরু হয়েছিল” বের করে np.maximum.accumulate: এটি চলমান সর্বোচ্চ, cumsum-এর ভাই। প্রতিটি ufunc-এর .accumulate আছে (np.add.accumulate হলো cumsum, np.multiply.accumulate হলো cumprod). (খ)-তে এমন কোনো কৌশল নেই, কারণ রিসেট ঘটবে কি না তা জানতে হলে আগে আগের দিনের ফল জানতে হবে।

import time
import numpy as np
rng = np.random.default_rng(42)
days = 1_000_000
sales = rng.integers(0, 15, size=days)
restock = np.arange(days) % 7 == 0        # প্রতি ৭ দিনে চালান: স্টক আবার 100

def stock_loop(sales, restock):           # ক) রিসেটের দিন আগেই জানা
    out, s = [], 100
    for x, r in zip(sales.tolist(), restock.tolist()):
        if r:
            s = 100
        s -= x
        out.append(s)
    return np.array(out)
def stock_vec(sales, restock):            # একই কাজ cumsum দিয়ে
    c = np.cumsum(sales)
    start = np.maximum.accumulate(np.where(restock, np.arange(sales.size), 0))
    before = np.where(start > 0, c[start - 1], 0)   # অংশ শুরুর আগের জমা
    return 100 - (c - before)
def stock_threshold(sales, low=20):       # খ) রিসেট নির্ভর করে আগের মানের ওপর
    out, s = [], 100
    for x in sales.tolist():
        s -= x
        if s < low:                       # সিদ্ধান্তের জন্য আগের s লাগবেই
            s = 100
        out.append(s)
    return out
t0 = time.perf_counter(); s1 = stock_loop(sales, restock)
t1 = time.perf_counter(); s2 = stock_vec(sales, restock)
t2 = time.perf_counter(); s3 = stock_threshold(sales); t3 = time.perf_counter()
print("ক) ফল এক?", np.array_equal(s1, s2), s1[:9])
print(f"   loop {(t1 - t0) * 1000:.1f} ms | cumsum {(t2 - t1) * 1000:.1f} ms")
print("খ) threshold:", s3[:9], f"{(t3 - t2) * 1000:.1f} ms")

ক) ফল এক? True [99 88 79 73 67 55 54 90 87]
   loop 104.7 ms | cumsum 23.5 ms
খ) threshold: [99, 88, 79, 73, 67, 55, 54, 44, 41] 36.4 ms

যখন vectorize করা যায় না — Numba আর Cython

(খ)-এর মতো কাজ দশ লাখ নয়, দশ কোটি দিনের হলে Python loop-এর খরচ সত্যিই গায়ে লাগে। তখন একটি পথ Numba: একটি library, যা একটি Python function-কে প্রথম call-এর সময় যন্ত্রের নিজের কোডে (machine code) অনুবাদ করে, LLVM নামের compiler কাঠামো দিয়ে। একে বলে JIT compilation (just-in-time, চালানোর মুহূর্তে compile). Function-এর ওপরে @njit বসালেই হয়, যদি function-টি Numba-র বোঝা অংশের মধ্যে থাকে: সংখ্যা, NumPy array, সাধারণ loop আর শর্ত। লেখকের ল্যাপটপে ২০ লাখ দিনের threshold-নিয়ম নিয়ে একটি সত্যিকারের run (লেখার সময়ে numba 0.68.1, NumPy 2.5.4, Python 3.14.4; Python loop-এ ৩ বারের, Numba-য় ৫ বারের median):

~/bazarghar-ai$ python loops_numba.py
numba 0.68.1 | NumPy 2.5.4
numba first call (compile+run) 541 ms
numba later calls median       4.51 ms
python loop median             261 ms
same result: True [99 88 79 73 67 55]

প্রথম call-এ ৫৪১ ms, যার প্রায় সবটাই compile; এটিই warm-up-এর সবচেয়ে স্পষ্ট উদাহরণ। পরের call-গুলো প্রায় ৪.৫ ms, Python loop-এর চেয়ে এই run-এ প্রায় ৫৮ গুণ দ্রুত, আর ফল হুবহু এক। কিন্তু দাম আছে: Numba একটি বাড়তি dependency, নতুন Python version এলে কিছুদিন পিছিয়ে থাকতে পারে, সব Python জিনিস (dict-ভরা object, pandas DataFrame) বোঝে না, আর error-এর বার্তা কঠিন। এটি এই পাতার ব্রাউজারের Python-এ নেই, তাই এখানে চালানো যাবে না। আরেকটি প্রতিষ্ঠিত পথ Cython: Python-এর মতো দেখতে একটি ভাষা, যাতে type লিখে দিলে আগেভাগেই C-তে অনুবাদ করে compile করা যায়। NumPy, SciPy আর scikit-learn-এর অনেক অংশ এভাবে লেখা। এটি একটি build ধাপ চায়, তাই সাধারণত library লেখকদের হাতিয়ার; এই পর্বে শুধু নামটি জেনে রাখুন।

৮ · ধীর জায়গা খুঁজে বের করা — cProfile, আর memmap-এর কথা

ডাক্তার পুরো শরীরের অপারেশন করেন না; আগে পরীক্ষা করে দেখেন সমস্যা কোথায়। ধীর কোডেও আগে profiling: প্রোগ্রাম চালিয়ে মাপা, কোন function কতবার ডাকা হলো আর কত সময় নিল। প্রায়ই দেখা যায়, পুরো সময়ের বেশির ভাগ যাচ্ছে এক-দুটি জায়গায়, আর অন্য জায়গা নিখুঁত করে কোনো লাভ নেই। Python-এর সঙ্গে আসে cProfile. বাজারঘরের ২ লাখ অর্ডার থেকে ৬৪টি জেলার গড় বের করার একটি ধীর function নিয়ে লেখকের ল্যাপটপে একটি সত্যিকারের run:

def to_taka(p):
    return round(p / 100, 2)

def district_means_slow(district, paisa):
    out = {}
    for d in range(64):
        vals = [to_taka(p) for p, dd in zip(paisa, district) if dd == d]
        out[d] = sum(vals) / len(vals)
    return out

~/bazarghar-ai$ python profile_it.py
         400130 function calls in 1.515 seconds

   Ordered by: internal time
   List reduced from 6 to 5 due to restriction <5>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    1.029    1.029    1.515    1.515 slow_report.py:11(district_means_slow)
   200000    0.441    0.000    0.441    0.000 {built-in method builtins.round}
   200000    0.040    0.000    0.481    0.000 slow_report.py:8(to_taka)
       64    0.005    0.000    0.005    0.000 {built-in method builtins.sum}
       64    0.000    0.000    0.000    0.000 {built-in method builtins.len}

slow 1450 ms | fast 0.82 ms (no profiler)

পড়ার নিয়ম: ncalls কতবার ডাকা হলো, tottime শুধু ওই function-এর নিজের ভেতরের সময়, cumtime তার ভেতর থেকে ডাকা সবকিছুসহ। তিনটি জিনিস বেরিয়ে আসে। (১) district_means_slow-এর নিজের ১.০৩ সেকেন্ড: ৬৪টি জেলার প্রতিটির জন্য পুরো ২ লাখ সারি নতুন করে হাঁটা, মানে ১ কোটি ২৮ লাখ তুলনা। (২) round ২ লাখবার, ০.৪৪ সেকেন্ড: প্রতিটি সংখ্যাকে আলাদা করে গোল করা, অথচ গড়ের জন্য তা দরকারই নেই। (৩) Python 3.12 থেকে list comprehension আলাদা function হিসেবে দেখায় না, তাই তার সময় বাইরের function-এর tottime-এ মিশে আছে। সমাধানটি NumPy-র একটি function: np.bincount(district, weights=paisa) এক পাসে প্রতিটি জেলার মোট দেয়, আর np.bincount(district) দেয় গোনা; ভাগ করলেই গড়। শেষ লাইনে profiler ছাড়া মাপ: প্রায় ১৪৫০ ms থেকে ০.৮২ ms. খেয়াল করুন, profiler নিজেও কোডকে কিছুটা ধীর করে, তাই চূড়ান্ত তুলনা সবসময় profiler ছাড়া।

৯ · চেকলিস্ট — NumPy কোড ধীর বা মেমরি-খরুচে মনে হলে

আর প্রতিটি বদলের পর দুটি কাজ: ফল আগের মতোই আছে কি না মেলানো, আর আবার মাপা। যতটুকু দ্রুত দরকার, ততটুকু হলেই থামুন; পড়তে সহজ কোডের মূল্য গতির চেয়ে কম নয়।

১০ · AI-এর যুগে — AI সহকারীর “optimization” যাচাই

“এই NumPy কোড দ্রুত করে দাও” লিখলে একটি AI সহকারী আত্মবিশ্বাসী উত্তর দেবে, প্রায়ই একটি গুণফলসহ (“১০০ গুণ দ্রুত হবে”)। সেই সংখ্যা সে মাপেনি; আপনার ডেটা আর যন্ত্রও সে দেখেনি। এই বিষয়ে AI সহকারীরা প্রায়ই যা করে:

• না-মাপা গতির দাবি করে, আর মাপলেও একবারের সময় বা warm-up-সহ প্রথম run দেখায়; Numba-র compile-সময় গোপন থাকে।
• মেমরি বাঁচাতে float16 বা float32 সুপারিশ করে, কিন্তু যোগফলের ভুল বা integer overflow-এর কথা বলে না; astype(np.int32) বসিয়ে দেয় বড় টাকার কলামে।
• পুরোনো বা বানানো API লেখে: NumPy 2-এ সরানো np.float, np.int বা np.product, অথবা এমন parameter যা ওই function-এ নেই।
• Function-এর input-কে in-place বদলে দেয় (লুকানো side effect), বা “vectorize” করতে np.vectorize ব্যবহার করে, যা নথি অনুযায়ী মূলত সুবিধার জন্য, গতির জন্য নয়; ভেতরে এটি loop-ই চালায়।
• ধারাবাহিক নিয়মকে (threshold-এ রিসেট) cumsum দিয়ে “vectorize” করে, যা দেখতে ঠিক কিন্তু ভুল ফল দেয়; আর warning চাপা দিতে np.seterr(all="ignore") বসায়।

AI-এর “দ্রুত” কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• পুরোনো আর নতুন কোড একই seed-এর ডেটায় চালিয়ে np.allclose বা np.array_equal দিয়ে ফল মিলিয়েছি, কিনারার ক্ষেত্রসহ (খালি array, একটি উপাদান)
• নিজে warm-up দিয়ে কয়েকবার মেপেছি; AI-এর বলা গুণফল বিশ্বাস করিনি
• প্রতিটি dtype বদলের পর সর্বোচ্চ মান আর যোগফলের নির্ভুলতা দেখেছি
• কোড input array বদলায় কি না পরীক্ষা করেছি (আগে .copy() রেখে পরে তুলনা)
• প্রতিটি অচেনা function আর parameter নিজের NumPy version-এর অফিসিয়াল নথিতে মিলিয়েছি; কোনো warning চাপা দেওয়া হয়নি
• ক্রেতার আসল ডেটা AI-তে পেস্ট করিনি; বানানো ছোট নমুনা দিয়েছি