Cores vs threads vs clock speed: how to size a server CPU

Cores vs threads vs clock speed comes down to one line: threads help concurrency, and clock speed helps single-request latency. Cores are the capacity you’re actually buying. Get that straight and you’ll stop paying for thread counts your workload can’t use, or buying cores when what you needed was a faster one.

Here’s what each term means on a server, which workloads lean on which, and what our own Xeon lineup gives you per dollar.

Cores, threads and clock, in plain terms

A core is a complete processor with its own execution units and its own L1 and L2 cache. Four cores run four instruction streams at full speed at the same time.

A thread, in a CPU spec, means a hardware thread. Intel’s Hyper-Threading lets one core run two threads at once, feeding its execution units from whichever thread has work ready. That pays off when one thread stalls, which mostly happens while it waits on memory. Both threads share the same execution units, so the second one fills gaps; it doesn’t double the work. Count a hyper-thread as a fraction of a core.

Clock speed is cycles per second per core. Server chips list a base and a turbo clock. Turbo is what one or two busy cores reach, and with every core loaded you’ll sit nearer the base. Clock only compares cleanly within one generation, because newer cores get more done per cycle.

On Linux, lscpu shows all three. “Thread(s) per core: 2”, “Core(s) per socket: 4” and “Socket(s): 1” is a quad-core with Hyper-Threading, and nproc will print 8. That 8 is threads. Plenty of monitoring dashboards treat it as cores.

Why the one line holds

Take a PHP page that needs 100 ms of CPU time. One core renders it in 100 ms and can turn out about 10 of those a second. Four cores, about 40. Hyper-Threading adds something on top, but nowhere near another 40.

Now raise the clock 20% within the same generation. Every page drops toward 83 ms, and every visitor feels it. Adding cores does nothing for that one visitor. It lets more visitors get the same 100 ms instead of waiting in line.

So latency is a clock question and throughput is a cores question. Threads squeeze a bit more throughput out of the cores you already have.

What different workloads want

PHP and most web apps. A request runs on one core from start to finish, and each PHP-FPM worker takes one request at a time. Clock sets how fast pages render; cores set how many render at once before visitors queue. A brochure site is happy on four cores. A busy store with uncached cart and checkout pages wants eight or more.

Databases. In MySQL, most individual queries run on a single thread, so one slow report is a clock problem and a hundred concurrent small queries are a cores problem. RAM usually beats both. A buffer pool that holds your working set does more than any CPU upgrade, which is why I’d put a database on a Xeon D-1541 with 64 GB before an E3 with 16.

Game servers. Most run the world simulation on one main thread. The official Satisfactory wiki says its dedicated server favors single-core speed, while Palworld’s requirements page recommends 4 cores or more. Buy clock first, then enough cores for the OS and your other services. Our game server builds start from the same Xeons in the table below.

CI builds. Compiling is the textbook parallel job. make -j$(nproc) hands a file to every thread, and builds scale with cores until the link step, which often runs on one. A team waiting on builds all day wants a dual-socket box.

Video encoding. x264 and x265 spread a single encode across every thread you give them and use AVX2 instructions when the CPU has them. You want many cores with AVX2, so a dual E5 v4 build, not the E3-1230.

Our lineup, by the numbers

These are CPUs from our dedicated server order forms, with Intel’s specs, all $0 setup and month to month. Four prices are builds printed on our site: $126 (E3-1230 v1), $159 (the Xeon D-1541 Special), $248 (Xeon D-1541) and $334 (the dual E5 build, two E5-2620s on the order form). The five marked * are our own sums: the CPU’s line price on the order form plus that form’s default RAM, drive and 30 TB of bandwidth. The $126, $248 and $334 builds are on our browse servers page, and the $159 Special is on current specials.

The E3 builds carry 16 GB against 64 GB on the rest, so their per-core figure flatters them. Add RAM and it climbs.

A few things jump out. The $159 Special is the cheapest way onto 8 cores and 64 GB, with an SSD and an unmetered port, in Ashburn, Chicago or Los Angeles. If you want more cores on one CPU, the single E5-2680 v4 has the lowest price per core of any single-socket build, though on a hard drive. Buying two sockets? Skip the E5-2620 pairs and take the E5-2680 v4s: 16 more cores for $70 over the $334 build. And for one busy single-threaded job, the E3-1271 v3’s 4.0 GHz turbo is the highest clock on our forms. Stock on individual CPU options varies, so the order form or a quote confirms what’s available.

These are older chips, and here’s the trade

Every CPU in that table launched between 2011 and 2016. Here’s what that costs you.

Per-core speed. A 2016 core does more per clock than a 2011 one, and current server cores do more again at higher clocks. You’ll feel it in single-request latency, not in how many requests you can serve.

Instruction sets. Intel’s spec page for the E3-1230 lists AVX but not AVX2. That rules out RHEL 10, which requires the x86-64-v3 level, AVX2 included, though AlmaLinux 10 kept an x86-64-v2 build. The D-1541 and the E5 v4 chips list AVX2.

Memory ceiling. The E3-1230 tops out at 32 GB of DDR3. The D-1541 takes 128 GB, and the dual E5 form goes to 512 GB.

What you get back is a low price per core, $0 setup and no contract. For web stacks, game servers, CI runners, Proxmox hosts and backup targets, that’s a good trade, and it’s the one I’d make. For latency-critical single-thread work at scale, or heavy vector math, it isn’t. The newest family we list is Xeon Silver, a 20-core, 40-thread system on our browse page; for anything newer, ask for a custom build.

Sizing it in practice

Measure before you buy. Run mpstat -P ALL 1 at your busiest hour. If one core sits at 100% while the rest idle, you need clock, not cores. If every core is busy and the load average sits above your core count, you need cores. Count threads only as a bonus, and when you plan VMs, plan them against physical cores. Our dedicated server buyer’s guide covers the rest of the spec sheet, from RAM to bandwidth.

FAQ

Pick a build on our browse servers page, or send your workload and peak numbers through the custom quote form and we’ll match a CPU to them.