Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/brakmic/hpx_projects

:zap: High-Performance-Computing with C++
https://github.com/brakmic/hpx_projects

boost c-plus-plus cplusplus cpp hpx

Last synced: about 2 months ago
JSON representation

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

Awesome Lists containing this project

README 

        
### 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