CPU vs GPU for DFT Calculations: Benchmarks and Guidance

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, shows an illustrative benchmark comparison, and gives practical guidance on when each option wins on both 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 translates fairly directly into speedup — provided the problem is large enough to keep the device busy and fits in its limited memory.

When the CPU Wins

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 Wins

• 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| D

An Illustrative Benchmark Comparison

The table below is illustrative and representative of plane-wave SCF behavior in Quantum ESPRESSO. It is not a set of official or guaranteed numbers; treat it as a directional guide. Assume a CPU node with 64 cores versus a node with 4 datacenter GPUs.

Notice the first row: on a tiny cell the GPU can actually be slower once overhead is counted. The advantage grows monotonically with system size and with FFT-heavy methods like hybrids.

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 if it finishes a large job in one-fifth the time, the total cost can be lower.

A simplified way to think about it:

where \(t_{\mathrm{wall}}\) is wall-clock hours and \(r_{\mathrm{node}}\) is the node hourly rate.

Consider the oxide supercell above. If a CPU node costs 3 units/hour and takes 7.5 hours, that is 22.5 units. If the GPU node costs 9 units/hour but finishes in 1.6 hours, that is 14.4 units — cheaper despite the higher rate, and you get your answer far sooner. For the tiny silicon cell, 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 generally deliver more performance per watt on the large, dense workloads they suit, because a single high-throughput device replaces many CPU cores that would otherwise run for longer. For a big supercell that finishes in one-fifth the wall time, the total energy drawn to reach the answer is often lower even though the GPU node’s instantaneous power draw is higher.

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 — is both cheaper and greener. 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 win on throughput and cost.
• 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 win decisively on both time and total cost.

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, delivering up to 5x faster convergence on large plane-wave workloads and supporting supercells up to roughly 2,000 atoms — 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. Start a free trial with $100 in credits at app.simatra.io.