Choosing between CPU and GPU hardware for density functional theory is not a matter of one being universally faster. It is a question of matching your workload to the architecture. This article breaks down the real differences, explains how speedup scales with system size, and gives practical guidance on when each option can come out ahead on speed and cost.
Two Very Different Architectures
The CPU-versus-GPU question comes down to how each processor is built and what kind of work it is designed to do.
CPUs: Few Fast Cores, Large Memory
A modern server CPU has on the order of tens of cores, each with high single-thread performance, deep caches, and sophisticated branch prediction. A dual-socket node commonly exposes 64 to 128 cores and hundreds of gigabytes of system RAM. CPUs excel at latency-sensitive, branch-heavy, and irregular code, and they give you a huge memory pool to work with.
GPUs: Thousands of Slow Cores, Fast but Scarce Memory
A datacenter GPU has thousands of lightweight cores organized for massive data parallelism, fed by high-bandwidth memory (HBM) that delivers 1-3 TB/s but tops out at 40-80 GB per device. GPUs are throughput machines: they win when the same operation runs across enormous amounts of data with little branching — exactly the profile of the FFTs and dense linear algebra at the heart of plane-wave DFT.
The practical tension is clear: GPUs offer far more raw floating-point throughput and memory bandwidth, but far less memory capacity and weaker performance on serial or irregular sections.
Why Memory Bandwidth Dominates DFT
Plane-wave DFT is largely memory-bandwidth bound, not compute bound. The FFTs that transform wavefunctions between real and reciprocal space move large arrays through the processor repeatedly, and the rate at which data streams from memory usually limits performance more than peak FLOPS.
This is central to understanding the GPU advantage. HBM on a GPU delivers roughly an order of magnitude more bandwidth than DDR system memory on a CPU node. For the bandwidth-hungry inner loops of an SCF cycle, that gap can translate into real speedup — provided the problem is large enough to keep the device busy and fits in its limited memory.
When the CPU Can Come Out Ahead
Despite the GPU hype, plenty of real DFT work runs better, or more economically, on CPUs.
- Small systems. A unit cell with a handful of atoms cannot generate enough parallel work to saturate a GPU. The device sits mostly idle, and a CPU often finishes just as fast or faster.
- Many small independent jobs. Convergence sweeps, high-throughput screening of hundreds of small structures, and parameter scans parallelize trivially across CPU cores and nodes. Throughput per dollar can favor CPUs here.
- Memory-hungry runs that overflow the GPU. If a calculation needs more memory than the device offers and cannot be distributed cleanly across multiple cards, a large-RAM CPU node is the pragmatic choice.
- Serial-heavy or I/O-bound workflows. Post-processing, heavy file output, and setup-dominated runs see little GPU benefit.
When the GPU Can Come Out Ahead
- Large supercells and defect calculations (roughly 100 atoms and up) that saturate the FFT and linear-algebra kernels.
- Hybrid functionals (EXX), which are dominated by FFTs and map extremely well to GPU throughput.
- Ab-initio molecular dynamics with thousands of steps, where per-step cost compounds.
- Fewer, bigger jobs rather than many tiny ones.
The unifying theme: GPUs reward large, dense, uniform work. The bigger and more homogeneous the numerical problem, the better the return.
flowchart TD
A[Choose hardware] --> B{Atoms}
B -->|less than ~30| C[CPU]
B -->|greater than ~100| D[GPU]
B -->|30–100| E[Benchmark both]
A --> F{Many small jobs?}
F -->|Yes| C
A --> G{Hybrid / long AIMD?}
G -->|Yes| D
A --> H{Fits in GPU memory?}
H -->|No, cannot split| C
H -->|Yes| DHow Speedup Scales with System Size
Speedup depends on system size: small cells may see little or no gain — on a tiny cell the GPU can even be slower once overhead is counted — while large systems and FFT-heavy methods like hybrids benefit most.
Cost Per Simulation, Not Cost Per Hour
The most common budgeting mistake is comparing hourly hardware rates instead of cost per completed simulation. A GPU node bills at a higher hourly rate, but GPUs can be faster for some workloads, so the total cost can come out cheaper, depending on the job; benchmark your own system.
A simplified way to think about it:
$$ C_{\mathrm{sim}} = t_{\mathrm{wall}} \times r_{\mathrm{node}} $$where \(t_{\mathrm{wall}}\) is wall-clock hours and \(r_{\mathrm{node}}\) is the node hourly rate.
For a large supercell, GPUs can be faster for some workloads, so a GPU node that bills at a higher hourly rate can come out cheaper, depending on the job; benchmark your own system to find out. For a tiny cell such as bulk silicon, the math flips and the CPU is the economical choice.
The lesson: always evaluate total time-to-solution and total cost, weighted by how many jobs of each type you run.
A Practical Decision Framework
Use this as a starting checklist when deciding where to run a given workload.
- How big is the system? Under ~30 atoms leans CPU; over ~100 atoms leans GPU.
- How many jobs? Many small independent runs favor CPU throughput; a few large runs favor GPU.
- Does it fit in GPU memory? If not and it cannot be split across cards, use large-RAM CPU nodes.
- What method? Hybrids and long AIMD strongly favor GPU. Plain SCF scales with size.
- What matters more — throughput or turnaround? Screening campaigns want throughput; a single blocking result wants fastest turnaround.
A pragmatic real-world strategy is hybrid: run high-throughput small-system screening on CPUs, then promote the promising large candidates to GPU nodes for the expensive production calculations. For more on how the underlying engines are built and optimized for each target, see our computational engines overview and the companion post on GPU acceleration for Quantum ESPRESSO.
Validating Your Own Numbers
Vendor slides and generic benchmarks rarely match your specific systems, pseudopotentials, and convergence settings. Before committing a large budget:
- Pick two or three representative structures from your actual project.
- Run each on both CPU and GPU with identical inputs and convergence thresholds.
- Compare not just wall time but the end-of-run timing breakdown (
fft, diagonalization,h_psi) to see where the time goes.
The official Quantum ESPRESSO resources and user forum at quantum-espresso.org are the best source for version-specific performance notes and known scaling behavior.
Energy and Sustainability
Cost is not only measured in currency. GPUs can deliver more performance per watt on the large, dense workloads they suit, because a single high-throughput device can replace many CPU cores that would otherwise run for longer. Because GPUs can be faster for some workloads, the total energy drawn to reach the answer for a big supercell can be lower even though the GPU node’s instantaneous power draw is higher; benchmark your own system.
The caveat is the same as with cost: this holds only when the GPU is well utilized. A half-idle GPU wastes energy on hardware it is not using. For small systems, packing several jobs onto one device — or simply running them on CPUs — can be both cheaper and greener, depending on the job. As research groups face growing scrutiny over compute footprints, matching hardware to workload size is an easy, tangible efficiency win.
Mixed Fleets and Real Workflows
Most productive groups do not choose CPU or GPU; they run a mixed fleet and route each job to the right target. A typical materials-discovery pipeline illustrates this:
- Structure enumeration and pre-screening. Thousands of tiny relaxations, each cheap, embarrassingly parallel across CPU cores. CPUs often come out ahead on throughput and can come out cheaper, depending on the job.
- Candidate refinement. Medium supercells with tighter convergence. Either target works; decide by queue availability and cost per simulation.
- Production and properties. Large supercells, hybrid functionals, long molecular dynamics. GPUs can be faster for some of these workloads and can come out cheaper, depending on the job; benchmark your own system.
Routing rules can be as simple as an atom-count threshold: below roughly 30 atoms go to CPU, above roughly 100 atoms go to GPU, and benchmark the grey zone in between. Automating this routing means researchers never think about hardware — the workflow places each job where it runs most economically.
Run it on Simatra
Simatra runs Quantum ESPRESSO on GPU-accelerated clusters using our GPU-Opt-V2 instances, so you can compare CPU and GPU cost-per-simulation on your own structures without buying hardware. You get both the Quantum ESPRESSO engine and our native KRONOS engine (a C++20, GPL-3.0 DFT code with CUDA, HIP, and Metal backends), described on our computational engines page. Request early access through our contact page.