Mia Drake: Cleo, hey — I saw you sent me that chip architecture link at like eleven-thirty last night, which means either you couldn't sleep or you found something genuinely weird.
Cleo Rios: Both, honestly. Both. The thing that would not let me sleep is this: GPUs — the thing that trains every AI model right now — they came from arcade game graphics in the 1970s. Like, Pac-Man era hardware is the direct ancestor of the chip doing your large language model. That's not a technology upgrade story, that's a complete identity crisis for a piece of silicon.
Mia Drake: No way — okay so that's what we're doing today, and I want to frame the question properly: is this a story about three different architectures, or is it a story about how we keep making the same economic bet and calling it physics?
Cleo Rios: It's both and that's what makes it interesting. The three architectures — CPU, GPU, FPGA — they are not competing on one performance curve. That's the thing. A CPU minimizes the time to finish one task. A GPU maximizes how many tasks it can run at the same time across thousands of parallel threads. An FPGA gets rewired after it ships. Those are three different answers to 'what is computation even for.'
Mia Drake: Three different answers — okay but here's what I'd add: in principle a CPU can do everything the other two do. The Haltian documentation basically says it outright — you could compute everything with a CPU, the others just exist because they're faster or more power-efficient for specific jobs. So the split isn't about capability at all.
Cleo Rios: That's the distinction that keeps getting flattened, and it matters so much — it's efficiency versus capability. People say 'GPUs are faster for parallel work' and that's true but it skips the whole point. A GPU isn't doing something a CPU can't do. It's doing something a CPU won't do efficiently because it's built for latency, not throughput.
Mia Drake: And the FPGA angle is where it gets really strange — because FPGAs dominate aerospace and defense not because they're the fastest but because you can literally rewire them after they're deployed. What does that even mean for how we think about 'specialized' hardware?
Cleo Rios: It means the FPGA is the one architecture where flexibility is the product — except the cost of that flexibility is that you need hardware description languages and months of design cycles. It's not free. It is extremely not free.
Mia Drake: Right — but that cost is exactly why I push back on the 'physics' framing. Because FPGAs started in the 1980s as reconfigurable glue logic, just connecting chips on a board, then ballooned into telecom in the 90s as gate counts rose, then got a whole second life in the 2010s paired with CPUs for high-performance compute. That's not a physics arc. That's an economic arc. Someone kept finding a new reason to pay the design tax.
Cleo Rios: No, I don't buy that.
Mia Drake: Why not? The GPU story is the same — arcade graphics in the 70s, 2D blitters in the 80s, fixed-function 3D cards in the 90s, and then suddenly it's training large language models. Nobody planned that. That's luck meeting structure, not durability.
Cleo Rios: Okay, actually — that's where I think luck is the wrong word, and it matters. The reason GPU architecture matched AI training is not accident. AI workloads are thousands of identical operations across independent data. That is literally the SIMT model. Single instruction, multiple threads, built to assume that exact shape. The label changed — 'graphics' became 'AI' — but the workload structure didn't.
Mia Drake: Wait — so you're saying the architecture recognized the workload before anyone named it?
Cleo Rios: Basically, yes. And the CPU side of this proves it from the other direction. Out-of-order execution, speculative branch prediction, register renaming, reorder buffers — all of that exists because operating systems are branch-heavy sequential work. Every line of OS kernel code is 'if this, then that, but only if this other thing.' AMD's Zen, ARM Cortex-A — they're all built on the same out-of-order superscalar premise, and that's not Intel-specific legacy. That's the workload demanding the architecture.
Mia Drake: I mean — that's structurally true, but isn't it possible the workloads got shaped by the available tools? Like, did we write sequential operating systems because CPUs were sequential, and now we're calling that physics?
Cleo Rios: That's the interesting version of the path-dependence argument. But no — databases are sequential because transactions have to be, not because CPUs made us lazy. You cannot parallelize 'check the balance, then debit it' without blowing up consistency. The branch-heavy CPU is not the cause there, it's the match.
Mia Drake: Okay but the person at a defense contractor on Tuesday choosing between an FPGA and waiting for GPU costs to drop another thirty percent — they're not thinking about workload structure. They're thinking about budget cycles. And that decision is what application-class dominance actually is in practice.
Cleo Rios: That decision — okay, but the decision only exists because the FPGA's cost is *structural*, not incidental. Like, it's not 'oh, VHDL is annoying.' It's that the design cycle is months. You're not writing Python. You're describing hardware behavior in Verilog or VHDL, which is a completely different cognitive discipline, and most software engineers will never have it.
Mia Drake: No way — months, not weeks?
Cleo Rios: Months. And that's why the FPGA user base stayed boutique from the 1980s straight through to now. Glue logic in the 80s, telecom gear in the 90s, hybrid FPGA-CPU chips in the 2010s — the arc is real, but the people paying the design tax are always aerospace, always defense, always telecom. It's the same club because it's the only club that can absorb it.
Mia Drake: Okay but that's — actually, is that proof of durability or proof of a moat? Because those aren't the same thing.
Cleo Rios: It's both and the moat *is* the durability — that's my whole point. The contractor on Tuesday isn't just weighing price. She's weighing reconfigurability post-deploy versus a six-month VHDL cycle. And in aerospace, you sometimes *need* to rewire the chip after it's already on the satellite.
Mia Drake: Right — but the thirty-percent GPU cost drop changes that math fast. And power efficiency? GPUs burn hot. Does the FPGA actually win on watts for those workloads?
Cleo Rios: For certain specialized workloads — yes. Actually yes. FPGAs can be more power-efficient than GPUs when the task fits the custom datapath exactly. Which is exactly why defense keeps absorbing the design cost instead of waiting for GPU prices to fall. The watt budget on a satellite is not something you negotiate.
Mia Drake: I mean — fine, I'll grant the power efficiency point. But the expertise gap is the thing that doesn't get solved by physics. That's a people pipeline problem. And there's something coming later about whether a unified model even pretends to fix it that I think is going to break this whole framing open.
Cleo Rios: The flexibility is real. The cost of the flexibility is also real. And nobody in the industry is producing Verilog engineers at scale — that's not inertia, that's a structural gate that keeps the FPGA exactly where it's been since the 80s.
Mia Drake: And that structural gate is exactly where oneAPI comes in — because Intel built this unified programming model, SYCL underneath it, one codebase targeting CPUs, GPUs, FPGAs, accelerators. And I'll give you that. That's real. That does lower the floor.
Cleo Rios: Wait — you're conceding that?
Mia Drake: Narrowly. Because Intel's own documentation basically admits that writing *fast* code on oneAPI still requires you to understand each device's actual capabilities. Like — the abstraction leaks. You can ship code that runs everywhere and is mediocre everywhere.
Cleo Rios: That's — okay, that's the most honest framing of it. Because Intel manufactures Core-series CPUs *and* FPGAs and they built oneAPI, right — they had every incentive to collapse the paradigms and they still couldn't. Out-of-order execution depth, SIMT thread width, reconfigurable datapath design — oneAPI hides those. It does not delete them.
Mia Drake: Exactly that. The heterogeneous compute environment still routes workloads to whichever architecture fits — but doing that *correctly* still demands someone in the room who knows the hardware. The expertise gap didn't move.
Cleo Rios: So oneAPI is — I mean, it's a delivery mechanism, not a dissolution. The physics and the economics underneath it are still just sitting there.
Mia Drake: One inch. That's how much that gap closed.
Cleo Rios: One inch. And the thing is — application-class dominance holds regardless of which fab node we're on this year. It's not tied to a manufacturing process generation. It's tied to workload structure. The CPU runs your OS because OS work is sequential and branch-heavy. That's not 2024's physics. That's not going anywhere.
Mia Drake: But in ten years, if energy costs keep climbing and general-purpose abstraction keeps getting more expensive to run — does the CPU actually lose its role as the brain of the whole system to something that wastes fewer watts per operation?
Cleo Rios: The CPU has been losing that argument for fifty years. And it's still the thing running your operating system. Physics doesn't care about your energy bill.
Mia Drake: That's — yeah. I think that's where we actually land. Unresolved, kind of uncomfortable, which honestly feels right. Good one to sit with.
