MPI Standalone Implementation - First Bits

[csegarragonz]

This PR is the first bit towards running standalone MPI applications #42 . In it I include a simple executor implementation for MPI methods. It consists of a single thread execution thread in a singleton thread pool. I also implement support to run both threadPool and endpoint either in the background or in the foreground (depending on where we want our program to hang).

As of now, the way to port an MPI application is to change the int main line for a custom function (faabric::executor::mpiFunc), and prepend a different main entrypoint (this could be wrapped in a macro).

To test the hello world program, from a fresh instance:

inv container.build-mpi-native

# outside the container
# modify the values in ./docker/mpi_native.env
./bin/run_mpi_native.sh

To-Do:

• Compilation of mpi_helloworld
• Execution of mpi_helloworld
• Scalability test of mpi_helloworld
• Regression test

After this gets merged in:

• Update the main issue tracker (Run and profile standalone MPI applications #42)
• Port the actual implementation of most MPI methods. ([MPI] Port the remaining MPI calls #51)
• Aggregate log files from all different workers in a shared directory ([MPI] Centralize Logging #50).

To be discussed:

• Running invoke from outside the container is a bit dodgy, migrate to standalone script?
• Wrap all code in a macro?

[Shillaker]

Modifying the global CMake context like this should be avoided where possible, as it's changing it for all targets, and can lead to hard-to-diagnose build issues if this produces a conflict (e.g. if someone has installed pistache natively and there are two versions available). The CMake docs advise against using link_directories unless absolutely necessary (https://cmake.org/cmake/help/latest/command/link_directories.html).

As it is, this is not technically related to pistache either, so if it was to make it in, it should live in the top-level CMake file.

Can you look at the grey box in the docs page and try the alternatives they list there?

[Shillaker]

Why do we need the modifications to the endpoint here? I would have thought we'd run the endpoint in the foreground or not run it at all. Is it needed for this native MPI stuff?

[csegarragonz]

The endpoint is currently used to bootstrap execution. This is, before instantiating the SingletonPool object that starts the thread pool, state server, and http endpoint, we make a call to the scheduler in examples/mpi_helloworld.cpp:35 this in turn loads the function defined in faabric::executor::mpiFunc and at this point we don't need the endpoint anymore.

If running the HTTP endpoint in the background is something we definately won't need down the road, then these changes may add complexity for a single call, but as previously mentioned they are needed for initialisation.

Alternatively, we could try and come up with a different bootstrapping scheme offline (that does not rely on the handling of http requests).

[Shillaker]

I can't see where the call to the endpoint is actually made. I can see that the scheduler is called, but I don't think the endpoint needs to be running for the scheduler to work. IIRC the endpoint is basically just an HTTP wrapper around the scheduler that doesn't do much else. What does the endpoint add in this case and where in mpi_helloworld.cpp is the endpoint actually used?

[csegarragonz]

You are completely right about this. I missunderstood some of the endpoint functionalities, I really don't need it at all. I will revert to the implementation in master.

[Shillaker]

Couple of minor requests

[Shillaker]

Nice, this looks relatively clean. Can you move faasm and faasm-toolchain to this version of Faabric to check they both still work after (or before) merging this?

[csegarragonz]

Here is faasm's and here the toolchain's. Should we merge those PRs?

Note that the toolchain one would not pass for some missmatch in the submodule build (which I am looking into) but afaik everything else worked fine (as to what this PR is concerned).

[Shillaker]

Tiny typo, then good to go

[Shillaker]

Tiny typo