HPX: a C++ standard library for parallelism that extends to distributed systems

What HPX is for, and who it is not for

HPX is a C++ Standard Library for Concurrency and Parallelism. It implements all of the corresponding facilities as defined by the C++ Standard, and additionally implements functionalities proposed as part of the ongoing C++ standardization process. The stated goal is a programming model for conventional systems such as classic Linux based Beowulf clusters or multi-socket highly parallel SMP nodes. The README describes the API as modeled after C++11/14/17/20/23 interfaces and as adhering to Boost programming guidelines.

The important word is distributed. Most C++ concurrency libraries stop at the process boundary. HPX extends the standard APIs to the distributed case, which is why the README claims unified syntax and semantics for local and remote operations. If your problem is one machine and a few dozen threads, that extension buys you nothing. If your problem is a cluster and you want futures, dataflow synchronization and parallel algorithms to behave the same whether the work lands on the local node or a remote one, the project is aimed at you.

The README also states HPX is the first fully functional implementation of the ParalleX execution model, and that it has been designed for systems of any scale, from hand-held devices to very large scale systems. Treat that as an intent statement rather than a deployment claim. The examples directory tells you more about the practical targets: jacobi, sheneos, 1d_stencil, interpolate1d, random_mem_access, nqueen. Those are numeric and simulation kernels, not web services.

How the runtime unifies local and remote work

The mechanism visible from the repository is a runtime system plus a component model. The top level holds components/, libs/, tools/, init/, wrap/ and a large examples/ tree. The README describes a rich set of runtime services, a performance counter framework that can enable runtime adaptivity, and futures-based synchronization. The README does not describe the internal scheduling algorithm, so any claim about how tasks are placed would be invention.

What can be said is the shape of the API. HPX exposes futures and dataflow, and the README says it enables fully asynchronous code using hundreds of millions of threads. Those are not OS threads; the runtime multiplexes them. The same future type is used for local and remote work, which is the core design decision. Remote operations are expressed through actions and components, and the examples/hello_world_component directory is the canonical entry point for that model.

The performance counter framework is the part most teams underestimate. It exposes counters that let a program observe its own runtime state and adapt. That is unusual in a C++ library of this kind, and it is also the source of coupling: if you use the counters, you depend on HPX's runtime internals more deeply than if you only use algorithms and futures.

Modularity is a stated design goal. The README says the project wants a very modular and well designed runtime system architecture which would allow porting the implementation onto new computer system architectures. The libs/ directory, split into many subdirectories, is consistent with that. It also means a source build touches a lot of targets.

Installing HPX and running a first example

The README does not give a package manager one-liner. It points to the latest released version on the GitHub releases page, to a quick start guide at docs.hpx.dev/latest/html/quickstart.html, and to detailed build instructions at docs.hpx.dev/latest/html/manual/building_hpx.html. The repository carries CMakeLists.txt, CMakePresets.json, CTestConfig.cmake, a cmake/ directory and a conanfile.py, so both a direct CMake build and a Conan-based build are represented in the tree. Use the quick start page for the exact configure flags rather than guessing them.

A source build is large. If you only want to try the API, prefer a released tarball over the master branch, which the README explicitly says can contain new bugs despite efforts to keep it stable.

The examples tree is the fastest way to see the model once you have a build. The quickstart example is the smallest demonstration of the API surface. The documentation pages linked from the README give the configure and build commands for your platform; the README itself does not list them.

For the distributed case, the examples/hello_world_component directory shows the component and action pattern. That example is the one to read before writing your own distributed code, because it exercises the local and remote path with the same source.

The README also points to a book, Parallel C++: Efficient and Scalable High-Performance Parallel Programming Using HPX, with code examples in a separate repository. For a library with this much surface area, that is a more realistic starting point than reading headers.

The cost of a distributed runtime you may not need

The clearest limitation is scope. HPX is a runtime, not a header-only utility. Adopting it means your build, your startup and shutdown sequence, and your error handling all live inside HPX's model. The examples/startup_shutdown directory exists precisely because that lifecycle is something you have to get right.

Build cost is the second constraint. The repository is organized into many libraries under libs/, with a components/ tree and a wrap/ directory for external integration. A source build compiles a large amount of C++ and is not a five-minute operation. If your team is not already comfortable with CMake and toolchain configuration, that is a real barrier.

Third, the distributed extension only pays off when you actually run across nodes. A single-process program that uses HPX futures and parallel algorithms gains the API but pays the runtime's initialization and scheduling overhead. For that case, the standard library's own parallel algorithms or a lighter task library are the better fit.

Finally, the README says the project uses real-world applications to drive development and to converge on a stable API. That is honest about the project's nature: the API is converging, not frozen. The release history supports this. v1.10.0 shipped in May 2024, v1.11.0 in June 2025, with a release candidate a few weeks earlier. If you need long-term API stability guarantees, check the release notes for each version before upgrading rather than assuming compatibility.

HPX against oneTBB and raw standard threads

oneTBB is the comparison people search for, and the difference is architectural. oneTBB is a task-based parallelism library for a single process. It gives you parallel algorithms, task groups and concurrent containers, and it does not model remote execution. HPX starts from the same place, the C++ standard facilities, and then extends the same APIs to the distributed case. If your workload fits in one address space, oneTBB is the smaller dependency and the shorter build.

The second alternative is the C++ standard library itself. HPX implements the standard concurrency and parallelism facilities, so for code that only uses std::thread, std::async and the parallel algorithms, the standard library is already there. The reason to move to HPX is the parts the standard does not cover: futures that work across nodes, dataflow synchronization, actions and components, and the performance counter framework.

A third option worth naming is writing your own MPI plus threads layer. That is the approach HPX is positioned against. The README's claim of unified syntax and semantics for local and remote operations is exactly the pain that a hand-rolled MPI layer creates. Whether HPX's abstraction is worth its runtime is a judgement about your team and your codebase, not something the documentation settles.

Maintenance, licensing and what to check before upgrading

The repository is not archived and the last push was on 2026-09-23. Releases are infrequent but real: v1.11.0 on 2025-06-29, v1.10.0 on 2024-05-29. That cadence means upgrade cost is concentrated in the jump between minor versions, and the release notes are the place to look. The README does not document a rollback procedure, so plan your own.

On licensing, HPX is distributed under the Boost Software License 1.0, identified as BSL-1.0 in the repository and in the README header. The README points to LICENSE_1_0.txt in the repository. BSL-1.0 is a permissive licence, but the README does not discuss patent terms, contributor agreements or the implications of the project's status as a member project of the High-Performance Software Foundation, and it does not state the copyright holder's position on redistribution beyond the licence text itself. Read LICENSE_1_0.txt and, if it matters to your organisation, get your own legal review rather than relying on a summary.

Governance is documented. The README describes HPX as a meritocratic, consensus-based community project and links a governance document at hpx.dev/documents/governance/. Support routes are listed in .github/SUPPORT.md, and the README directs questions to StackOverflow with the hpx tag. For a project of this size, those are the channels to use before filing an issue.

Editorial conclusion

Adopt HPX when you need one API for local and remote parallelism and your team already writes modern C++ for HPC or distributed systems. Do not adopt it if you only need std::thread, OpenMP, or oneTBB inside a single process; the distributed runtime is overhead you will not use. Before committing, verify the build works with your compiler and CMake version against the quick start and building_hpx pages, and check the release notes for v1.11.0 to confirm the modules and API surface you depend on. The repository was last pushed on 2026-09-23, so check the CDash dashboard before you pin to master.

Frequently asked questions

Official sources

1. License: BSL-1.0
2. Project website
3. README
4. Releases
5. TheHPXProject/hpx on GitHub