HPX V0.9.0 (Jul 5, 2012)#

We have had roughly 800 commits since the last release and we have closed approximately 80 tickets (bugs, feature requests, etc.).

General changes#

  • Significant improvements made to the usability of HPX in large-scale, distributed environments.

  • Renamed hpx::lcos::packaged_task to hpx::lcos::packaged_action to reflect the semantic differences to a packaged_task as defined by the C++11 Standard.

  • HPX now exposes hpx::thread which is compliant to the C++11 std::thread type except that it (purely locally) represents an HPX thread. This new type does not expose any of the remote capabilities of the underlying HPX-thread implementation.

  • The type hpx::lcos::future is now compliant to the C++11 std::future<> type. This type can be used to synchronize both, local and remote operations. In both cases the control flow will ‘return’ to the future in order to trigger any continuation.

  • The types hpx::lcos::local::promise and hpx::lcos::local::packaged_task are now compliant to the C++11 std::promise<> and std::packaged_task<> types. These can be used to create a future representing local work only. Use the types hpx::lcos::promise and hpx::lcos::packaged_action to wrap any (possibly remote) action into a future.

  • hpx::thread and hpx::lcos::future are now cancelable.

  • Added support for sequential and logic composition of hpx::lcos::futures. The member function hpx::lcos::future::when permits futures to be sequentially composed. The helper functions hpx::wait_all, hpx::wait_any, and hpx::wait_n can be used to wait for more than one future at a time.

  • HPX now exposes hpx::apply and hpx::async as the preferred way of creating (or invoking) any deferred work. These functions are usable with various types of functions, function objects, and actions and provide a uniform way to spawn deferred tasks.

  • HPX now utilizes hpx::util::bind to (partially) bind local functions and function objects, and also actions. Remote bound actions can have placeholders as well.

  • HPX continuations are now fully polymorphic. The class hpx::actions::forwarding_continuation is an example of how the user can write is own types of continuations. It can be used to execute any function as an continuation of a particular action.

  • Reworked the action invocation API to be fully conformant to normal functions. Actions can now be invoked using hpx::apply, hpx::async, or using the operator() implemented on actions. Actions themselves can now be cheaply instantiated as they do not have any members anymore.

  • Reworked the lazy action invocation API. Actions can now be directly bound using hpx::util::bind by passing an action instance as the first argument.

  • A minimal HPX program now looks like this:

    #include <hpx/hpx_init.hpp>
    
    int hpx_main()
    {
        return hpx::finalize();
    }
    
    int main()
    {
        return hpx::init();
    }
    

    This removes the immediate dependency on the Boost.Program_options library.

    Note

    This minimal version of an HPX program does not support any of the default command line arguments (such as –help, or command line options related to PBS). It is suggested to always pass argc and argv to HPX as shown in the example below.

  • In order to support those, but still not to depend on Boost.Program_options, the minimal program can be written as:

    #include <hpx/hpx_init.hpp>
    
    // The arguments for hpx_main can be left off, which very similar to the
    // behavior of ``main()`` as defined by C++.
    int hpx_main(int argc, char* argv[])
    {
        return hpx::finalize();
    }
    
    int main(int argc, char* argv[])
    {
        return hpx::init(argc, argv);
    }
    
  • Added performance counters exposing the number of component instances which are alive on a given locality.

  • Added performance counters exposing then number of messages sent and received, the number of parcels sent and received, the number of bytes sent and received, the overall time required to send and receive data, and the overall time required to serialize and deserialize the data.

  • Added a new component: hpx::components::binpacking_factory which is equivalent to the existing hpx::components::distributing_factory component, except that it equalizes the overall population of the components to create. It exposes two factory methods, one based on the number of existing instances of the component type to create, and one based on an arbitrary performance counter which will be queried for all relevant localities.

  • Added API functions allowing to access elements of the diagnostic information embedded in the given exception: hpx::get_locality_id, hpx::get_host_name, hpx::get_process_id, hpx::get_function_name, hpx::get_file_name, hpx::get_line_number, hpx::get_os_thread, hpx::get_thread_id, and hpx::get_thread_description.

Bug fixes (closed tickets)#

Here is a list of the important tickets we closed for this release:

  • Issue #71 - GIDs that are not serialized via handle_gid<> should raise an exception

  • Issue #105 - Allow for hpx::util::functions to be registered in the AGAS symbolic namespace

  • Issue #107 - Nasty threadmanger race condition (reproducible in sheneos_test)

  • Issue #108 - Add millisecond resolution to HPX logs on Linux

  • Issue #110 - Shutdown hang in distributed with release build

  • Issue #116 - Don’t use TSS for the applier and runtime pointers

  • Issue #162 - Move local synchronous execution shortcut from hpx::function to the applier

  • Issue #172 - Cache sources in CMake and check if they change manually

  • Issue #178 - Add an INI option to turn off ranged-based AGAS caching

  • Issue #187 - Support for disabling performance counter deployment

  • Issue #202 - Support for sending performance counter data to a specific file

  • Issue #218 - boost.coroutines allows different stack sizes, but stack pool is unaware of this

  • Issue #231 - Implement movable boost::bind

  • Issue #232 - Implement movable boost::function

  • Issue #236 - Allow binding hpx::util::function to actions

  • Issue #239 - Replace hpx::function with hpx::util::function

  • Issue #240 - Can’t specify RemoteResult with lcos::async

  • Issue #242 - REGISTER_TEMPLATE support for plain actions

  • Issue #243 - handle_gid<> support for hpx::util::function

  • Issue #245 - *_c_cache code throws an exception if the queried GID is not in the local cache

  • Issue #246 - Undefined references in dataflow/adaptive1d example

  • Issue #252 - Problems configuring sheneos with CMake

  • Issue #254 - Lifetime of components doesn’t end when client goes out of scope

  • Issue #259 - CMake does not detect that MSVC10 has lambdas

  • Issue #260 - io_service_pool segfault

  • Issue #261 - Late parcel executed outside of pxthread

  • Issue #263 - Cannot select allocator with CMake

  • Issue #264 - Fix allocator select

  • Issue #267 - Runtime error for hello_world

  • Issue #269 - pthread_affinity_np test fails to compile

  • Issue #270 - Compiler noise due to -Wcast-qual

  • Issue #275 - Problem with configuration tests/include paths on Gentoo

  • Issue #325 - Sheneos is 200-400 times slower than the fortran equivalent

  • Issue #331 - hpx::init and hpx_main() should not depend on program_options

  • Issue #333 - Add doxygen support to CMake for doc toolchain

  • Issue #340 - Performance counters for parcels

  • Issue #346 - Component loading error when running hello_world in distributed on MSVC2010

  • Issue #362 - Missing initializer error

  • Issue #363 - Parcel port serialization error

  • Issue #366 - Parcel buffering leads to types incompatible exception

  • Issue #368 - Scalable alternative to rand() needed for HPX

  • Issue #369 - IB over IP is substantially slower than just using standard TCP/IP

  • Issue #374 - hpx::lcos::wait should work with dataflows and arbitrary classes meeting the future interface

  • Issue #375 - Conflicting/ambiguous overloads of hpx::lcos::wait

  • Issue #376 - Find_HPX.cmake should set CMake variable HPX_FOUND for out of tree builds

  • Issue #377 - ShenEOS interpolate bulk and interpolate_one_bulk are broken

  • Issue #379 - Add support for distributed runs under SLURM

  • Issue #382 - _Unwind_Word not declared in boost.backtrace

  • Issue #387 - Doxygen should look only at list of specified files

  • Issue #388 - Running make install on an out-of-tree application is broken

  • Issue #391 - Out-of-tree application segfaults when running in qsub

  • Issue #392 - Remove HPX_NO_INSTALL option from cmake build system

  • Issue #396 - Pragma related warnings when compiling with older gcc versions

  • Issue #399 - Out of tree component build problems

  • Issue #400 - Out of source builds on Windows: linker should not receive compiler flags

  • Issue #401 - Out of source builds on Windows: components need to be linked with hpx_serialization

  • Issue #404 - gfortran fails to link automatically when fortran files are present

  • Issue #405 - Inability to specify linking order for external libraries

  • Issue #406 - Adapt action limits such that dataflow applications work without additional defines

  • Issue #415 - locality_results is not a member of hpx::components::server

  • Issue #425 - Breaking changes to traits::*result wrt std::vector<id_type>

  • Issue #426 - AUTOGLOB needs to be updated to support fortran