Our main focus for this release was the design and development of a coherent set of higher-level APIs exposing various types of parallelism to the application programmer. We introduced the concepts of an executor, which can be used to customize the where and when of execution of tasks in the context of parallelizing codes. We extended all APIs related to managing parallel tasks to support executors which gives the user the choce of either using one of the predefined executor types or to provide its own, possibly application specific, executor. We paid very close attention to align all of these changes with the existing C++ Standards documents or with the ongoing proposals for standardization.

This release is the first after our change to a new development policy. We switched all development to be strictly performed on branches only, all direct commits to our main branch (master) are prohibited. Any change has to go through a peer review before it will be merged to master. As a result the overall stability of our code base has significantly increased, the development process itself has been simplified. This change manifests itself in a large number of pull-requests which have been merged (please see below for a full list of closed issues and pull-requests). All in all for this release, we closed almost 100 issues and merged over 290 pull-requests. There have been over 1600 commits to the master branch since the last release.

General Changes

• We are moving into the direction of unifying managed and simple components. As such, the classes `hpx::components::component` and `hpx::components::component_base` have been added which currently just forward to the currently existing simple component facilities. The examples have been converted to only use those two classes.
• Added integration with the CircleCI hosted continuous integration service. This gives us constant and immediate feedback on the health of our master branch.
• The compiler configuration subsystem in the build system has been reimplemented. Instead of using Boost.Config we now use our own lightweight set of cmake scripts to determine the available language and library features supported by the used compiler.
• The API for creating instances of components has been consolidated. All component instances should be created using the hpx::new_ only. It allows to instantiate both, single component instances and multiple component instances. The placement of the created components can be controlled by special distribution policies. Please see the corresponding documentation outlining the use of hpx::new_.
• Introduced four new distribution policies which can be used with many API functions which traditionally expected to be used with a locality id. The new distribution policies are:
  • hpx::default_distribution_policy which tries to place multiple component instances as evenly as possible.
  • hpx::colocating_distribution_policy which will refer to the locality where a given component instance is currently placed.
  • hpx::binpacking_distribution_policy which will place multiple component instances as evenly as possible based on any performance counter.
  • hpx::target_distribution_policy which allows to represent a given locality in the context of a distribution policy.
• The new distribution policies can now be also used with hpx::async. This change also deprecates hpx::async_colocated(id, …) which now is replaced by a distribution policy: hpx::async(hpx::colocated(id), …).
• The hpx::vector and hpx::unordered_map data structures can now be used with the new distribution policies as well.
• The parallel facility hpx::parallel::task_region has been renamed to hpx::parallel::task_block based on the changes in the corresponding standardization proposal N4411.
• Added extensions to the parallel facility hpx::parallel::task_block allowing to combine a task_block with an execution policy. This implies a minor breaking change as the hpx::parallel::task_block is now a template.
• Added new LCOs: hpx::lcos::latch and hpx::lcos::local::latch which semantically conform to the proposed std::latch (see N4399).
• Added performance counters exposing data related to data transferred by input/output (filesystem) operations (thanks to Maciej Brodowicz).
• Added performance counters allowing to track the number of action invocations (local and remote invocations).
• Added new command line options –hpx:print-counter-at and –hpx:reset-counters.
• The hpx::vector component has been renamed to hpx::partitioned_vector to make it explicit that the underlying memory is not contiguous.
• Introduced a completely new and uniform higher-level parallelism API which is based on executors. All existing parallelism APIs have been adapted to this. We have added a large number of different executor types, such as a numa-aware executor, a this-thread executor, etc.
• Added support for the MingW toolchain on Windows (thanks to Eric Lemanissier).
• HPX now includes support for APEX, (Autonomic Performance Environment for eXascale). APEX is an instrumentation and software adaptation library that provides an interface to TAU profiling / tracing as well as runtime adaptation of HPX applications through policy definitions. For more information and documentation, please see https://github.com/khuck/xpress-apex. To enable APEX at configuration time, specify -DHPX_WITH_APEX=On. To also include support for TAU profiling, specify -DHPX_WITH_TAU=On and specify the -DTAU_ROOT, -DTAU_ARCH and -DTAU_OPTIONS cmake parameters.
• We have implemented many more of the parallel algorithms. Please see IS#1141 for the list of all available parallel algorithms (thanks to Daniel Bourgeois and John Biddiscombe for contributing their work).

Breaking Changes

• We are moving into the direction of unifying managed and simple components. In order to stop exposing the old facilities, all examples have been converted to use the new classes. The breaking change in this release is that performance counters are now a hpx::components::component_base instead of hpx::components::managed_component_base.
• We removed the support for stackless threads. It turned out that there was no performance benefit when using stackless threads. As such, we decided to clean up our codebase. This feature was not documented.
• The CMake project name has changed from ‘hpx’ to ‘HPX’ for consistency and compatibilty with naming conventions and other CMake projects. Generated config files go into <prefix>/lib/cmake/HPX and not <prefix>/lib/cmake/hpx.
• The macro HPX_REGISTER_MINIMAL_COMPONENT_FACTORY has been deprecated. Please use HPX_REGISTER_COMPONENT instead. The old macro will be removed in the next release.
• The obsolete distributing_factory and binpacking_factory components have been removed. The corresponding functionality is now provided by the hpx::new_ API function in conjunction with the hpx::default_layout and hpx::binpacking distribution policies (hpx::default_distribution_policy and hpx::binpacking_distribution_policy)
• The API function hpx::new_colocated has been deprecated. Please use the consolidated API hpx::new_ in conjunction with the new hpx::colocated distribution policy (hpx::colocating_distribution_policy) instead. The old API function will still be available for at least one release of HPX if the configuration variable HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY is enabled.
• The API function hpx::async_colocated has been deprecated. Please use the consolidated API hpx::async in conjunction with the new hpx::colocated distribution policy (hpx::colocating_distribution_policy) instead. The old API function will still be available for at least one release of HPX if the configuration variable HPX_WITH_COLOCATED_BACKWARDS_COMPATIBILITY is enabled.
• The obsolete remote_object component has been removed.
• Replaced the use of Boost.Serialization with our own solution. While the new version is mostly compatible with Boost.Serialization, this change requires some minor code modifications in user code. For more information, please see the corresponding announcement on the hpx-users@stellar.cct.lsu.edu mailing list.
• The names used by cmake to influence various configuration options have been unified. The new naming scheme relies on all configuration constants to start with HPX_WITH_…, while the preprocessor constant which is used at build time starts with HPX_HAVE_…. For instance, the former cmake command line -DHPX_MALLOC=… now has to be specified a -DHPX_WITH_MALLOC=… and will cause the preprocessor constant HPX_HAVE_MALLOC to be defined. The actual name of the constant (i.e. MALLOC) has not changed. Please see the corresponding documentation for more details (CMake Variables used to configure HPX).
• The get_gid() functions exposed by the component base classes hpx::components::server::simple_component_base, hpx::components::server::managed_component_base, and hpx::components::server::fixed_component_base have been replaced by two new functions: get_unmanaged_id() and get_id(). To enable the old function name for backwards compatibility, use the cmake configuration option HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY=On.
• All functions which were named get_gid() but were returning hpx::id_type have been renamed to get_id(). To enable the old function names for backwards compatibility, use the cmake configuration option HPX_WITH_COMPONENT_GET_GID_COMPATIBILITY=On.

How to Download HPX V0.9.11:

If you would like to access the code directly, please clone the git repository here. Please refer to the file README.rst in the root directory inside the downloaded archives or to the documentation for more information about how to get started.

Bug reports via email (hpx-users@cct.lsu.edu), our ticket submission system, or directly through our IRC channel (#ste||ar at Freenode) are welcome.

The development of HPX is supported by U.S. National Science Foundation through awards 1117470 (APX), 1240655 (STAR), 1447831 (PXFS), and 1339782 (STORM), the U.S. Department of Energy (DoE) through the award DE-SC0008714 (XPRESS), and the Bavarian Research Foundation (Bayerische Forschungsstiftung, Germany) through the grant AZ-987-11. In addition we utilize computer resources through allocations from LSU HPC, XSEDE, and the Gauss Center for Supercomputing.