Skip to main content

Computer Language Benchmarks Game

The Computer Language Benchmarks Game compares programming-language implementations on small algorithmic tasks, reporting runtime, memory, and source size. It offers cross-language performance intuition but should not be extrapolated to whole applications.

The Computer Language Benchmarks Game (CLBG) is a long-standing public project that compares how fast and memory-efficient different programming languages are on a set of small, well-defined algorithmic problems. It is one of the most cited sources for cross-language performance intuition, though it is best understood as comparing specific implementations rather than languages in the abstract.

The suite consists of about ten micro-programs such as n-body simulation, spectral norm, mandelbrot set, k-nucleotide, regex matching, binary trees, and fasta generation. Each task has a precise specification and reference output, so every language implements the same algorithm. Contributors submit optimized programs in dozens of languages, from C and Rust to Python, Java, Go, and JavaScript.

What It Measures

For each program and language, CLBG reports CPU runtime (the headline number), peak memory usage, CPU load across cores, and source code size in gzipped bytes as a rough proxy for verbosity. Presenting all four lets readers weigh raw speed against memory cost and developer ergonomics rather than ranking on speed alone.

Methodology

Programs are compiled and run on a fixed reference machine with specified compiler versions and flags. Each task uses a defined input size, and times are measured over repeated runs. The project publishes the exact source, build commands, and hardware so results are reproducible. Submissions are community-contributed and curated, with the fastest correct program per language typically featured.

How to Interpret Results

Treat CLBG as comparing tuned implementations on micro-tasks, not whole languages or applications. Compiled systems languages cluster near the top on speed; managed and dynamic languages trade speed for productivity. Look at memory and source size alongside runtime — a language a few times slower but far terser may suit a project better. Never extrapolate a single micro-benchmark to overall application performance.

Limitations

The tasks are tiny, CPU-bound kernels that ignore I/O, concurrency at scale, libraries, startup time, and real-world code structure. Results reflect expert-optimized, often non-idiomatic code, so they overstate what typical programs achieve. Hand-tuning effort varies by language community, biasing comparisons. The benchmark says little about maintainability, ecosystem, or the factors that usually dominate real engineering decisions.