Daily Digest — 2026-09-12

In 1987, the Strategic Defense Initiative Organization quietly funded a black program called Timberwind. The goal: a nuclear thermal rocket with ten times the power density of NERVA, small enough to fit in a Shuttle payload bay, capable of hauling Brilliant Pebbles interceptors from LEO to any orbit in hours. The technology was particle-bed reactor (PBR) propulsion, invented at Brookhaven National Laboratory by James Powell in the early 1980s.

The trick was the fuel form. Instead of NERVA's monolithic graphite fuel elements (which cracked, eroded, and limited operating temperature to about 2,500 K), Powell's design used millions of uranium fuel microspheres, each about 500 microns across, coated in zirconium carbide. Hydrogen propellant flowed radially inward through a porous frit into the bed, absorbing heat directly from the enormous surface area of the particles, then out through a central hot channel to the nozzle.

The performance numbers were extraordinary:

• Specific impulse: 930–1,000 seconds (vs. NERVA's 850, chemical LH2/LOX's 450)
• Power density: 40 MW per liter of core (NERVA managed about 4)
• Thrust-to-weight ratio: 25–30 (NERVA was ~4; the RL-10 is ~50 but at a third the Isp)
• Core diameter under one meter, mass under two tons for a 1,000 MW engine

In 1991 the program was declassified, renamed Space Nuclear Thermal Propulsion (SNTP), and transferred to the Air Force Phillips Laboratory. Roughly $200–$800 million had already been spent (numbers still contested). Fuel elements had been tested in the Annular Core Research Reactor at Sandia. A full ground-test reactor called PIPE (Particle-bed reactor Integral Performance Element) was being fabricated at the Nevada Test Site's Saddle Mountain facility. First hot-fire was planned for 1994.

Then the Cold War ended. Brilliant Pebbles was cancelled in 1993. Without an SDI mission, the Air Force couldn't justify a rocket engine whose only civil customer was a Mars program that didn't exist. Congress zeroed the budget in FY1994. The fuel bed hardware was shipped to storage. Test-stand construction stopped mid-pour.

Why 2026 changes the math:

• HALEU is now a commodity. High-Assay Low-Enriched Uranium (up to 19.75%) sidesteps the weapons-grade issue that shadowed Timberwind's 93%-enriched HEU. Centrus Energy delivered the first US commercial HALEU in 2023.
• TRISO fuel is proven. The DOE's AGR-2 tests demonstrated coated-particle fuel operating at 1,800 K with zero cladding failures — validating exactly the microsphere concept Timberwind pioneered.
• DARPA's DRACO program (2023, BWX Technologies + Lockheed) is building a flight-test NTR for 2027. Its engine architecture is a lineal descendant of SNTP: HALEU, ceramic-coated particles, hydrogen propellant.
• Additive manufacturing now produces the porous frit and complex hot-frit geometries that were the single hardest fabrication challenge in 1991.
• Ceramic matrix composites (SiC/SiC) allow structural components at 1,900 K that Inconel-era Timberwind couldn't use.

The result is that a modernized PBR could probably hit the 1,000-second Isp target Timberwind promised, with better safety margins and civilian-legal fuel. A reusable nuclear tug moving 40 tons from LEO to lunar orbit in 30 days — the exact capability NASA now needs for Artemis logistics — sits within reach of 1993 hardware plus 33 years of materials science. The engine was cancelled not because it didn't work, but because the war it was built for ended.

Your PCV system pulls crankcase blow-by back into the intake to burn it. Problem: those vapors carry oil mist, aerosolized by the crank whipping through the sump and by hot gases venting past the rings. On a port-injected engine, injector spray washes intake valves clean of oil deposits. On a direct-injected engine, there's no fuel wash on the back of the intake valve — that oil bakes into carbon crust, choking airflow and killing power. This is why a 60,000-mile GDI engine often needs walnut-shell blasting.

An oil catch can (or air-oil separator, AOS) sits inline between the PCV port on the valve cover and the intake manifold. Its job: slow the vapor stream, force phase separation, drop liquid oil to a reservoir, and pass clean vapor downstream.

Three separation mechanisms are used, often stacked:

• Impaction baffles — vapor hits vertical plates; heavier oil droplets have too much inertia to follow the airflow around them and stick. Cheap and effective for coarse mist.
• Cyclonic separation — the inlet enters tangentially, spinning the flow. Centrifugal force throws oil to the wall where it drains down. Works great for droplets above ~10 microns.
• Coalescing media — stainless mesh or sintered bronze catches sub-micron mist, letting tiny droplets merge into big ones that gravity can drop. Essential for a "true" AOS.

Real-world example: A 2015 VW EA888 2.0T (direct injection) with a factory PCV that separates poorly. Owners routinely find a tablespoon of oil per 1,000 miles in an aftermarket catch can. Skip it and by 80k miles you're pulling the head or paying $600 for walnut blasting. Mishimoto and Radium sell dual-can setups (one on each PCV leg — one for cruise vacuum, one for boost) that solve this permanently.

Rule of thumb — sizing the can: internal volume should be at least 10× your engine's blow-by flow rate per second. A healthy 2.0L engine passes roughly 1–2 CFM of blow-by (about 0.5–1 liter/second). So a 250–500 ml can gives enough residence time (~0.5 seconds) for droplets to fall out. Undersize it and vapor rockets straight through, useless.

Watch out: a catch can is not a delete. It must still vent to the intake — plumbing it to atmosphere causes crankcase pressure buildup, oil leaks past the rear main, and fails emissions. Also: drain it. A full can gets sucked into the intake in one gulp, hydrolocking risk on cold starts.

This program launches two threads that each increment a shared counter one million times. The variables are marked volatile so the compiler won't stash them in registers. The final count should be exactly 2,000,000.

#include <pthread.h>
#include <stdio.h>

volatile long counter = 0;
volatile int  done    = 0;

static void *worker(void *arg) {
    for (int i = 0; i < 1000000; i++) {
        counter++;          /* shared, but "volatile" — safe, right? */
    }
    done = 1;               /* signal completion to a watcher thread */
    return NULL;
}

int main(void) {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, worker, NULL);
    pthread_create(&t2, NULL, worker, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    printf("counter = %ld (expected 2000000)\n", counter);
    return 0;
}

Run it a few times on a multi-core box and you'll see numbers like 1348217, 1892044, 1210778. Never 2,000,000. On single-core hardware — or heavily optimized builds that happen to inline everything into one register — you might see the "correct" answer often enough to think the bug is flaky.

The Bug

volatile is a hint to the compiler, not a synchronization primitive. It tells the compiler:

• Don't cache this value in a register — re-read it from memory each access.
• Don't reorder or elide accesses to this location.

That's all. It says nothing about:

• Atomicity. counter++ compiles to load, add, store — three separate machine instructions. Two threads can interleave: both load 42, both compute 43, both store 43. One increment silently vanishes.
• Memory ordering. Modern CPUs (x86-64, ARM, POWER) reorder loads and stores. A watcher thread spinning on while (!done); might see done == 1 before it sees the writes that logically preceded it. On weakly-ordered ARM this happens routinely.
• Cache coherence timing. Coherence eventually propagates, but "eventually" is not a happens-before relationship your program can rely on.

The confusion comes from Java, where volatile genuinely does provide acquire/release semantics and a happens-before edge. C's volatile was designed decades earlier for memory-mapped I/O registers on single-core systems. The name overlap is a historical accident that has cost the industry uncountable debugging hours.

The Fix

Use C11 atomics, which guarantee both atomicity and (by default) sequential consistency:

#include <stdatomic.h>

atomic_long counter = 0;
atomic_int  done    = 0;

static void *worker(void *arg) {
    for (int i = 0; i < 1000000; i++) {
        atomic_fetch_add(&counter, 1);
    }
    atomic_store(&done, 1);
    return NULL;
}

If C11 isn't available, use a mutex around the increment, or platform intrinsics like __atomic_fetch_add (GCC/Clang) or InterlockedIncrement (MSVC). Any of these produces both an atomic RMW instruction (lock xadd on x86) and the memory fences the hardware requires.

Reserve volatile for what it was actually designed for: memory-mapped hardware registers, signal handler flags of type sig_atomic_t, and setjmp/longjmp locals. Never as a substitute for synchronization.

When you build a multiplier, you generate a mountain of partial products — a 32×32 multiply produces 32 rows that must all be summed. Wallace and Dadda trees reduce these rows using 3:2 counters (a.k.a. full adders): three input bits become a sum and a carry, reducing the row count by a factor of 3/2 per stage. But there's a smarter primitive: the 4:2 compressor.

A 4:2 compressor takes four bits of the same weight plus one carry-in from the neighboring column, and produces a sum, a carry-out (to the same column's next stage), and a carry to the next column. The key trick: the carry to the next column depends only on the four inputs, not on the carry-in. This breaks the horizontal ripple that would otherwise chain across the tree.

Internally it's two full adders, but the boolean structure is optimized. The classic implementation uses two XOR-3 gates on the critical path plus multiplexers for the carries. The result: a 4:2 compressor has a delay of roughly 3 XOR gates, versus 2 XOR gates for two cascaded 3:2 counters — but the compressor reduces four bits to two in one stage, while two cascaded 3:2s take two stages and add up to 4 XOR delays. Net win: fewer stages, lower depth, less wiring.

Real-world example: Intel's floating-point multipliers from the Pentium 4 onward used 4:2 compressor trees rather than pure Wallace trees. AMD's K10 FMA uses a mix of 4:2 and 3:2. ARM's Cortex-A76 multiplier is a 4:2 tree because it maps beautifully onto a regular layout — every compressor has the same footprint, so the physical design is a clean tiled array instead of the irregular jumble a Wallace tree produces.

Rule of thumb: for reducing N rows to 2:

• 3:2 counters need log_1.5(N/2) stages ≈ 8 stages for 32 rows
• 4:2 compressors need log₂(N/2) stages ≈ 4 stages for 32 rows

Half the depth, at the cost of ~40% more transistors per unit reduction. For any multiplier wider than 16 bits, the 4:2 wins on delay and on layout regularity, which is why it dominates modern designs.

The final two rows still need a fast carry-propagate adder — typically a Kogge-Stone or Ling adder — to produce the actual product. The compressor tree is the reduction; the CPA is the finish.

Everyone learns the op-amp. Almost nobody learns the current conveyor, even though Sedra and Smith proposed it back in 1968 as a more general analog primitive. If you've ever needed a wideband transimpedance stage, a precision current mirror with voltage input, or a filter that runs cleanly at hundreds of MHz, the current conveyor is often a better answer than an op-amp.

A second-generation current conveyor (CCII) has three terminals: Y (high-impedance voltage input), X (low-impedance voltage output that tracks Y), and Z (high-impedance current output that mirrors the current flowing into X). The defining equations are beautifully simple:

• V_X = V_Y (X follows Y like a buffer)
• I_Y = 0 (Y draws no current)
• I_Z = ±I_X (Z sources/sinks whatever current X is carrying)

The sign choice gives you CCII+ or CCII−. That's the entire abstraction.

Why bother? Op-amps have a fixed gain-bandwidth product — push voltage gain up and bandwidth collapses. Current conveyors don't. Their gain is set externally by an impedance ratio, and the internal signal path is current-mode, so parasitic node capacitances don't roll off the transfer function the same way. A CCII-based transimpedance stage can hit hundreds of MHz where an op-amp version dies at 10 MHz.

Concrete example — voltage amplifier. Tie Y to your input, put R₁ from X to ground, and R₂ from Z to ground with the output taken at Z. Since V_X = V_in, the X-terminal current is I_X = V_in/R₁. That current is conveyed to Z, developing V_out = I_Z·R₂ = V_in·(R₂/R₁). Same gain formula as a non-inverting op-amp — but with no gain-bandwidth trade-off.

Rule of thumb: if your desired gain × required bandwidth exceeds ~50% of your op-amp's GBW, reach for a current conveyor (AD844 is the classic, and it also exposes the Z node explicitly — many "CFA" op-amps are secretly CCII+ blocks with a buffer). Typical AD844 achieves 60 MHz at a gain of 10, versus a general-purpose op-amp with 10 MHz GBW that would give you only 1 MHz.

Watch out for: X-terminal input impedance isn't truly zero (typically 50 Ω on the AD844), so at low R₁ values it eats into your gain accuracy. Also, Z-terminal parasitic capacitance sets your ultimate high-frequency pole — keep the Z node's load light and its wiring short.

A TVS diode is a purpose-built silicon device that clamps voltage spikes by breaking down into avalanche conduction the moment the line exceeds its rated voltage. Unlike MOVs, which use metal-oxide grain boundaries and degrade with every hit, TVS diodes are solid-state PN junctions that respond in under a picosecond and survive millions of surge events without measurable wear — as long as you stay under their peak pulse power rating.

They come in two flavors:

• Unidirectional — one PN junction, conducts normally in reverse only. Used on DC rails where polarity is fixed (e.g., a 12V automotive supply). Forward-biased, it looks like a regular diode at ~0.7V.
• Bidirectional — two junctions back-to-back, clamps in either polarity. Used on AC lines, differential data pairs (USB, CAN, RS-485), and antenna inputs where signals swing above and below ground.

Three voltages define every TVS:

• V_RWM (reverse working voltage) — the highest normal operating voltage. Below this, the diode is invisible (leakage in microamps).
• V_BR (breakdown voltage) — where avalanche begins, typically 10–15% above V_RWM.
• V_C (clamping voltage) — the actual voltage across the diode at peak surge current. This is what your downstream circuit sees, and it's always higher than V_BR.

Real-world example: Protecting a CAN transceiver on an automotive ECU. The CAN bus normally swings between 0V and 5V, but load-dump events can inject ±100V transients from the alternator. A bidirectional TVS like the PESD1CAN (V_RWM = 24V, V_C ≈ 40V at 1A) sits across CAN_H-to-ground and CAN_L-to-ground. Under normal signaling, the diode's ~5pF capacitance is low enough not to distort the 1 Mbps signal. During a transient, it dumps the surge current to ground before the transceiver's 40V-rated input pins see anything they can't survive.

Rule of thumb — sizing peak pulse power: The IEC 61000-4-5 standard tests with an 8/20µs surge waveform (8µs rise, 20µs to half-peak). For that pulse, use P_PP = V_C × I_PP. If your line sees 30A surges and the diode clamps at 40V, you need at least 1200W of peak pulse power capability. A 600W TVS will fail open (or shorted, then explode) on the first real strike.

The capacitance tradeoff: TVS junction capacitance ranges from ~0.5pF (specialized RF/high-speed data) to ~10,000pF (bulk power rails). On a USB 3.0 line at 5 Gbps, anything over 1pF causes eye-diagram distortion. On a 12V DC input, 500pF is fine and actually helps filter noise.

Nearly two centuries before "evidence-based medicine" became a slogan, a London farrier named John Hinds wrote a preface that reads like a manifesto against what we would today call cargo-cult practice. In his 1827 treatise on horse diseases, Hinds warned readers not to trust the fashionable recipe books of his day — including, presumably, his own — unless they first understood why a remedy worked.

Indeed, he should study it hard, if he would become proficient in "the Art of Farriery," and not rely implicitly upon other people's prescriptions for the cure of any alleged disorder, which have been composed for the most part without any such preparation. From this neglect, also, symptoms of one disorder are confounded with those of another, when the proposed remedies cannot possibly effect the cure.

His prescription for genuine competence was startlingly direct: cut open dead horses. Whenever, and wherever, you can.

He had best to comply with the advice strenuously urged at the very outset, to examine the internal parts of dead horses, as often as opportunity presents itself, which in the neighbourhood of large towns and hunts is frequent enough. For this is the manner in which I was myself mainly instructed.

What's remarkable here is not the recommendation of dissection — anatomists had been doing it for centuries — but Hinds's insistence that the working farrier, the ordinary shoeing-smith or groom, had a moral obligation to develop his own diagnostic eye rather than mechanically match symptoms to recipes in a book. He was writing at the very moment veterinary medicine was professionalizing (the Royal Veterinary College had opened in 1791), and the market was flooded with "quack" pamphlets promising cures. His response was to tell readers, in effect: your book is only as good as your ability to see through it.

Modern medicine has spent the past thirty years rediscovering the same tension. Clinical decision-support systems, protocol-driven care, and now large language models can all produce a plausible answer for any set of symptoms. But study after study finds that the practitioners who catch the outliers — the atypical presentations, the two-diseases-at-once cases — are the ones who understand pathophysiology deeply enough to distrust the pattern-match. Physicians call this the difference between "System 1" and "System 2" thinking. Hinds called it the difference between studying nature and copying prescriptions.

His observation that "symptoms of one disorder are confounded with those of another" when the remedy is applied without understanding is essentially a description of diagnostic anchoring bias, first named in the medical literature in the 1970s. Hinds had no framework for cognitive bias. He just watched a lot of horses die from correctly-applied wrong cures.

The advice to walk down to the knacker's yard and open up a corpse is quaint. The underlying claim — that reading recipes is not the same as understanding disease — is not.

In 1867, a young chemist named Victor G. Bloede — "Late Assistant Chemist at the Cooper Institute" — published a book aimed at a profession that no longer exists. His subject: how to systematically recover the gold and silver dissolved into every photograph made in the 19th century.

The table of contents reads like a forgotten industrial workflow:

On the Best Methods and Apparatus for Saving the Various Wastes Occurring in Photography — The Bath — The Sensitized Plate — Developer Residues — The Fixing Solution — Old Negatives, Ambrotypes, etc., etc — Paper Clippings, etc., etc — The Print Washings — The Toning Solution — The Print Fixing Solution

Every step of the wet-plate collodion process leaked precious metal. Silver nitrate soaked the plate; gold chloride toned the print; both metals drifted into the fixing bath, the wash water, and even the paper clippings on the darkroom floor. Bloede taught photographers and dedicated "reducers" how to burn, roast, precipitate, decant, and smelt these residues back into ingots — a whole chapter is devoted to "The Furnace and the Management of Heat — Selection and Preparation of Fuel — Crucibles and Melting Pot."

Was this real money? Absolutely. A working portrait studio in the 1870s could recover several ounces of silver per month from its fixing baths alone. Refiners paid cash for barrels of exhausted hypo. Some studios employed the reducer's trade themselves; others sold their sludge to specialists. The economics were plain: silver was expensive, and every unfixed photograph literally rinsed money down the sink.

What killed the trade? Three things: gelatin dry plates reduced silver consumption, electrolytic recovery replaced smelting, and finally digital photography erased silver halide chemistry from consumer life entirely. The knowledge Bloede so carefully compiled — how to precipitate a toning bath, how to burn paper wastes to concentrate their metal, how to manage a crucible fire — became irrelevant within a century.

Except it didn't, really. The modern analogue is urban mining — recovering gold, silver, palladium, and rare earths from discarded circuit boards, catalytic converters, and X-ray film. The techniques Bloede describes (roasting, precipitation with iron or zinc, cyanide leaching, cupellation) are still the backbone of e-waste refining. A ton of smartphone motherboards contains more gold than a ton of gold ore. The Bureau of Mines rediscovered in the 1980s what Bloede's readers knew in 1867: your waste stream is an ore body if you know how to read it.

Hospitals still recover silver from X-ray fixer. Dental labs still smelt gold from crown scrap. But the household-scale knowledge — that a working professional could and should reclaim their own precious metals — is gone. Bloede's readers would be astonished at how much silver and gold we now simply throw away.

Ralph Teetor lost his sight at age five in a workshop accident. He never learned to drive a car. And yet, in August 1950, the U.S. Patent Office granted him US Patent 2,519,859, "Speed Control Device for Resisting Operation of the Accelerator" — the mechanism that would become cruise control, and, seventy-five years later, the throttle backbone of every self-driving car on the road.

Teetor filed the application in 1945. He was chief engineer at Perfect Circle Corporation, an Indiana piston-ring maker, and had developed a mechanical intuition sharp enough that colleagues said he could diagnose an engine by ear alone. The origin story is unusually specific: Teetor was regularly chauffeured by his patent attorney, a man who unconsciously sped up while talking and slowed down while listening. The rocking motion made Teetor carsick. He decided to invent his way out of it.

The patent describes a beautifully simple closed loop. A cable driven off the transmission spins a small centrifugal governor. As road speed rises, flyweights fling outward and push against a diaphragm connected to engine vacuum. That vacuum, in turn, pulls a pneumatic servo attached to the throttle linkage. Set a target speed, and the governor fights any deviation — the throttle backs off when the car accelerates downhill, and opens when it lugs uphill. Teetor called it the Speedostat.

Chrysler licensed it. The 1958 Imperial shipped it as "Auto-Pilot." Cadillac adopted it a year later under the name that stuck: Cruise Control. Within a decade it was standard equipment across the American luxury market.

The modern lineage is direct and largely unbroken.

• Adaptive Cruise Control (ACC) — Mitsubishi shipped the first radar-based ACC in Japan in 1995; Mercedes followed with Distronic in 1999. Both are Teetor's control loop with an extra input: measured distance to the car ahead becomes another variable the governor tries to hold.
• Tesla Autopilot and every Level 2+ ADAS system — internally called "Traffic Aware Cruise Control," the throttle-and-brake half of Autopilot is architecturally Teetor's PID loop, now closed around camera and radar fusion instead of a spinning cable.
• Waymo, Cruise, Mobileye — the module every autonomy stack labels "longitudinal control" is a lineal descendant. Sensors and target-setting have exploded in complexity; the actuator loop underneath still does what Teetor's governor did.
• EV one-pedal driving — the regenerative-braking algorithms that hold speed on a downhill in a Rivian or a Model Y are a Teetor governor in software, blending motor torque instead of vacuum.

Teetor's insight was not the mechanism — centrifugal governors dated back to James Watt's steam engines in 1788. His insight was applying feedback control to the driver's own foot, treating the human as a noisy signal to be smoothed rather than a system to be replaced. That framing — augment the driver, don't remove them — is exactly the posture Tesla, GM Super Cruise, and Ford BlueCruise all still take in 2026, half a century into the arc.

Teetor served as president of the Society of Automotive Engineers in 1936. He held more than forty patents. He never once operated the invention he is remembered for.

Among a sea of randomly-named repos with cryptic six-letter identifiers, bdd-pilot stands out as one of the few in this batch with a real name, a real language tag, and — judging by the naming — a real intent. The name suggests a Behavior-Driven Development pilot: a TypeScript project likely exploring how BDD workflows can be automated, assisted, or "piloted" (perhaps with an AI copilot flavor, given the current zeitgeist).

BDD tooling in the TypeScript ecosystem has historically been a bit fragmented. Cucumber.js exists, and playwright-bdd has gained traction, but the developer experience of writing Gherkin scenarios, wiring up step definitions, and keeping them in sync with evolving application code remains tedious. A "pilot" project in this space could plausibly tackle any of several pain points:

• Scaffolding — generating step definitions from feature files automatically
• Sync detection — flagging orphaned steps or missing implementations
• AI-assisted authoring — turning natural-language requirements into runnable scenarios
• Integration glue — bridging BDD frameworks with Playwright, Vitest, or Jest

Even at zero stars and with no description, the repo is worth a peek because BDD tooling is one of those areas where anyone shipping a genuinely useful helper can gain traction fast. The QA and test-automation community actively hunts for tools that reduce the friction between product requirements and executable specifications.

Who might benefit? QA engineers evaluating BDD adoption, test automation leads working with Cucumber or Playwright, and developers curious about how AI-assisted test authoring is evolving in TypeScript-heavy codebases. It's also a nice reference point for anyone considering building their own BDD tooling — early-stage repos often reveal cleaner architectural decisions before feature creep sets in.

For decades, CPU caches lived on the same silicon die as the cores, competing for area with everything else. 3D V-Cache (AMD's marketing name; the technique is hybrid bonding or TSV stacking) breaks that constraint by bonding a second silicon die directly on top of the CCD, tripling L3 capacity without touching the core layout.

The trick: through-silicon vias (TSVs) punch vertical connections through the base die to a cache-only die stacked above. AMD's implementation uses direct copper-to-copper hybrid bonding (no solder bumps), giving inter-die bandwidth similar to on-die wires. The stacked SRAM die adds 64MB of L3 on top of the 32MB base, yielding 96MB total per CCD.

Why stacking, not just a bigger die?

• Wafer yield: SRAM has huge, regular structures — much higher yield per mm² than logic. Fabricating cache separately on an optimized process avoids dragging down CPU yield.
• Wire length: A 96MB planar L3 would require signals to traverse a much larger die area, adding latency. Vertical stacking keeps wires short.
• Thermal reality: SRAM sits above the cores — but SRAM generates almost no heat compared to logic. It insulates the hot cores from the heatspreader, forcing AMD to lower peak clock speeds on X3D parts by ~200-400 MHz.

Real-world impact: The 7800X3D beats the 7700X in gaming by 15-30% despite lower clocks, because game code often has a working set that fits in 96MB but not 32MB. Factorio's late-game simulation improves ~70%. Meanwhile, compilation workloads (which stream through memory rather than reuse hot data) gain almost nothing and lose to the non-X3D chip because of the clock deficit.

Rule of thumb: If your working set W satisfies 32MB < W < 96MB and access patterns show temporal reuse, expect V-Cache speedups of 15-40%. If W < 32MB (fits in base L3) or W >> 96MB (streams through both), expect zero benefit and a small clock-driven regression.

Latency cost: The stacked L3 adds ~4 cycles vs. the base L3 (from ~46 to ~50 cycles on Zen 4), because addresses must be hashed across a larger slice count and signals traverse TSVs. AMD hides this by keeping the base 32MB as the "fast" region for hot data, essentially creating an L3.5.

Intel's competing approach — Foveros — stacks logic-on-logic (used in Meteor Lake's compute tile atop the base tile), a harder thermal problem but more flexible than cache-only stacking.