Hardware prefetchers are good at sequential and strided access, but they're blind to pointer chases, hash lookups, and irregular graph traversals. That's why x86 exposes explicit prefetch instructions — hints the CPU treats as loads that don't produce a value, don't fault on bad addresses, and don't stall the pipeline waiting for completion.

The four variants differ only in which cache level they target and how the line is marked for replacement:

• PREFETCHT0: fetch into L1 (and L2/L3 as inclusion demands). Use when you'll touch the line within a few hundred cycles.
• PREFETCHT1: fetch into L2, bypassing L1. Use when the line is coming soon but not immediately — avoids evicting hot L1 data.
• PREFETCHT2: fetch into L3 only. Rarely used; the working set has to be genuinely large for this to help.
• PREFETCHNTA: non-temporal — brings the line into a special way of L1 (or L3 on some Intel parts) marked as least-recently-used, so it evicts quickly. For streaming data you'll touch once.

The classic use case: linked-list traversal. When you dereference node->next, the CPU can't prefetch node->next->next because it doesn't know the address yet. But you do — as soon as next loads, issue a prefetch for it while processing the current node:

while (node) {
    __builtin_prefetch(node->next, 0, 3);  // T0, read-only
    process(node->data);
    node = node->next;
}

The 3 is the temporal locality hint (3=T0, 2=T1, 1=T2, 0=NTA). If process() takes ~100 cycles and DRAM latency is ~200 cycles, one iteration of prefetch distance isn't enough. Rule of thumb: prefetch distance = memory latency ÷ work per iteration. For 200ns memory and 50ns of work per node, you need to prefetch ~4 nodes ahead — meaning you need node->next->next->next->next, which requires unrolling or a look-ahead pointer.

Where it backfires: prefetching too aggressively pollutes L1 and steals memory bandwidth from demand loads. Prefetching too close (distance too small) means the line arrives after you need it — no benefit, all overhead. And on modern CPUs with beefy stream prefetchers, adding software prefetch to a simple sequential loop typically hurts performance because you're duplicating what hardware already does for free.

Real numbers: on Skylake, a well-tuned prefetch on a pointer-chasing workload commonly recovers 30–50% of the memory stall time. On a sequential loop over an array, the same instructions cost 1–2% with zero benefit.