Version 1.0 approaches! The STE||AR Group is proud to announce the release of HPX v0.9.99. This release is significant as HPX is nearly feature complete. Over the next several months the STE||AR Group will continue to test and polish HPX’s API and documentation. The feedback and experience gained from the community’s utilization this release will provide guidance on where to add the finishing touches for v1.0.

We would like to thank all the many people who have contributed to this release. This release incorporates nearly 1500 commits and has closed almost 400 tickets from collaborators all over the world. In this release we have introduced several important changes:

We have fixed a couple of issues in AGAS and the parcel layer which have caused hangs, segmentation faults at exit, and a slowdown of applications over time. Fixing those has significantly increased the overall stability and performance of distributed runs.

We have started to add parallel algorithm overloads based on the C++ Extensions for Ranges (N4560) proposal. This also includes the addition of projections to the existing algorithms. Please see IS#1668 for a list of algorithms which have been adapted to N4560.

We have implemented index-based parallel for-loops based on a corresponding standardization proposal (P0075R1). Please see IS#2016 for a list of available algorithms.

We have started to implement a new prototypical functionality with HPX.Compute which uniformly exposes some of the higher level APIs to heterogeneous architectures (currently CUDA). This functionality is an early preview and should not be considered stable. It may change considerably in the future.

We have pervasively added (optional) executor arguments to all API functions which schedule new work. Executors are now used throughout the code base as the main means of executing tasks.

Added hpx::make_future<R>(future<T> &&) allowing to convert a future of any type T into a future of any other type R, either based on default conversion rules of the embedded types or using a given explicit conversion function.

We finally finished the implementation of transparent migration of components to another locality. It is now possible to trigger a migration operation without ‘stopping the world’ for the object to migrate. HPX will make sure that no work is being performed on an object before it is migrated and that all subsequently scheduled work for the migrated object will be transparently forwarded to the new locality. Please note that the global id of the migrated object does not change, thus the application will not have to be changed in any way to support this new functionality. Please note that this feature is currently considered experimental. See IS#559 and PR#1966 for more details.

The hpx::dataflow facility is now usable with actions. Similarly to hpx::async, actions can be specified as an explicit template argument (hpx::dataflow<Action>(target, …)) or as the first argument (hpx::dataflow(Action(), target, …)). We have also enabled the use of distribution policies as the target for dataflow invocations. Please see IS#1265 and PR#1912 for more information.

Adding overloads of gather_here and gather_there to accept the plain values of the data to gather (in addition to the existing overloads expecting futures).

We have cleaned up and refactored large parts of the code base. This helped reducing compile and link times of HPX itself and also of applications depending on it. We have further decreased the dependency of HPX on the Boost libraries by replacing part of those with facilities available from the standard libraries.

Wherever possible we have removed dependencies of our API on Boost by replacing those with the equivalent facility from the C++11 standard library.

We have added new performance counters for parcel coalescing, file-IO, the AGAS cache, and overall scheduler time. Resetting performance counters has been overhauled and fixed.

We have introduced a generic client type hpx::components::client<> and added support for using it with hpx::async. This removes the necessity to implement specific client types for every component type without losing type safety. This deemphasizes the need for using the low level hpx::id_type for referencing (possibly remote) component instances. The plan is to deprecate the direct use of hpx::id_type in user code in the future.

We have added a special iterator which supports automatic prefetching of one or more arrays for speeding up loop-like code (see hpx::parallel::util::make_prefetcher_context()).

How to Download

For a complete list of new features and breaking changes please see our release notes. If you have any questions, comments, or exploits to report you can comment below, reach us on IRC (#stellar on Freenode), or email us at hpx-users@stellar.cct.lsu.edu. We value your input!