Multicore programming: it’s all in the messaging
MCAPI
Looking at MCAPI, you see that it has three different communication modes:
1. Connectionless Messages
2. Connected Packet Channels
3. Connected Scalar Channels
Connectionless Messages is the most flexible mode, sent from a source to a destination without requiring a connection and with blocking and non-blocking functionality. Communication is buffered with per message priority.
Connected Packet Channels use connected unidirectional FIFO channels with blocking and non-blocking functionality. Communication is buffered with per channel priority.
Connected Scalar Channels are for 8-, 16-, 32- or 64-bit scalars and use connected unidirectional FIFO channels with blocking functionality and with per channel priority.
Other functional groups provide node and endpoint management, as well as management of non-blocking operations and general support functions. A 3-tuple, consisting of domain id, node id and port id, defines an endpoint.
After MCAPI has been initialized, the application creates endpoints on the local node and retrieves endpoints from remote nodes. Based on the application, the proper communication mode and blocking or non-blocking functionality is selected.
When completed, the application can send and receive the messages. If non-blocking functions are used, the proper non-blocking management functions are used to complete the communications. Beyond the MCAPI API, the application is not aware of how the communication is managed. The how is managed by the MCAPI implementation and supporting tools.
MCAPI Enablement. On a single processor, function parameters are passed on the call stack. Distributing functions across multiple cores using message passing involves passing the parameters and computational results by explicit communication. Functions are encapsulated by communication calls to deliver parameters and results. Parameters can be passed by reference or by movement, if shared memory is used.
Migrating to multicore using MCAPI
Let's look at the flow in migrating an application to multicore using message passing.
Your first step is to determine the composition and behavior of the application. In some cases, the application is well understood and in other cases it may have to be analyzed through profiling.
It is important to emphasize the functions that use the most CPU cycles. Tackling the hotspots first is the fastest path to performance improvement. Once you have established your first assumptions of how to distribute the application function on multiple cores, it's time to map the application to the multicore platform.
The following step is to encapsulate the functions that are mapped to other cores. To do so, you add communication primitives, in their simplest form, by sending and receiving messages.
Now there’s the more complex task of adding the communications software. This involves movement of metadata and possibly payload data, synchronizing and safeguarding the meta and payload data during the communication.
The communication needs to be adapted to the transport, taking into account operating systems, drivers if applicable, and also considering that the two sides of the communication may be on different types of cores. As you add communication channels, this task becomes increasingly complex.
Once you have encapsulated, added primitives and written the communications software, it's time to compile, test, and validate it against the requirements. Chances are that you won't get it right the first time, which will lead you to the step of measuring and analyzing to discover where assumptions made can be improved. This flow may have to be repeated multiple times before you are finished.
This migration flow (Figure 1, below) can be greatly simplified with the MCAPI programming model and tools support.
MCAPI is a relatively simple API with approximately 50 different functions. Most applications do not need them all, and often require only a small subset. Even so, tools can simplify the MCAPI-enabling task.
Click on image to enlarge.
Figure 1: Application Flow and Topology Map
The tool shown in the figure above is aware of the underlying topology map, in terms of nodes and ports. It can therefore provide information to the programmer about which nodes and ports are available.
You first select which MCAPI function to use (i.e., send or receive message, blocking or non-blocking, destination node, and which ports to use), then select parameters either from existing variables or those offered by the tool.
The template is filled in and MCAPI code is generated and inserted into the application at the location that the programmer chooses. Code generation as provided by this tool speeds up the programming effort, and because the tool is topology aware, the code templates are tested, reducing the number of errors and amount of debugging required.
Loading comments... Write a comment