Description.
La semplicità è l'ultima forma della sofisticazione1
Leonardo da Vinci
This post describes the Skeleton’s in terms of structure, processors’ network configuration and operation.
When, for the sake of clarity, has been considered necessary to explain something related in some way with the programming language, it has been done in terms of the C language.
--------------------
As was stated in post “Introduction” of this series, the Skeleton is the component of the software of Single Program Multiple Data (SPMD) machines –dedicated to signal and/or image processing applications– that constitutes the logical communication’s infrastructure that connects the processors. According to this, the main functions of the Skeleton are to configure and support the communications of the processors’ network.
The communications of the processors’ network consist on the transferences described in post “Data transferences“ of the series “Notes on SPMD architecture” series, these transferences are supported by means of channels.
The configuration of the communications of the processors’ network consists of the definition of the network topology and the configuration of the channels.
The software correspondent to channels’ creation, configuration, use, and destruction are part of the Skeleton. These operations are addressed in this series first, in post “Channels” and then, in post “Nodes’ programming model”. The configuration of the communications of the processors’ network is addressed below and the channels’ configuration parameters’ set in the mentioned post “Channels”.
As was stated in post “Requirements” of this series, the processor network is considered to be static. That means that the network topology is defined only after the Skeleton’s code starts to run. Therefore, once the Skeleton code is running, it has to be re-started in order to be re-configured.
Consequently, one of the firsts things that the Skeleton’s code when start up is to read the Skeleton’s configuration file (Configuration file). This file contains all the necessary parameters to configure the processors’ network. Regardless of that additional parameters might be necessary for a specific machine and/or a specific application, within this work we will only address those parameters corresponding to the channels.
We will consider that the Configuration file resides in some kind of non-volatile storage media (hard-disk or memory) accessible by all the nodes as mentioned in post “Requirements”.
On the other hand, in the same post was stated that the SPMD machine application software consists of three executable files, the correspondent to the input, output and processing nodes. Let’s name these three files as inputNode, outputNode, and processingNode. Let’s consider that those files are built from the object files inputNode.o, outputNode.o and processingNode.o. These objects files are linked with the Skeleton object files as well as the necessary libraries in order to generate the correspondent executable files. At the same time, let's say that these object files correspond to the source files inputNode.c, outputNode.c and processingNode.c.
In some moment in the later start-up of the machine, those executable files, together with the Configuration file are allocated to the nodes and made to run. It is considered that the allocation mechanism is provided by the platform, either by the operating system (OS) or by some library. After the Skeleton reads the Configuration file in each node, the nodes’ software becomes parametrized and ready to run.
Note that information about the nodes that constitute the network -at least number of nodes and function to be performed- has to be provided also to the allocation process.
Therefore, for supporting the configuration of the communications of the processors’ network, the Skeleton supports the definition of the variables that parametrize the channels used in the nodes’ code. When the Configuration file is read, values are assigned to those variables. The definition of such variables is carried out in header file/s included in the source files inputNode.c, outputNode.c and processingNode.c, and the reading of the Configuration file is performed by a Skeleton function called from the code of the nodes.
The communications of the processors’ network consist on the transferences described in post “Data transferences“ of the series “Notes on SPMD architecture” series, these transferences are supported by means of channels.
The configuration of the communications of the processors’ network consists of the definition of the network topology and the configuration of the channels.
The software correspondent to channels’ creation, configuration, use, and destruction are part of the Skeleton. These operations are addressed in this series first, in post “Channels” and then, in post “Nodes’ programming model”. The configuration of the communications of the processors’ network is addressed below and the channels’ configuration parameters’ set in the mentioned post “Channels”.
As was stated in post “Requirements” of this series, the processor network is considered to be static. That means that the network topology is defined only after the Skeleton’s code starts to run. Therefore, once the Skeleton code is running, it has to be re-started in order to be re-configured.
Consequently, one of the firsts things that the Skeleton’s code when start up is to read the Skeleton’s configuration file (Configuration file). This file contains all the necessary parameters to configure the processors’ network. Regardless of that additional parameters might be necessary for a specific machine and/or a specific application, within this work we will only address those parameters corresponding to the channels.
We will consider that the Configuration file resides in some kind of non-volatile storage media (hard-disk or memory) accessible by all the nodes as mentioned in post “Requirements”.
On the other hand, in the same post was stated that the SPMD machine application software consists of three executable files, the correspondent to the input, output and processing nodes. Let’s name these three files as inputNode, outputNode, and processingNode. Let’s consider that those files are built from the object files inputNode.o, outputNode.o and processingNode.o. These objects files are linked with the Skeleton object files as well as the necessary libraries in order to generate the correspondent executable files. At the same time, let's say that these object files correspond to the source files inputNode.c, outputNode.c and processingNode.c.
In some moment in the later start-up of the machine, those executable files, together with the Configuration file are allocated to the nodes and made to run. It is considered that the allocation mechanism is provided by the platform, either by the operating system (OS) or by some library. After the Skeleton reads the Configuration file in each node, the nodes’ software becomes parametrized and ready to run.
Note that information about the nodes that constitute the network -at least number of nodes and function to be performed- has to be provided also to the allocation process.
Therefore, for supporting the configuration of the communications of the processors’ network, the Skeleton supports the definition of the variables that parametrize the channels used in the nodes’ code. When the Configuration file is read, values are assigned to those variables. The definition of such variables is carried out in header file/s included in the source files inputNode.c, outputNode.c and processingNode.c, and the reading of the Configuration file is performed by a Skeleton function called from the code of the nodes.
In the writing of this article, Stanley Clarke, Marcus Miller and Victor Wooten (SMV Concert 2009 - Jazz à Vienne, France) have collaborated in an involuntary but decisive way.
---------------------
1. Simplicity is the ultimate sophistication.
2. Picture: Based on “Magic cube – cube puzzle play” by Domenic Blair | Pixabay. Link to the source.
0 Comments