ARM, x86 & the Semiconductor World

01ISA — the "language" a CPU speaks

At the very bottom, a CPU only understands electrical signals representing 1s and 0s, arranged into a fixed vocabulary of instructions: "add these two numbers," "load this value from memory," "jump to this instruction if X is true." This vocabulary, and the rules for encoding it as binary, is the Instruction Set Architecture (ISA).

x86 and ARM are two different "languages." A program compiled for x86 is a specific sequence of bytes meaningful to an x86 chip — the same bytes mean something different (or nothing) to an ARM chip. This is why software must be compiled separately per architecture, and why ARM64 compatibility comes up as an issue when migrating to Graviton.

02Why x86 hasn't died out

• Software compatibility debt — decades of Windows, enterprise software, games compiled as x86 binaries. Recompiling isn't always possible (lost source, third-party binaries). This installed base makes switching costly for many use cases.
• Peak single-thread performance — Intel/AMD invested heavily in raw per-core speed (deep pipelines, aggressive out-of-order execution, huge caches). Workloads that don't parallelize well can still favor a fast x86 core.
• Ecosystem and drivers — Windows has historically been x86-first; specialized hardware drivers, GPUs, industrial equipment often assume x86.
• Moving target — Intel and AMD have narrowed the efficiency gap via smaller manufacturing nodes and tricks like efficiency cores, so "ARM always wins on efficiency" is less absolute than it used to be.

Apple's M-series (M1–M4) is ARM-based, not x86 — a deliberate 2020 switch away from Intel. Apple designs the chips itself (architecture license from ARM), same relationship AWS has via Graviton. Old Intel-only Mac software runs via Rosetta 2, a translation layer solving the same compatibility problem via on-the-fly translation instead of recompilation.

03What "licensing the ARM ISA" actually means

ARM Holdings doesn't manufacture chips — it owns designs/specifications and licenses them. Two distinct products:

Manufacturing is a separate step entirely — none of ARM, Apple, or AWS operate fabs. Designs are sent to a foundry (overwhelmingly TSMC in Taiwan) for physical fabrication.

04Neither x86 nor ARM is open source

Both are proprietary IP. The difference is business model, not openness:

• Intel — mostly designs and manufactures its own chips; doesn't license x86 out broadly (AMD is the one big historical exception).
• ARM — manufactures nothing; its entire business is licensing (ISA or ready-made cores) to anyone willing to pay — Apple, AWS, Qualcomm, Samsung, MediaTek, Nvidia, etc.
• RISC-V — the genuinely open one: free to implement, no permission needed, governed by a nonprofit.

05ARM vs RISC-V

Both are RISC-philosophy ISAs — similar at the technical/philosophy level, different entirely in ownership and cost.

Why choose RISC-V over ARM? Cost at massive scale (zero royalty), no dependency on a single company's roadmap or legal/export-control terms (a real factor for Chinese chipmakers), and freedom to add custom instructions without permission.

Why hasn't RISC-V replaced ARM yet? Software ecosystem maturity — the same "compatibility debt" problem seen with x86, just earlier in its lifecycle.

06ARMv8 vs ARMv9, and what "64-bit" really means

The ISA "vocabulary" isn't frozen — ARM periodically releases new spec versions adding instructions and capabilities, always backward compatible.

• ARMv7 — last major 32-bit-only version.
• ARMv8 — introduced 64-bit support (AArch64) alongside 32-bit mode. The big architectural jump.
• ARMv9 (2021+) — built on v8's 64-bit foundation; adds security features (confidential computing, memory tagging) and SVE2.

Graviton3 = ARMv8 (Neoverse V1) — Graviton4 = ARMv9 (Neoverse V2). Graviton4 isn't just faster; it runs a newer instruction vocabulary that unlocks capabilities (like SVE2) Graviton3 physically cannot execute.

07What a "core" is, and why 64 of them

A core is one complete, independent execution unit on a chip: its own registers, arithmetic circuitry, instruction decoder, and private cache.

Historically a chip was one core. Pushing a single core's clock speed higher runs into the power wall — heat generated per second becomes unmanageable past roughly 3–4 GHz (mid-2000s). The industry's answer: put multiple complete cores on one chip, each at a moderate, sustainable clock speed, running separate tasks in parallel instead of one core doing everything sequentially.

"64-core" simply means 64 independent execution units physically etched onto one chip — but this raises the real question: why stop at 64? Why not 32, or 128, or 1000?

Short answer: 64 was never a hard ceiling — it was Graviton3's balance point for 2022's technology, not a physical limit. AWS has since moved past it: Graviton4 (2024) shipped with 96 cores, and Graviton5 (2025) shipped with 192 cores. So the honest framing isn't "64 is the max," it's "each generation picks a core count based on where several real bottlenecks intersect, and better engineering pushes that intersection point higher over time." Four separate bottlenecks decide that point:

• Memory bandwidth per core (usually the tightest constraint). Every core needs data delivered from RAM to stay busy. Total memory bandwidth is fixed by the number of memory channels and their speed (covered in DDR5 below) — it doesn't automatically grow just because you added more cores. Double the cores without also increasing memory channels, and each core now gets roughly half the memory bandwidth it had before — cores start sitting idle waiting for data instead of computing, so the extra cores stop delivering extra real-world throughput. This is a documented, measured problem: AMD's Rome-generation chips doubled core count without proportionally widening memory channels, and per-core bandwidth dropped noticeably as a result — fixed only in the next generation (Genoa) by jumping to 12 memory channels. Concretely: core count and memory-channel count have to scale together, or the extra cores are wasted.
• Interconnect latency and complexity. More cores means the on-chip mesh (covered below) has to route messages across a physically larger grid — more hops, more distance for a coherency signal to travel, more contention on the mesh itself. Past some core count, a single shared cache structure becomes a latency bottleneck for every core trying to reach it — this is precisely why Graviton5's jump to 192 cores required redesigning the cache architecture (from one shared "system-level cache" to a distributed L3 design) rather than just copy-pasting more cores onto the Graviton4 layout. Scaling core count isn't free — it requires re-engineering the communication fabric at each big jump.
• Die size and yield. More cores means more silicon area, and — as covered in the chiplet topic below — larger dies have a higher chance of containing a manufacturing defect, lowering yield and raising cost per working chip. This is one reason chiplets exist: they let AWS add cores without needing one impossibly large monolithic die.
• Diminishing real-world returns (Amdahl's Law). Even with unlimited memory bandwidth and a perfect interconnect, more cores only help if the workload can actually be split into that many independent pieces. Amdahl's Law formalizes this: if some fraction of a workload must run sequentially (a step that depends on a previous step finishing — request parsing, a shared lock, a single database write), that sequential fraction puts a hard ceiling on total speedup no matter how many cores you add. A workload that's 80% parallelizable tops out around 5x speedup whether you throw 100 cores or 100,000 cores at it — the remaining 20% dominates once you've thrown enough cores at the parallel part. This is a mathematical limit, not an engineering one — it's why core counts don't just spiral upward indefinitely even when the hardware constraints above are solved.

Core vs vCPU: a vCPU in AWS docs is usually one physical core. Graviton has no hyperthreading (unlike some Intel chips presenting 2 vCPUs per physical core via simultaneous multithreading) — so vCPU counts aren't always apples-to-apples across instance families. (Deep dive: §20)

08Graviton generation-over-generation evolution

Consistent trend: more cores, faster memory (DDR4→DDR5, wider channels), progressively better price-performance versus equivalent x86 — the gap has widened, not closed, each generation. Performance per vCPU has grown substantially, and core counts have roughly tripled, since Graviton3's 64-core design — direct evidence that 64 was a per-generation balance point (see §07), not a ceiling.

09AWS's broader processor lineup (beyond Graviton)

• x86 instances — Intel Xeon (including newer Granite Rapids-based Xeon 6 in "id"-suffix families like C8id/M8id) and AMD EPYC ("a"-suffix families like M7a, C7a). For anything needing x86-specific binaries, Windows, or software with no ARM build.
• Inferentia / Trainium — AWS's own ML accelerator chips, separate from Graviton, purpose-built for training/inference, competing with GPU instances.
• NVIDIA GPU instances — P and G family instances for CUDA-dependent ML/graphics workloads Graviton and Trainium can't serve.

10Where Graviton is the right call (Django/Celery/Redis/MongoDB stack)

• Django app servers / Celery workers on ECS or EC2 — usually a straightforward win. Python and most C-extension-heavy libraries (numpy, psycopg2, lxml) have solid ARM64 wheels now — often just a Dockerfile base-image change plus rebuild.
• Redis/Valkey caches — R8g instances are explicitly positioned for memory-intensive workloads like in-memory caches, offering up to 3x more vCPUs and memory than R7g.
• Lambda — Graviton2-based arm64 Lambda functions are usually cheaper and sometimes faster than x86 for typical Python/Node handlers; a near-zero-effort switch unless you depend on an x86-only binary layer.
• MongoDB — works fine on Graviton if self-managed on EC2; on Atlas, check their ARM support separately since that's outside AWS's instance choice.

11SVE and SVE2 — what the vector extensions actually do

Ordinary instructions process one number at a time: add these two numbers, get one result. Vector (SIMD — Single Instruction, Multiple Data) instructions process many numbers with one instruction: "add these 8 pairs of numbers" in a single step. This matters enormously for workloads that do the same arithmetic repeatedly across large arrays — matrix multiplication (ML), image processing, cryptography.

ARM's earlier vector extension was NEON — fixed-width (always operates on a fixed number of bits per instruction, e.g. 128-bit). SVE (Scalable Vector Extension), introduced in ARMv8.2, is different in one key way: it's length-agnostic. The same compiled binary can run on a chip with a 128-bit vector unit or a 2048-bit vector unit — the hardware decides the width at runtime, and the software doesn't need to be recompiled per chip. SVE was designed specifically for HPC (high-performance computing) and ML workloads.

SVE2, built into ARMv9, extends the same idea to a much broader set of domains beyond HPC/ML: computer vision, multimedia/video codecs, 5G/LTE baseband signal processing, and general-purpose software — plus operations NEON couldn't do efficiently, like non-contiguous memory access (gather-load/scatter-store) and complex-number arithmetic.

12Chiplet design — why Graviton3 is "7 chiplets," not one piece of silicon

The traditional approach is a monolithic die: the entire chip — all cores, cache, memory controllers, I/O — etched as one continuous piece of silicon. The problem: as chips get more complex, a single microscopic manufacturing defect anywhere on that large piece of silicon ruins the entire chip. Larger dies have proportionally lower yield (the percentage of chips on a wafer that come out defect-free) — cost rises sharply as die size grows.

A chiplet design instead splits the chip into several smaller, independently-manufactured pieces of silicon, which are then connected together inside one physical package using high-speed on-package interconnects — functioning as a single chip from the software's point of view, but built from separate parts.

• Better yield/cost: a defect only ruins one small chiplet, not the whole chip — small dies are cheaper to manufacture at high yield.
• Mix-and-match manufacturing: different chiplets can even use different process nodes — e.g. put the compute cores on the newest, most expensive node, and less performance-critical I/O on an older, cheaper one.
• Trade-off: communication between chiplets (over the package) is slower and uses more power than communication within a single monolithic die — so chiplet design only wins once the die-size/yield problem outweighs that interconnect cost, which is exactly the regime large server chips live in.

Graviton3's "7-chiplet" design: one central compute chiplet (holding the 64 cores) surrounded by additional chiplets handling other functions (built on 5nm for the compute die, with some surrounding chiplets on other nodes) — AWS's answer to keeping a 64-core, DDR5-and-PCIe5-capable chip manufacturable at reasonable cost and yield.

13Mesh interconnect — how 64 cores actually talk to each other

Having 64 independent cores on one chip raises a question we haven't addressed yet: when core #12 needs data that core #47 just wrote to memory, how does that communication physically happen, and how does the chip guarantee every core sees a consistent view of memory (cache coherency) even though each core has its own private cache?

Early multi-core chips used a single shared bus — one shared wire path all cores take turns using. This doesn't scale: with more cores, contention for that one shared path grows, and it becomes a bottleneck.

ARM's answer for high-core-count server chips is the CMN (Coherent Mesh Network) — e.g. CMN-650, used in Graviton3-class designs. Instead of one shared bus, the chip is laid out as a 2D grid of routing nodes called crosspoints (XPs), each connected to its neighbors (north/south/east/west), plus to a nearby core, cache slice, or memory controller. A message from core #12 to core #47 hops across a handful of crosspoints rather than contending for one shared resource — and the network runs a coherency protocol so that when one core writes a value, every other core's view of that memory location stays consistent.

14DDR5 memory, channels, and what "8-channel DDR5-4800" means

RAM doesn't talk to the CPU over one wire — it talks over a memory channel: an independent electrical pathway, with its own set of wires, connecting the memory controller to a group of RAM chips. More channels running in parallel means more total data can move per second — the same logic as adding more highway lanes.

DDR5 is simply the newest generation of the DDR (Double Data Rate) memory standard — the successor to DDR4, running at higher transfer rates and, notably, splitting each memory module internally into two independent 32-bit sub-channels instead of one 64-bit channel, which improves efficiency for the small, frequent memory accesses typical of server workloads.

The number after "DDR5-" (e.g. 4800) is the effective transfer rate in MT/s (mega-transfers per second) — roughly, how many times per second each wire can move a bit. Bandwidth (total data per second) is calculated as: transfer rate × bus width × number of channels ÷ 8 (bits to bytes).

15PCIe lanes — what "32 lanes of PCIe 5.0" means

PCIe (PCI Express) is the standard high-speed connection between the CPU and everything that isn't RAM: network cards, NVMe SSDs, GPUs, and other peripherals. A lane is the smallest unit of a PCIe connection — physically, one pair of wires for sending data and one pair for receiving, forming a single serial data path.

A device connects using some number of lanes bonded together — written as "x1," "x4," "x16," etc. — and more lanes means proportionally more bandwidth to that device, the same "more lanes = more highway capacity" idea as memory channels. Each new PCIe generation (3.0 → 4.0 → 5.0) roughly doubles the data rate per lane while keeping the lane concept the same, so a PCIe 5.0 x4 SSD gets the same bandwidth a PCIe 4.0 x8 connection would have needed.

16Nitro System — the layer that makes Graviton (and all modern EC2) possible

Every EC2 instance is a virtual machine sharing physical hardware with other customers' instances. Traditionally, a hypervisor (the software layer that creates and manages VMs) has to do a lot of extra work on the same CPU your workload runs on: virtualizing networking, virtualizing storage I/O, enforcing security isolation between tenants. All of that overhead competes with your application for the same cores — you never get 100% of the physical hardware's performance.

AWS's Nitro System is a redesign that moves nearly all of that overhead off the main CPU entirely, onto dedicated hardware:

• Nitro Cards — separate physical cards (plugged in alongside the CPU) that handle networking (VPC), EBS storage, and instance-local storage I/O — work that used to run as hypervisor software on the CPU now runs on dedicated silicon instead.
• Nitro Security Chip — dedicated hardware enforcing isolation between AWS's own management functions and customer instances, with a locked-down model that blocks administrative access, including AWS employees.
• Nitro Hypervisor — a lightweight hypervisor left doing only CPU/memory allocation, since I/O and security are now handled elsewhere. This is thin enough that performance is "indistinguishable from bare metal."

17Neoverse N1 vs V1 vs V2 — what actually changes between them

All three are ARM's pre-designed server core blueprints, but they sit in two different product lines within Neoverse, aimed at different priorities:

The "N" line (N1, N2...) prioritizes packing as many efficient cores as possible into a chip — good when your workload is many independent, parallel tasks (exactly the Celery-worker/request-per-core case covered earlier). The "V" line (V1, V2...) sacrifices some of that density for a more powerful individual core — wider instruction decode, more aggressive out-of-order execution, bigger caches — which helps workloads that are partly bottlenecked on single-thread speed even when run on a many-core chip.

18Inferentia and Trainium — AWS's non-Graviton silicon

Graviton is a general-purpose CPU — good at running arbitrary application code (Django, Celery, databases). Machine learning training and inference are different kinds of workloads: extremely repetitive, massively parallel matrix-multiplication, which specialized chips can do far more efficiently than a general-purpose CPU (this is the same reason GPUs are used for ML — they're built for exactly this pattern).

AWS builds its own specialized silicon for this, separate from Graviton, also designed in-house via Annapurna Labs:

• Trainium — purpose-built for training ML models: the computationally expensive process of adjusting a model's parameters against large datasets.
• Inferentia — purpose-built for inference: running an already-trained model to generate predictions, optimized for high throughput and low cost/latency per prediction rather than raw training throughput.

These use the AWS Neuron SDK to let developers deploy models onto Inferentia and train them on Trainium — a software layer analogous to how CUDA lets developers target NVIDIA GPUs.

19EC2 instance family naming — decoding "C7g," "M7g," "R7g"

AWS instance type names follow a consistent pattern: [family][generation][suffixes].[size] — e.g. c7gn.xlarge breaks down as compute-optimized, 7th generation, Graviton, network-optimized, xlarge size.

So C7g / M7g / R7g (mentioned earlier as Graviton3's instance families) are the same C/M/R workload-optimization categories as any Intel or AMD instance — the "g" is the only thing signaling Graviton underneath. This is exactly why a Graviton migration is often "change the instance type string, rebuild for ARM64" rather than a deeper architectural change: the family (C/M/R) still tells you what the instance is optimized for, independent of which CPU vendor is inside it.

20vCPU vs physical core, and hyperthreading (SMT) in full

A physical core, as covered earlier, is one complete independent execution unit. Hyperthreading (Intel's name; the general technique is called SMT — Simultaneous Multithreading) is a technique where a single physical core presents itself to software as two logical processors, by duplicating just the lightweight bookkeeping state (registers, instruction pointer) while sharing the expensive execution circuitry (arithmetic units, caches) between the two threads.

The benefit: a single instruction stream rarely keeps 100% of a core's execution resources busy every cycle — there are gaps (waiting on memory, branch mispredictions). SMT lets a second, independent instruction stream fill those gaps, improving overall throughput — commonly cited around 15-30% more throughput per core, not a full 2x, since the two threads are still competing for the same underlying execution hardware.

215nm process node — what the number actually refers to, and fabs

A process node (e.g. "5nm," "7nm") is the name for a specific generation of chip manufacturing technology at a foundry. Historically the number roughly tracked a physical feature size on the transistor (like gate length, in nanometers) — but since roughly the 20nm era, the marketing number is no longer a direct physical measurement. It's now essentially a brand name for a manufacturing generation, chosen partly for comparability with competitors' node names, not a literal "the smallest feature is exactly 5 billionths of a meter" claim.

What the node number does still correlate with, generation over generation: more transistors packed into the same physical area (higher transistor density), generally lower power consumption per transistor, and generally higher achievable clock speeds — the concrete benefits that let each new Graviton generation pack more cores and features into a similarly sized chip.

Fabs (fabrication plants) are the factories that physically manufacture chips from a finished design — extraordinarily expensive facilities (multi-billion dollar) using photolithography to etch circuit patterns onto silicon wafers. TSMC (Taiwan Semiconductor Manufacturing Company) is the dominant contract fab today, manufacturing chips designed by companies that don't own fabs themselves — Apple, AWS/Annapurna, AMD, Nvidia, Qualcomm, and ARM's own Neoverse reference designs all get physically built at TSMC or similar foundries. This "fabless" model — design without manufacturing — is standard across the industry now; Intel is the notable exception among major players, still running its own fabs for its own chips (though it now also offers foundry services to others).

22ARM's other chip families — Cortex vs Neoverse

ARM licenses more than one family of pre-designed cores, aimed at different markets:

• Cortex — ARM's core family for phones, tablets, laptops, embedded devices, and IoT. Split further into Cortex-A (application processors — the "brains" of a phone), Cortex-M (tiny microcontrollers), and Cortex-R (real-time, e.g. automotive). Optimized primarily for power efficiency and per-device cost, since these ship in the billions.
• Neoverse — ARM's core family specifically for servers and data-center infrastructure (covered in depth above: N-series and V-series). Optimized for core count, memory bandwidth, and sustained throughput under datacenter power/cooling budgets — different priorities than a battery-powered phone.

23RDS instance class naming — decoding "db.r6g," "db.m8g," "db.r6gd"

RDS (AWS's managed relational database service) doesn't run on its own separate hardware lineup — it reuses the exact same EC2 instance families and CPU silicon underneath, just wrapped with a db. prefix and managed by AWS (automated backups, patching, failover). If you already know the EC2 naming pattern from §19, RDS naming is almost the same pattern with one prefix added: db.[family][generation][suffixes].[size] — e.g. db.r6g.2xlarge is a 6th-generation, memory-optimized, Graviton2-powered instance, 2xlarge size.

Notice there's no RDS equivalent of EC2's "C" (compute-optimized) or "I" (storage-optimized) family — because a managed relational database's bottleneck is almost never raw CPU-bound compute or local sequential disk throughput the way a batch job or search index would be; it's memory (buffer cache/working set) and consistent I/O latency to the storage layer. That's exactly why R-family dominates real-world RDS usage — it directly matches what a database actually needs.

One practical wrinkle worth knowing: not every DB engine supports every instance class — e.g. some older or licensed engines (certain SQL Server editions, some legacy Oracle configurations) may lag behind on Graviton or the newest generation support, so it's worth checking AWS's per-engine instance class support table before assuming a given db. class is available for your specific engine/version, even if the equivalent EC2 type exists.