One final point is worth emphasizing as a strict matter of language style. The current draft of the language is targeted primarily towards operations where all involved nodes are active participants. At first glance, this seems to be in contrast to, for example, the shared-memory model, which uses a request-reply structure for all communications.
However, the COP language is not about programming styles so much as communication. A simple shared-memory implementation with COP might just consist of a single operator per node:
This example uses the :dynamic optional argument to (runtime), which specifies that a particular node may call the load function multiple times with new values of the specified operand, without assuming that other nodes will do likewise. Currently dynamic operands are only legal in a few places, such as runtime stream destinations.
A shared-memory handler could then be built on top of this by the application, using interrupts to access the memory and return data to the requesting node (similar arguments could be made, for example, for Active Messages [66]). Where COP becomes useful is when the compiler can extract phase and communication information from the application (e.g., when a given section of the application performs a transpose using nested for loops), and convert it into COP operators. These operators may still be hooked up to a shared memory interrupt handler, but the communication will happen faster once the underlying communication patterns are extracted and given to COP by the frontend compiler.