A Minecraft server lives and dies on one thread. The tick loop, the thing that moves every mob, ticks every hopper and saves every chunk, runs on a single core and has to finish this tick before it can start the next. So the CPU that matters is the one that runs a single thread quickly and stalls the least while doing it, whatever its core count or headline number. This post explains what that means, and why the large-cache X3D parts win on a dedicated box.

The tick is single-thread bound and memory-latency bound

Two things decide how fast one tick finishes.

The first is how fast that one core runs, which comes down to clock speed and IPC (instructions per clock, roughly how much work the core does each cycle). A faster core finishes the tick's arithmetic sooner. Straightforward.

The second is less obvious and usually matters more. The tick spends a lot of its time chasing pointers around the heap: entity here, block entity there, chunk data somewhere else again. Every time the data it needs is not already in the CPU's cache, the core stalls and waits on main memory. That wait is a cache miss, and on a branchy, pointer-heavy workload like a game tick there are a lot of them. A stalled core is a core doing nothing, no matter how high its clock.

So the two levers that actually move MSPT (milliseconds per tick, the time each tick takes) are per-core speed and cache. Clock and IPC set how fast the thread runs when it's running. Cache sets how often it has to stop.

Why X3D wins

AMD's X3D parts stack extra L3 cache on top of the die, a design AMD calls 3D V-cache. Instead of the 32MB or so on a normal chip, you're looking at 96MB or more. For a game tick that's the difference that counts.

More cache means more of the tick's hot working set stays resident. The entities, the loaded chunks, the block data the tick touches every 50ms can sit in cache instead of being fetched from RAM over and over. Fewer cache misses means fewer stalls, and fewer stalls means a lower MSPT. On a cache-bound workload, keeping the working set resident cuts tick time more than another few hundred megahertz of clock would, because clock does nothing for a core that's parked waiting on memory.

This is a dedicated-server story for us, and we'll scope it honestly. On a dedicated server, where you're not sharing the chip, you can have a large-cache X3D part for exactly this reason. On shared hardware the extra cache is split across whatever else is on the box, so the benefit is diluted. The claim only holds cleanly when the chip is yours, which is why we offer it there and don't pretend it applies everywhere.

Intel or AMD, and the hybrid-core trap

This is not a team-sport argument, so here's the actual engineering.

The thing to watch on modern desktop-class Intel parts is the hybrid layout: a handful of strong performance cores (P-cores) alongside a larger number of weaker efficiency cores (E-cores). It looks excellent on a spec sheet, twenty-something cores for the money. The problem for a game server is the scheduler. If the operating system parks your tick thread on an E-core, the tick suddenly has less core to work with, MSPT climbs, TPS drops, and nothing in your logs explains why, because from the game's point of view it just got slower for no reason. You end up chasing a ghost.

Uniform, full-power cores don't have that failure mode. Every core is the same, so wherever the tick thread lands it gets the same speed, and performance stays predictable. That predictability is the whole point. A server that's steadily good is worth more than one that's occasionally faster and occasionally mysterious.

That's why our game nodes run high-clock AMD Ryzen parts (Ryzen 7 and Ryzen 9) on the current generation, with X3D available on dedicated boxes. Uniform cores suit the predictability argument above, the cache story is there to be specced for when the chip is yours, the platform has a sensible upgrade path, and the power behaviour is easy to reason about when you're tuning for flat tick times. Intel makes fast cores. For this specific workload the uniform-core AMD parts with the big cache are the cleaner fit, and we'd rather tell you why than wave a flag.

The AVX-512 myth

AVX-512 comes up a lot, so it's worth killing plainly. It's a set of wide vector instructions, brilliant at doing the same maths on big blocks of numbers at once: scientific computing, encoding, some machine-learning kernels. It does close to nothing for Minecraft.

A game tick is branchy and latency-bound. It's a mess of conditionals (is this mob in water, is that hopper full, did this redstone update) walking scattered data structures. That's the opposite of the neat, regular number-crunching wide vectors are built for. There's almost nothing to vectorise, so the instructions sit unused. And even where you could vectorise a corner of it, it wouldn't help, because the bottleneck is the cache miss, not the arithmetic. You cannot SIMD your way out of waiting on memory. Wider maths on data you don't have yet is still waiting on data you don't have yet.

So AVX-512 is a real feature, genuinely useful elsewhere, that does very little for a Minecraft tick. The things that make a server tick faster are cache and per-core speed.

The short version

For a Minecraft server, chase per-core clock and IPC first, then cache, and treat core count as a separate question about how many servers you're running. We answer that one in do more cores actually help a game server. And once the hardware is sorted, the server software matters just as much, which is where Paper vs Purpur and the SMP tuning guide come in.

One caveat over all of the above. Unless your server is genuinely busy and cache-bound, the gap between a good chip and the best available one is smaller than the internet suggests, and the X3D argument is overkill for a small world. We still buy for it, because the part costs us the same whether or not your server needs it, and the headroom is there on the night it turns out you did.

If you'd rather just run on hardware that's already picked for this, our Minecraft hosting runs dedicated boxes you can spec with a large-cache X3D part for exactly the reasons above.