Memory Model

The memory model for RaftLib is quite simple, and can be summarized as FIFO with respect to ports and standard C/C++ within the compute kernel, for those that don't want to read further.

Terms

• Enqueue - used in place of head or tail of a FIFO to avoid confusion. This term indicates that an item is inserted into a FIFO. In RaftLib's case, all ports are abstracted as FIFOs.
• Dequeue - used in place of head or tail of a FIFO to avoid confusion. This term indicates that an item is popped (removed) from a FIFO. In RaftLib's case, all ports are abstracted as FIFOs.

Physical Memory Type No guarantees are made as to physical memory type, only that the underlying cost functions that govern the runtime will monitor and allocate/move memory to obtain the best balance given the current available cost functions.

Locality Locality is explicit for the FIFO access pattern to ports, therefore the runtime optimizes for this first and foremost.

The Ordering Model RaftLib views ports as the primary abstraction for communicating between compute kernels, in fact it is the only way two kernels should be communicating in RaftLib. There are varying levels of ordering implied by each port, however there are several guarantees that are given.

• single port ordering - given message i inserted into a port at time t and message i+1 inserted at time t+1, i will always be received at the
• multi path routing - given the example image:
  ,
  data set on the path from kernel a to kernel b and from kernel a to kernel c is not guaranteed to arrive at the same time. Nor is data sent from b to d or from c to d guaranteed in any order. If the programmer wishes to provide synchronization, in-line signaling is provided to add meta-data that can be used to add time stamps to implement synchronized data movement, RaftLib however does not natively provide that guarantee as it hurts performance for the general case (most applications do not need this type of behavior.
• multiple port ordering - given a compute kernel a with N output ports, the only guarantee of ordering is with respect to single port ordering.

Consistency Memory, and the data residing in it, are governed primarily by the simple concept of ownership. To own memory or data is to take control from the runtime and pass it to the programmer inside a kernel. RaftLib provides several methods to own and release data via FIFO interfaces.

Memory can be claimed from an output port using the allocate() function call. It is owned by the caller of allocate() until it is written to the output port via send() or push(). Allocated memory, if allocated by mistake, must be returned to the port via a call to deallocate() so that the runtime may be free to manage the port.

Data written to an output FIFO using the send() or push() functions of the FIFO interface found in fifo.hpp is considered to be owned by the downstream kernel object. Prior to executing these functions, that data is owned by the calling compute kernel.

Data read from the input FIFO is considered to be owned by the compute kernel after executing a pop() or the range equivalent. There is a concept of leasing data for a fixed amount of time using the peek() functionality. When a compute kernel calls peek() the calling compute kernel takes temporary ownership of the data from that port. It is owned by the kernel until the unpeek() function is called to release it (this is critical as the runtime must be conservative and honor ownership). If the data is not needed, a recycle() function can be called to invalidate (and destroy if a C++ object). The destruction of these objects is not guaranteed by the run-time to be immediate (most often it is more efficient to trap the destruction into a bulk operation at a later time).