Synergy User Manual and Tutorial. - THE CORE MEMORY

Synergy User Manual and Tutorial
In comparison, Synergy uses dynamic tuple binding at the expense of increased
communication overhead by using dynamic tuple space daemons. In the full SLM
implementation, this overhead will be reduced by a distributed tuple matching engine.
Practical computational experiments indicate that synchronization overhead (due to load
imbalance) logged more time than communication. Thus Synergy's load balancing
advantage can be used to offset its increased communication overhead.
Parallel Programming and Processing in Synergy
A parallel programmer must use the passive objects for communication and
synchronization purposes. These operations are provided via the language injection
library (LIL). LIL is linked to source programs at compilation time to generate hostless
binaries that can run on any binary compatible platforms.
After making the parallel binaries the interconnection of parallel programs (IPC graph)
should be specified in CSL (Configuration Specification Language). Program ``prun''
starts a parallel application. Prun calls CONF to process the IPC graph and to complete
the program/object-to-processor assignments automatically or as specified. It then
activates DAC to start appropriate object daemons and remote processes (via remote
cid's). It preserves the process dependencies until all processes are terminated.
Building parallel applications using Synergy requires the following steps:
1. Parallel program definitions. This requires, preferably, establishing timing models
for a given application. Timing model analysis provides decomposition
guidelines. Parallel programs and passive objects are defined using these
guidelines.
2. Individual program composition using passive objects.
3. Individual program compilation. This makes hostless binaries by compiling the
source programs with the Synergy object library (LIL). It may also include
moving the binaries to the $HOME/bin directory when appropriate.
4. Application synthesis. This requires a specification of program-to-program
communication and synchronization graph (in CSL). When needed, user preferred
program-to-processor bindings are to be specified as well.
5. Run (prun). At this time the program synthesis information is mapped on to a
selected processor pool. Dynamic IPC patterns are generated (by CONF) to guide
the behavior of remote processes (via DAC and remote cid's). Object daemons are
started and remote processes are activated (via DAC and remote cid's).
6. Monitor and control (pcheck).
122