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
tohpx::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
andhpx::lcos::local::packaged_task
are now compliant to the C++11std::promise<>
andstd::packaged_task<>
types. These can be used to create a future representing local work only. Use the typeshpx::lcos::promise
andhpx::lcos::packaged_action
to wrap any (possibly remote) action into a future.hpx::thread
andhpx::lcos::future
are now cancelable.Added support for sequential and logic composition of
hpx::lcos::future
s. The member functionhpx::lcos::future::when
permits futures to be sequentially composed. The helper functionshpx::wait_all
,hpx::wait_any
, andhpx::wait_n
can be used to wait for more than one future at a time.HPX now exposes
hpx::apply
andhpx::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 theoperator()
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
andargv
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 existinghpx::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
, andhpx::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 exceptionIssue #105 - Allow for
hpx::util::function
s to be registered in the AGAS symbolic namespaceIssue #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 actionsIssue #239 - Replace
hpx::function
withhpx::util::function
Issue #240 - Can’t specify RemoteResult with lcos::async
Issue #242 - REGISTER_TEMPLATE support for plain actions
Issue #243 -
handle_gid<>
support forhpx::util::function
Issue #245 -
*_c_cache code
throws an exception if the queried GID is not in the local cacheIssue #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
andhpx_main()
should not depend on program_optionsIssue #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 interfaceIssue #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 brokenIssue #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 ofhpx::components::server
Issue #425 - Breaking changes to
traits::*result
wrtstd::vector<id_type>
Issue #426 - AUTOGLOB needs to be updated to support fortran