-
Notifications
You must be signed in to change notification settings - Fork 2
Workflow
CnC is a programming model rather than a programming language. There are many implementations of the CnC model in many programming languages, including the C-based implementation built on OCR.
In CnC, programs are expressed in graph form. The CnC programmer decomposes an application into item collections, which represent data, and step collections, which represent computation. Item and step instances comprise the nodes of the CnC graph, while the edges represent data and control dependencies among the nodes.
Although these core concepts of the CnC model are common among the many implementations of the CnC model, code written for individual implementations may not be compatible. For example, Intel CnC—the flagship implementation of the CnC model—has a very different feature set from CnC-OCR. For a more detailed overview of the flavor of the CnC model used in CnC-OCR, please see this introduction to CnC (pdf).
The CnC-OCR application developer begins the development process by creating a CnC graph.
We use a textual format to represent the CnC graph, and it is saved in a file with the .cnc
extension.
The graph spec file includes declarations of all item and step collections, as well as the tag functions describing the I/O for all step instances.
For more details, see the [graph specification language page](Graph Spec DSL).
Note: Although we do not provide official syntax highlighting schemes for the CnC graph syntax, we have found that highlighting the code as JavaScript tends to give pretty good results.
The CnC-OCR graph translator tool (cncocr_t
) is used to parse the developer's graph specification, and use the parsed graph structure to generate a skeleton CnC-OCR project. The generated project files include:
- Makefile
- Program entry point / main function
- Graph initialization and finalization function skeletons
- Step function skeletons (suggested code) for each CnC step collection
- Additional scaffolding code to interface with OCR
The graph translator should produce a valid, but incomplete project. In other words, the generated code should compile without error, but probably won't produce any interesting results if run. The application developer needs to flesh out the provided skeleton functions with the desired computations.
The CnC-OCR application developer should only need to edit the source files in the root project directory. This includes the main function, graph initialization function, graph finalization function, and step functions. The developer might also need to add additional definitions to the provided header file. However, the developer should not need to modify any of the generated source code in the cncocr_support
subdirectory, which deals directly with the underlying runtime (OCR).
The generated Makefile provides default targets for building and running the CnC-OCR application. Launching the application via make
ensures that the environment is correctly configured to run OCR. Simply running make run
should compile and launch the application (with no arguments). Additional parameters can be passed to the application via the WORKLOAD_ARGS
variable. For example:
make run WORKLOAD_ARGS="arg1 arg2 ... argN"
By default, the Makefile generated for your CnC-OCR project is set to use the x86 (shared memory) version of OCR. The generated scaffolding code is also optimized for running single-node. To run distributed using MPI, you must first re-generate the scaffolding code:
cncocr_t --distributed
Re-running the CnC graph translator will only overwrite the generated code in the cncocr_support
directory (all files that may be overwritten have an explicit warning in a comment at the top of the file).
Now you can use make
to run the application using the x86-mpi runtime:
OCR_TYPE=x86-mpi OCR_NODEFILE=hosts.txt make run WORKLOAD_ARGS="arg1 arg2 ... argN"
Note that to run with the distributed runtime, you must either provide an OCR_NODEFILE
(a text file with a single hostname on each line), or set OCR_NUM_NODES
to tell how many MPI processes to launch.
Similarly, running on the TG hardware simulator (FSim) requires regenerating some files using the translator tool:
cncocr_t --fsim
When invoked with the --fsim
option, the translator tool will generate a Makefile.tg
for use with FSim.
You can use this new Makefile to build and launch your application with FSim:
make -f Makefile.tg run WORKLOAD_ARGS="arg1 arg2 ... argN"
Console output is not printed by default for TG applications. After running your application, you can print the console output using the print
target:
make -f Makefile.tg print
Please see the wiki homepage for more in-depth tutorials on using the CnC-OCR toolchain for application development.