/HPX_Projects

:zap: High-Performance-Computing with C++

Primary LanguageC++MIT LicenseMIT

HPX Projects

This is a collection of small demos showing different functionalities from HPX.

All parts are based on Visual C++ under VS 2015.

HPX version: 0.9.11

BOOST version: 1.60

HWLOC version: 1.11.0

The configuration procedure of HPX with Visual Studio is rather complex and can quickly lead to very confusing errors.

Therefore I'd recommend to use my small tutorial on building HPX under Windows.

For a more detailed explanation and examples you can read my article on HPX.

Configuration

To make the configuration of Project-Options easier I've extracted some default properties into a separate prop file.

I'm using the following system-variables to access Boost, HwLoc and HPX libraries:


BOOST_ROOT = C:\lib\boost
HWLOC_ROOT = C:\bin\hwloc
HPX_ROOT   = C:\bin\hpx

In my PATH there are some additional entries pointing at subdirectories inside the above roots:


%BOOST_ROOT%\lib
%HPX_ROOT%\bin

This is, of course, not mandatory and you can create your own paths. What's important is that you have the libs installed and accessible under some system-wide variables.

Visual Studio Project Properties

After having compiled and installed the libraries (boost, hpx & hwloc) you have to insert certain library and include paths. These settings will look like in the screenshot below. There's a separate properties-file with several defaults available so you can more easily adapt the project to your environment. The most important part will be the different library ROOTs.

Compilation

The compilation is straightforward. Just use the standard Debug/Release facilities.

Execution

Currently, the whole execution logic is packed into a single ugly source file. At least the participating objects and functions are defined over several cpp and hpp files. But soon I'll provide a better structure. The main focus will be on actions and components. This project already contains a few actions and a component implementing some (a)synchronous methods. There's also a separate DLL-Project available that defines another HPX-Component (SmallServer.dll) to be used in this demo. The output is console-based and currently looks like this:

The program's main is located in HpxTest_1.cpp which contains a special hpx_main function where HPX kicks in. To make the app aware of this additional main function we have to execute another HPX-function called hpx::init. Of course, this is not the only way to start an HPX app. There are several possibilities for different use-cases.

In our case the hpx::main contains a bunch of calls to other functions which utilize different functionalities from HPX.

  • Applying (a)synchronous actions.

In HPX actions are like wrappers that map to real functions. And it doesn't matter if they're available locally or on some other machine. In fact, HPX maintans its own registry for managing actions and components so you don't have to fiddle around with memory addressing. Instead, HPX assigns a globally unique id to a thing. Only this Id is needed to localize a thing. Also, HPX can move things around the global memory. For example, when there's no sufficient memory on a certain machine HPX can take some components and move them to other machine within the cluster. HPX does this by using parcels which are basically serialized functions and/or components. HPX also extends the standard C++ syntax for asynchronous function calling.

  • Continuations demo.

A continuation allows us to chain several functions together and forward their results down the chain.

  • Error handling in HPX

Asynchronous functions throw asynchronous errors. And in highly parallel systems errors are really hard to handle. But HPX keeps the complexity away by providing nice facilities for location-agnostic error handling.

  • Components

HPX supports remotely manageable components. In this demo part we initialize a component and call it's (a)synchronous methods to manipulate a number.

  • Components from DLLs

HPX also supports loading components from DLLs. In this example we have a SmallServer.dll that lives in a project of the same name.

Our client app HpxTest_1.exe should be able to load and execute exported methods from SmallServer.dll. This is done the standard way via #include "smallserver.h" where the needed function declarations & component exports are located. It's important to know that in this file no function definitions should be located. Any function definition in this header file will ultimately lead to weird dllimport errors. Put your function definitions into SmallServer.cpp. The import library file SmallServer.lib is located in the Output directory: x64/Debug respective x64/Release. HpxTest_1.exe needs this file for mapping to SmallServer-exports.

If you'd prefer some other location take care of properly setting the import-library paths in Project Settings.

License

MIT