Integrating HPX into existing applications

Having your application work with HPX is unfortunately not as simple as just linking against it. However it can be rather straightforward or rather complex based on the type of application that is trying to be integrated. The complexity derives from the overall design of the application. If the application was designed to be parallel, then integrating should be relatively straightforward. However HPX is not some magic wand that will make your application work in parallel. Applications that are serial or that rely too heavily on global variables will have a more difficult time in integrating. Most parallel applications have already identified the sections of code that do the most work and have abstracted them out to use the parallel library of their choice.

One of the big advantages of HPX is the concept of moving work to data. Data-heavy applications can use components to create remote objects that encapsulate that data, and call methods on these component-objects. Computation-heavy applications (which is the one I have the most experience with) do not care so much about moving work to data, but instead try to get as much parallel computation done as possible. HPX futures provide a nice tool for accomplishing this. Using futures, one can set up a lot of work to be done, fire it off and wait for them to be finished. HPX takes care of creating the threads, moving the work across node boundaries, and making sure the calling thread suspends when it wants the value from a future that is still executing. A lot of boring code that you don’t need to write. The one caveat is that for any function you wrap with a future, any parameters of those functions need to be serializable. This can be a rather complicated procedure if the data structures are complex. HPX uses Boost::Serialization for the serialization of the data to be used in futures. That really is the hardest part, because once the serialization functions are completed, you can use futures anywhere in your code. If you plan on only running on an SMP machine, then HPX never calls the serialization functions and they may be blank (but the signatures are still required).

The next stumbling block to integrating HPX is having it actually link against your program. If your application uses a CMake build system, you can set the CMake Module Path to the path where HPX has the FindHPX.cmake module. Here is a code snippet that is from my application:



      MESSAGE("HPX was found.")

Now to actually build the application you should have a code snippet similar to this in your CMakeLists.txt file:

        SOURCES ${your_app_SRCS}
    add_executable(your_app ${your_app_SRCS})

When you configure your application, all you need to do is set the HPX_INSTALL_DIR variable to point to the installation of HPX! Now all you have to do is type ‘make’ and the application should build under HPX.

If you do not use CMake, you can still build against HPX but you should refer to the HPX documentation on How to Build HPX Applications with pkg-config.

Those two things, the serialization and actually integrating with HPX, were the biggest stumbling blocks that I encountered when trying to integrate HPX. For an idea on how to integrate HPX constructs into your application, you should take a look at some of the examples that HPX includes.

GD Star Rating
Integrating HPX into existing applications, 5.0 out of 5 based on 2 ratings
    This entry was posted in Applications and tagged , , by Phillip LeBlanc. Bookmark the permalink.

    About Phillip LeBlanc

    Phillip LeBlanc is an undergraduate researcher at the Center of Computation and Technology (CCT) at Louisiana State University. He works on a chess application/benchmark which utilizes parallel processing and his research interests include integrating HPX with his chess application. He has been working at CCT for 4 years.

    Leave a Reply

    Your email address will not be published. Required fields are marked *