Synergy Project Home Page

Comparing to ordinary makefiles, the "parallel makefile" only needs one additional library:

FLAGS = -g

OBJS = -L$(SNG_PATH)/obj -lsng

all: sort split merge

sort : sort.c $(OBJS)

          cc $(FLAGS) sort sort.c $(OBJS)

split : split.c $(OBJS)

          cc $(FLAGS) split split.c $(OBJS)

merge : merge.c $(OBJS)

          cc $(FLAGS) merge merge.c $(OBJS)

============================================================

The key here is at the second line: -L$(SNG_PATH)/obj -lsng that links the passive object function calls to use the Synergy runtime library implementation.

Parallel Program Configuration

There are two purposes of parallel program configuration:

The application configuration is done via a Configuration Specification Language (CSL) or an integrated Graphic User Interface (GUI). The GUI (mp in Synergy V3.0) actually translates the application's graphical representation into a CSL file and automatically calls respective programs to process it.

The definition of the software network is done by the "path statements" in CSL. The specified software topology exhibits the SIMD, MIMD and pipeline potentials of the application.

Programs and objects are to be assigned to various processors along with scheduling parameters. The processor assignments define a customized parallel processor for a given application. Using the CTF decomposition method, the overall application performance is first influenced by processor assignments and then the scheduling parameters.

Assuming the use of the CTF principle, we make the following recommendations:

Since the application dependent parallelisms are determined in the program decoupling process, adhering to the above guide lines can guarantee a better than average performance before the adjustments in scheduling parameters.

CSL is simple graphical language for specifying a) program-to-object-to-program network; and b) runtime parameters, such as program/object execution locations and scheduling parameters, etc.

There are two types of statements: a) path statement; and b) synonym statement. The path statement can describe a graphical image of input and output interfaces for each program. The connection between programs is made by objects with identical names.

For example,

F: in1 (type=pipe), in2 (type= ts)

-> M: program1

-> F: out1 (type=pipe), out2 = output (type= seq);

describes the following program image:

In this example, object out2 has a physical file named "output" in default running directory of Program1. The actual file location (directory) depends on Program1's execution environment. For example, if Program1 is activated by CID, the file will be located at user's home directory, whereas a manual activation of Program1 will result in a file created in the same directory as Program1's binary.

The use of "=" sign here is replicable anywhere when a specific physical name (at the target operating system level) is needed. For example, the same program may be needed in more than one place. In this case, we would need many program names equating to the same binary as shown in the following example (program sort).

The Synonym (S:) statement is used to define the linkage between CSL object definitions and program reference symbols.

An MIMD example:

Configuration: msort;

R_debug = 0; /* 0: No debugging

1-5: Runtime debug with varying display details

(1 short, 5 long). */

F: infile = sort.dat

-> M: split

-> F: F1 (type: pipe), F2 (type: pipe);

F: F1

-> M: Sort1 = sort (exec_loc=argo.cis.temple.edu::/u/shi/apps)

-> F: OF1 (type:pipe);

F: F2

-> M: Sort2 = sort (exec_loc=zoro.cis.temple.edu::/u/shi/apps)

-> F: OF2 (type:pipe);

F: OF1, OF2

-> M: Merge

-> F: out = sorted.dat;

/* The Synonyms */

S: F1, sort1.in,split.out1;

S: F2, sort2.in,split.out2;

S: OF1, sort1.out, merge.in1;

S: OF2, sort2.out, merge.in2;

This CSL file describes the same mergesort network as shown in Figure 4 with the following processor assignments: (split, default), (sort1, argo), (sort2, zoro), (merge, default) as defined in the "exec_loc" clauses. A default processor is the computer where a user's CSL is processed. The path specification in the exec_loc clauses indicates the locations of the binaries (for respective CIDs to activate).

The F: objects interconnect program modules. The "->" sign indicates a reference order. This order is primarily for documentation purposes. The "S:" (synonym) statements define the linkage between objects and program specific input/output symbols. For example, object F1 is referred to in program sort1 as in but split as out1.

The following CSL describes the SIMD topology as shown in Figure 3 using manual processor assignments.

=========================================================

 

Configuration: Fractal;

R_Debug = 1; /* Application-wide debug switch */

M: master = frclnt

(factor = 50 /* Scheduling parameter definitions */

threshold = 1

debug = 3) /* Module debug switch, overwrites R_debug */

-> F: coords (type= ts)

-> M: frwrk1=frwrk

(exe_location=dmark.wharton.upenn.edu::/usr/users/shi/apps),

frwrk2=frwrk

(exe_location=aegis.cis.temple.edu::/u/shi/apps),

frwrk3=frwrk

(exe_location=zoro.cis.temple.edu::/u/shi/apps)

-> F: colors (type=ts)

-> M: frclnt;

=========================================================

In this example, the processor assignments are done manually: (frclient,default), (frwkr1,dmark), (frwrk2,aegis), (frwrk3,zoro), (coors, default) and (colors, default). Since the program object references are the same as CSL objects (try to compare this CSL object definitions with the Mandelbrot program cnf_open statements), there is no synonym (S:) statement.