Bit, Nibble, Byte, Word — সংগঠনের একক

গাণিতিকভাবে “সেরা” ছিল না — বাণিজ্যিকভাবে যথেষ্ট আর প্রভাবশালী ছিল।

কোনো গাণিতিক প্রমাণ নেই যে ৮ bit “সেরা” byte size — এটা শুধু একটা প্রকৌশলগত trade-off: ৬-bit যথেষ্ট character-space দেয় না (মাত্র ৬৪টা code), আর তার চেয়ে বড় (১০, ১২ bit) হলে অহেতুক জায়গা নষ্ট হতো তখনকার character set-এর জন্য যেখানে ২৫৬টা code point-ই যথেষ্টের চেয়ে বেশি ছিল।

প্রকৃত সিদ্ধান্তকারী শক্তি ছিল বাণিজ্যিক আধিপত্য: System/360 এত ব্যাপকভাবে সফল হয় যে পুরো software industry তার convention-এর সাথে মানিয়ে নেয়, শুধু compatibility আর নেটওয়ার্ক-এফেক্টের কারণে (যত বেশি সিস্টেম ৮-bit ব্যবহার করে, তত বেশি নতুন সিস্টেমের জন্য ৮-bit বাছা “নিরাপদ” পছন্দ হয়ে ওঠে)। এটাই asymptotic-notation লেসনের সেই “asymptotically ভালো সবসময় বাস্তবে সেরা নয়” নীতির আরেকটা রূপ — এখানে প্রশ্নটা optimality নিয়েই না, বরং কে প্রথমে বাজারে জিতে গেল তা নিয়ে। যে কোনো একটা যুক্তিসঙ্গত পছন্দ (হয়তো ৭-bit, হয়তো ৮-bit) “জিতে” যেতে পারত যদি সঠিক কোম্পানি সেটা বাছত আর বাজারে সফল হতো — এটা একটা path-dependent historical outcome, প্রমাণযোগ্য গাণিতিক optimum নয়।

তুলনা করুন keyboard layout-এর সাথে: QWERTY “সেরা” arrangement নয় (Dvorak-এর মতো বিকল্প বিদ্যমান, কিছু গবেষণায় দ্রুততর), তবু QWERTY জিতেছে আগে থেকে established হয়ে যাওয়ায়। ৮-bit byte-এর গল্পও একই শ্রেণির — standardization-এর মূল্য প্রায়ই যেকোনো একটা নির্দিষ্ট বিকল্পের “অপ্টিমালিটি”-র চেয়ে বেশি গুরুত্বপূর্ণ।

৩২-bit system-এ:

struct Node {
    int   value;   // offset 0, 4 byte
    Node* next;     // offset 4, 4 byte (৩২-bit pointer, 4-align)
};
sizeof(Node) = 8 byte     (কোনো padding লাগে না — উভয় field 4-byte-aligned)

মোট: $10,000,000 \times 8 = 80,000,000$ byte $= 80$ MB (প্রায়)।

৬৪-bit system-এ:

struct Node {
    int   value;   // offset 0, 4 byte
    Node* next;     // ৮-byte pointer, ৮-align দরকার — কিন্তু offset 4 থেকে শুরু করলে misaligned
};

next কে offset 4-এ রাখা যাবে না (৮-এর গুণিতক নয়), তাই ৪ byte padding লাগবে value-এর পর, next শুরু হবে offset 8-এ:

offset 0-3  : value (4 byte)
offset 4-7  : padding (4 byte)
offset 8-15 : next (8 byte)
sizeof(Node) = 16 byte

মোট: $10,000,000 \times 16 = 160,000,000$ byte $= 160$ MB (প্রায়)।

ফলাফল: $80 \to 160$ MB — ঠিক দ্বিগুণ, শুধু pointer আকার আর তার সাথে আসা padding-এর কারণে, যদিও প্রতিটা node-এর “প্রকৃত তথ্য” (int value) অপরিবর্তিত। এটাই আগে concept section-এ উল্লেখ করা “linked list-এ ৬৪-bit-এর দ্বিগুণ খরচ” দাবির সম্পূর্ণ, সংখ্যায়িত প্রমাণ — আর এই কারণেই বড়, memory-সংবেদনশীল data structure-এ (যেমন game engine বা large-scale server) ইঞ্জিনিয়াররা প্রায়ই raw pointer-এর বদলে ৩২-bit array index ব্যবহার করেন, এমনকি ৬৪-bit system-এও — pointer-এর নমনীয়তা ছেড়ে দিয়ে memory বাঁচানোর জন্য।

মূল ক্রম — char a; short b; char c; int d;:

sizeof = 12 byte (প্রকৃত তথ্য মাত্র $1+2+1+4=8$ byte, ৩৩% padding)।

পুনর্বিন্যস্ত — বড় থেকে ছোট alignment: int d; short b; char a; char c;:

sizeof = 8 byte — কোনো padding লাগেনি, কারণ প্রতিটা field নিজে থেকেই তার আগের field-গুলোর যোগফলের সাথে align হয়ে গেছে।

সাধারণ নিয়ম যা এখান থেকে বের হয়: field-গুলোকে বড় থেকে ছোট alignment অনুযায়ী সাজালে সাধারণত padding সর্বনিম্ন হয় (যদিও সবসময় শূন্য নিশ্চিত নয়, নির্ভর করে সব field-এর মোট আকার সবচেয়ে বড় alignment-এর গুণিতক কি না তার উপর — এখানে $4+2+1+1=8$, আর $8$ নিজেই int-এর ৪-alignment-এর গুণিতক, তাই কোনো tail padding-ও লাগেনি)। কিছু আধুনিক compiler (Rust-এর ডিফল্ট layout, এবং কিছু C compiler flag দিয়ে) স্বয়ংক্রিয়ভাবেই field reorder করে এই সাশ্রয় পায়, কিন্তু C স্ট্যান্ডার্ড অনুযায়ী struct-এর field ক্রম source code-এর ক্রম অনুসরণ করতে বাধ্য — তাই C-তে এই optimization প্রোগ্রামারকেই হাতে করতে হয়।

$2^{20}$ টা আলাদা address সম্ভব একটা ২০-bit address bus দিয়ে (combinatorics-এর product rule — প্রতিটা bit স্বাধীনভাবে 0 বা 1 হতে পারে, মোট সমাবেশ $2^{20}$)।

$2^{20} = 1,048,576 \text{ byte} = 1,024 \text{ KiB} = 1 \text{ MiB (ঠিক)}$

সর্বোচ্চ ১ MB memory address করা যাবে — এই bus-এ RAM যতই লাগানো হোক (২ MB, ১৬ MB), সিস্টেম শুধু প্রথম ১ MB-ই “দেখতে” পাবে, কারণ address-এর জন্য bit-ই নেই বাকিটা চেনানোর।

ঐতিহাসিক প্রসঙ্গ: এটা ঠিক আসল IBM PC (Intel 8086, ১৯৭৮)-এর সীমা — 8086-এর address bus ছিল ২০-bit, তাই ঠিক $2^{20} = 1$ MB address space। এই একই সীমার কারণে DOS-যুগে বিখ্যাত “conventional memory” (৬৪০ KB, বাকিটা BIOS/video card-এর জন্য সংরক্ষিত) সমস্যা জন্ম নেয় — যা এই লেসনের concept section-এর “৩২-bit 4GB wall”-এর ঠিক আগের প্রজন্মের সংস্করণ, একই গাণিতিক নীতির (address bus width → সর্বোচ্চ addressable space) আরেকটা প্রয়োগ, শুধু সংখ্যাটা ছোট।

এই প্রশ্নটা লেসনের প্রায় প্রতিটা ধারণা একসাথে প্রয়োগ করতে বলছে।

১. Fixed-width type বাছুন, platform-নির্ভর type নয়। int, long নয় — int32_t, uint64_t (timestamp-এর জন্য), uint8_t (status flag-এর জন্য, যদি কয়েকটা মাত্র অবস্থা থাকে)। এতে ফাইলটা platform-নিরপেক্ষ থাকবে, আর প্রতিটা field-এর আকার সবচেয়ে ছোট যথেষ্ট size-এ রাখা যাবে (একটা status flag-এর জন্য পুরো ৪-byte int অপচয়)।

২. Field-গুলো বড় থেকে ছোট alignment অনুযায়ী সাজান। যেমন RecordPacked উদাহরণে দেখা গেছে, শুধু ক্রম বদলে ৩০-৪০% পর্যন্ত padding বাঁচানো সম্ভব — লক্ষ লক্ষ record-এ এটা যথেষ্ট বড় সাশ্রয়।

৩. Explicit packing বিবেচনা করুন, কিন্তু trade-off বুঝে। #pragma pack(1) দিয়ে padding সম্পূর্ণ বন্ধ করা যায় — জায়গা সর্বোচ্চ বাঁচে, কিন্তু (ক) misaligned access-এর ঝুঁকি (কিছু ARM-এ crash), (খ) CPU-তে load করে ব্যবহারের সময় প্রতিবার misaligned penalty। যদি ফাইলটা মূলত disk/network-এ সংরক্ষিত থাকবে আর কম-ঘন ঘন পড়া হবে, packing worth it — disk জায়গা আর I/O bandwidth সাশ্রয় বেশি গুরুত্বপূর্ণ। যদি record বারবার in-memory প্রসেস করা হবে (hot path), alignment বজায় রেখে সামান্য বেশি জায়গা খরচ করাই ভালো — CPU cycle বাঁচবে।

৪. Variable-length data (string) আলাদাভাবে সামলান। একটা “ছোট string” যদি নির্দিষ্ট max length-এর না হয়, সরাসরি struct-এ বসানো যাবে না (compile-time known size লাগে)। সাধারণ সমাধান: হয় একটা fixed-size buffer (waste হতে পারে ছোট string-এ), অথবা string-টাকে আলাদা section-এ রেখে struct-এ শুধু একটা offset+length (এই module-এর পরের একটা লেসন — serialization — এই প্যাটার্নটা বিস্তারিত দেখাবে)।

৫. Endianness ঠিক করুন explicit ভাবে। যেহেতু ফাইলটা সম্ভবত ভিন্ন সিস্টেমে পড়া হবে (বা অন্তত ভবিষ্যতে হতে পারে), byte order একটা নির্দিষ্ট convention-এ (সাধারণত little-endian, আধুনিক CPU-র সাথে মিলিয়ে) স্থির করে রাখুন এবং documentation-এ লিখে রাখুন — পরের একটা লেসনের বিষয়, কিন্তু ডিজাইনের এই পর্যায়েই সিদ্ধান্ত নেওয়া উচিত।

সংক্ষেপে: এই একটা design প্রশ্ন এই পুরো লেসনের প্রতিটা নীতি (fixed-width type, alignment, padding, packing trade-off) একসাথে বাস্তব প্রকৌশল সিদ্ধান্তে রূপান্তরিত করে — যা প্রতিটা বাস্তব binary file format (PNG chunk, ELF section header, database page format) ডিজাইনারকে ঠিক এই প্রশ্নগুলোর মুখোমুখি হতে হয়।