LIKWID for Linux performance counters and CPU benchmarking

What LIKWID Measures on Linux

LIKWID addresses a specific problem in performance-oriented programming: turning low-level processor events into measurements that can guide optimization. It targets developers who need to inspect hardware performance counters, understand CPU placement, control where threaded applications run, and compare small CPU kernels. The suite is primarily written in C and is intended for Linux, with support listed for Intel, AMD, ARMv8, and POWER9 processors. The README also lists additional support for Nvidia and AMD GPUs.

The tools divide the work into several focused areas. `likwid-perfctr` configures and reads hardware performance counters, while `likwid-topology` reports thread, cache, and NUMA layout. `likwid-pin` assigns a threaded application to selected processors, and `likwid-bench` provides a microbenchmarking platform for CPU architectures. Other utilities cover energy information, frequency control, MPI launch wrappers, feature inspection, cache eviction, and timeline plotting. This makes LIKWID a collection rather than a single profiler. A team may use one command for a counter investigation and another for topology or placement work.

The distinction matters. LIKWID does not present itself as a visual application profiler with a single report format. Its documentation centers on command line applications, hardware counters, topology files, marker APIs, and benchmark code. The examples directory contains C, Fortran, Lua, and GPU-related marker API files, which indicates that application instrumentation is also part of the project rather than an afterthought.

Inside the LIKWID Toolset and Counter Flow

The architecture visible in the repository is tool-oriented. The top-level Makefile includes `config.mk`, compiler-specific files, configuration checks, and generated defines. It defines source, documentation, group, filter, make, and example directories, then builds executables from the C and Pascal-related source paths described in the Makefile comments. This is a source-build project rather than a package that the README presents as a one-command installation.

For measurement, the documented flow begins with selecting the right performance group and counter configuration. `likwid-perfctr` handles configuration and readout. The repository contains `groups/` and `filters/`, which correspond to LIKWID's performance event definitions and processing logic. The README's supported architecture list includes Intel families from Atom through SapphireRapids and EmeraldRapids, AMD families from K8 through Zen4, ARMv7 and ARMv8 variants, and experimental POWER8 and POWER9 support. This breadth is a strength for portable optimization work, but it also means that support should be checked against the exact CPU generation and event definitions.

Topology is a separate step. `likwid-topology` prints hardware threads, caches, and NUMA information. The README shows a Skylake example with one socket, four cores, two threads per core, and cache groups that reflect shared cache resources. `likwid-genTopoCfg` can dump topology information to a file, which is useful when measurements need to refer to a recorded machine layout. `likwid-memsweeper` handles NUMA-domain cache effects, while `likwid-pin` controls placement for pthread, Intel OpenMP, and GCC OpenMP applications. The suite therefore separates measurement from the system facts that determine where a workload runs.

Application-level integration is also documented through marker APIs. The examples include `C-markerAPI.c`, `C-likwidAPI.c`, `C-internalMarkerAPI.c`, `F-markerAPI.F90`, `Lua-likwidAPI.lua`, and GPU marker examples. These files indicate that an application can mark regions or call the library, allowing LIKWID-related instrumentation to be integrated into a larger program. The README does not provide a complete end-to-end API tutorial, so the exact marker semantics must be taken from the relevant example and documentation.

LIKWID Build and First CPU Use

The README directs users to the release archive and gives a source-build sequence. The quick installation uses the stable release variable, downloads the archive, edits `config.mk`, builds with `make`, and installs with elevated permissions. The installation step includes `sudo` because the access daemon must be installed with appropriate permissions.

VERSION=stable
wget http://ftp.fau.de/pub/likwid/likwid-$VERSION.tar.gz
tar -xaf likwid-$VERSION.tar.gz
cd likwid-*
vi config.mk
make
sudo make install

The `config.mk` edit is not optional for every target. For ARM builds, the README says to change `COMPILER` to `GCCARMv8` or `ARMCLANG`, with ARMCLANG marked experimental. For POWER builds, it says to use `GCCPOWER` or `XLC`, also marked experimental. Nvidia and AMD GPU support require separate build-time switches: `NVIDIA_INTERFACE=true` or `ROCM_INTERFACE=true`, with additional variables adjusted when necessary.

After installation, the first low-risk use is to inspect the machine before measuring it. Run the topology tool and compare its thread, cache, and NUMA output with the process placement intended for the application.

likwid-topology

The README gives a Skylake example in which four cores share one socket and each core has two hardware threads. The output also shows cache groups at each cache level. That result is an example, not a claim about every system. On a multi-socket or nonuniform machine, the actual output must be read for that host. Once the placement is understood, use `likwid-perfctr` with the performance group and event configuration appropriate to the processor and code path. The README does not provide a complete first measurement invocation, so it would be incorrect to invent one here.

Architecture Support and Build Boundaries

LIKWID's architecture list is broad, but support is not uniform. Intel and AMD coverage includes many named processor generations, from older Intel Atom, Pentium M, and Core2 systems to SapphireRapids and EmeraldRapids, and from AMD K8 and K10 through Zen4. ARM support includes ARMv7, ARMv8, Marvell Thunder X2, Fujitsu A64FX, Arm Neoverse N1 and V1, HiSilicon TSV110, and Apple M1 on Linux.

The qualification is important. The README states that ARMv7 and POWER8/9 support exists, but that there is currently no test machine available to test them properly. POWER is also labeled experimental in the supported architectures section. Nvidia and AMD GPU support is listed, while the build instructions make both interfaces optional. These statements limit how confidently a project can treat LIKWID as uniformly portable across the entire matrix.

The build system reflects that variation. Compiler selection is part of the build configuration, and GPU interfaces require explicit configuration variables. The central Makefile includes compiler-specific make fragments and generated configuration defines, so a build can differ not only by CPU architecture but also by compiler and enabled device interface. A deployment process should therefore preserve the selected `config.mk` values alongside the built binary if measurements must be reproduced.

The suite also includes `likwid-setFrequencies` and `likwid-sysFeatures` for frequency and system-setting tasks, but several of these tools have narrower platform boundaries. Frequency control is documented as x86 only, and `likwid-features` is also x86 only. `likwid-sysFeatures` is described as experimental. These restrictions make LIKWID less uniform than its long architecture list may initially suggest.

LIKWID Alternatives and Choosing the Right Measurement Model

Another alternative is a vendor-specific tool or a conventional application profiler. Such tools may offer a graphical timeline or source-level workflow that LIKWID's command line suite does not emphasize. LIKWID is more directly aligned with engineers who already know which hardware event or architectural question they want to investigate and need a repeatable command line measurement. Conversely, a vendor tool may be preferable when its supported event model is explicitly validated for one CPU generation, or when visual reports are the main requirement.

LIKWID is the wrong choice if the goal is only to launch an MPI application, inspect source lines, or generate an application-wide flame graph. `likwid-mpirun` is a wrapper for launching supported MPI and hybrid MPI/OpenMP applications, but that does not make LIKWID a replacement for every MPI launcher or profiler. The project also requires access to the relevant performance counters. If counter permissions, kernel settings, or device interfaces are unavailable, installation success alone does not guarantee usable measurements.

For microbenchmarks, `likwid-bench` is the more relevant component than the counter reader. Its presence makes LIKWID useful for controlled CPU experiments, but the repository README does not document the full benchmark syntax or methodology in the excerpt. The choice should therefore follow the measurement artifact you need: LIKWID groups and counters for hardware questions, topology and pinning for placement questions, and `likwid-bench` for its dedicated microbenchmark platform.

Operational Limits of LIKWID

The most immediate operational limit is counter availability. LIKWID can configure and read hardware performance counters, but the exact event set depends on the processor, device, kernel, permissions, and build configuration. The README lists wide architecture support, yet it does not claim that every event works identically on every listed processor. An unavailable or inaccessible counter can therefore limit a measurement even when the tool builds and starts.

Topology and pinning also affect interpretation. On a system with SMT, several hardware threads can share execution resources and cache levels. The example output shows threads grouped by core and cache groups, which illustrates why a counter result cannot be interpreted without the placement context. `likwid-pin` can assign pthread, Intel OpenMP, and GCC OpenMP applications to dedicated processors, but pinning changes the execution conditions and should be treated as part of the experiment rather than as a transparent optimization step.

GPU support is optional at build time. The README requires `NVIDIA_INTERFACE` or `ROCM_INTERFACE` to be set to `true`, and it does not claim that every GPU workflow is automatically available in a default build. The project also contains an `README_ROCM.md`, which suggests ROCm-specific setup is documented separately. A team using AMD GPUs should read that file and verify the required interface variables before assuming the CPU-only build is enough.

Some advertised utility areas are experimental or platform-specific. POWER support lacks a proper test machine according to the README. `likwid-sysFeatures` is experimental, while `likwid-features` and `likwid-setFrequencies` are limited to x86. These are adoption boundaries. They do not make the suite unusable, but they do mean that platform support should be verified at the component level rather than inferred from the product's general description.

LIKWID Licensing, Maintenance, and Upgrade Work

LIKWID is identified as GPL-3.0, and the Makefile states that the program can be redistributed or modified under the terms of the GNU General Public License. The repository includes a `COPYING` file, which is the appropriate place to examine the license text. Any deployment that distributes modified LIKWID binaries or incorporates the software into a distributed product should account for the license obligations that apply to that use. This is a licensing consideration, not legal advice.

The repository is not archived. Its last push was on 2026-10-14, and the release list includes `v5.5.2`, released on 2026-08-19. These facts indicate recent repository activity and a recent release, but they do not guarantee compatibility with a particular kernel, compiler, CPU, or GPU. The release list also includes `v5.5.2rc5` and `v5.5.2rc4`, which are release candidates rather than the final `v5.5.2` entry. Production users should distinguish the final release from its candidates when selecting an upgrade.

Upgrades can affect more than the installed binary. `config.mk` controls compiler selection and optional interfaces, while the Makefile includes compiler-specific fragments and generated configuration definitions. If a host changes architecture, compiler, or GPU support, the build configuration should be checked again. The repository's `CHANGELOG`, `INSTALL`, `config.mk`, and architecture-specific README files are the relevant project files for reviewing a new release, rather than relying only on the command list in the main README.

Editorial conclusion

Adopt LIKWID when you need Linux command line access to hardware performance counters, topology inspection, process pinning, or architecture-focused microbenchmarks. Do not choose it as a general application profiler without checking its API and tool coverage. Verify first that your processor, GPU, operating system permissions, and selected build interfaces match the configuration you need; POWER and some GPU configurations are explicitly experimental or optional. For a CPU investigation, confirm that the relevant architecture group exists, run `likwid-topology` to understand thread placement, then validate one `likwid-perfctr` measurement against the counters available on the target machine.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. RRZE-HPC/likwid on GitHub