Word to Pebibyte

A word's size depends on the CPU architecture. In x86/x64 (Intel/AMD) documentation: word = 16 bits, DWORD = 32 bits, QWORD = 64 bits. In ARM 32-bit: word = 32 bits. In most modern 64-bit systems (excluding x86 documentation): word = 64 bits. When reading technical documentation, always check the architecture's definition, as "word" is not a universal fixed size.

In Windows API documentation and x86 architecture, a DWORD (Double Word) = 32 bits = 4 bytes, capable of holding values 0–4,294,967,295 (unsigned) or -2,147,483,648 to 2,147,483,647 (signed). DWORD is the most common fixed-width integer type in the Windows API, used for flags, handles, and return codes. The equivalent in modern C/C++ is uint32_t (unsigned) or int32_t (signed).

A CPU's word size determines: (1) the maximum addressable memory — a 32-bit CPU addresses up to 4 GiB (2³² bytes); a 64-bit CPU addresses up to 16 EiB (2⁶⁴ bytes); (2) the precision of integer arithmetic — a 64-bit word handles numbers up to ~18.4 × 10¹⁸ in a single instruction; (3) performance — operations on data smaller than the word size may require extra sign-extension instructions on some architectures.

Modern x86-64 CPUs (Intel Core, AMD Ryzen) have 64-bit general-purpose registers, so their native word size is 64 bits for most operations. However, x86 documentation maintains the legacy definition: "word" = 16 bits, DWORD = 32 bits, QWORD = 64 bits. This creates a confusing terminology mismatch between the architectural naming convention and the physical register size.

Memory alignment means storing data at addresses that are multiples of the data's size. A 32-bit word should be stored at an address divisible by 4 (bytes); a 64-bit word at an address divisible by 8. Misaligned access is either forbidden (causes a CPU fault) or penalised (requires two memory reads instead of one). Compilers automatically align variables; manual struct packing can create misalignment that causes subtle performance issues or crashes on strict architectures.

PB (petabyte) = 10¹⁵ bytes = 1,000,000,000,000,000 bytes (SI decimal). PiB (pebibyte) = 2⁵⁰ bytes = 1,125,899,906,842,624 bytes (IEC binary). PiB is 12.59% larger. For a data center purchasing 100 PiB of raw storage, the SI vs IEC confusion would represent approximately 12.59 PB of missing or unexpected capacity.

Cloud providers (AWS, Azure, GCP) operate at exabyte scale but provision and bill individual customers at PiB scale for enterprise storage. Scientific computing facilities like CERN, the Square Kilometer Array telescope project, and US national laboratories store tens to hundreds of PiB. Large video platforms (Netflix, YouTube) store hundreds of PiB of encoded video content.

Using 20 TB drives (a 2024 high-density consumer drive): 1 PiB = 1,125,899,906,842,624 bytes ÷ 20,000,000,000,000 bytes/drive ≈ 56.3 drives. So roughly 57 × 20 TB drives to fill 1 PiB. In a data center using 60-drive storage shelves, one shelf of 60 × 20 TB drives provides about 1.07 PiB of raw capacity.

Magnetic tape (LTO technology) remains the dominant medium for cold storage at PiB scale due to economics and durability. An LTO-9 cartridge holds 18 TB (uncompressed) and costs roughly $100 — about $5.50 per TB, versus $15–20 per TB for HDDs. Tape also consumes zero power when idle, unlike spinning disks. The IBM TS4500 tape library can hold over 40 PiB in a single rack. Major users include CERN, national archives, and film studios — Netflix stores its master copies on tape. Tape's main downside is sequential access: retrieving a specific file can take minutes versus milliseconds for disk.

CERN's Worldwide LHC Computing Grid stores approximately 300–400 PB (petabytes, decimal) of data across distributed sites, with the main Tier-0 facility at CERN holding about 100 PB on disk and 200 PB on tape. The LHC generates roughly 15 PB of data per year from collision events. Future upgrades (High-Luminosity LHC) are projected to increase this to 50–100 PB per year.