With the emergence of commodity multicore architectures, exploiting tightly coupled parallelism has become increasingly important. Most of the parallelization efforts are addressed to applications that compute with large amounts of data in memory and in general have a regular behaviour. In the scenario of tiny artefacts, interactive/reactive applications, do not deal with huge amounts of data in memory, but streams of data. But still can exploit several cores in a fine grain parallelization.

NiMo (Nets In Motion) is a graphic-functional-data flow language designed to visualize algorithms and their execution in an understandable way. This visualization helps to understand where and when resources are used in the program, thus giving clues to optimize solutions.

Another characteristic is that the programs are deterministic unless non-deterministic constructs are used. A scheduler for executing transformations scales up to the number of available processors. NiMo, having very few constructs, is not a visual interpreter for a textual language because there is no textual code at all. It is a true graphical programming language. Programs are process networks. The program exploits the bi-dimensional description to express data dependency and colour to describe modes and states. Processes communicate through channels of unbound capacity, acting as FIFO lists. It has additional characteristics as wait by necessity, no explicit PUT or GET operations and value sharing. Programs in execution fully exhibit their state. Ready processes act concurrently. Processes may be polymorphic, higher order and have multiple outputs. The language has a set of primitive processes well suited for stream processing and supports executing. There is no variable sharing, because there are no variables: There are values or expressions that eventually can be transformed into values. The system provides an also graphical and incremental type inference system that guarantees program type-safeness by construction.

Fine grain concurrency is supported by independent computation and by the language construct: pipelining. Processes or operators have two types of input parameters, as well as an evaluation mode. Each process has its own evaluation mode: from lazy to weak-eager, which means that there are different ways a process can react to provide a needed result: react as soon as it has enough data to do so or there is a demand set on the result. Processes have parameters (in-ports) at the top for specializing the process and horizontal parameters are used to implement the producer-consumer model. By setting the evaluation modes for processes, the user can regulate the number of processor that could act concurrently, and also regulate channel population or the evolution of the number of alive process during execution.

Synchronization of processes is implicit; therefore programming does not include locks. There are facilities to measure the used resources (parallelism level, number of steps, number of processes, number of constants etc.).

Haskell reference

In the figure we see the NiMo code and its correspondence with Haskell code. The NiMo network is read from left (the result) to right (the code used to produce the result). This example calculates the (infinite) sequence of Fibonacci, therefore the result will be a list. The already calculated values are duplicated (using black dots), feedback and used as operands for MAP process that will add (using the process +) all pairs of values that show up in the input. There are no names used in the NiMo code to name neither the sequence nor intermediate values.