Exposing I/O Wait Time

A related, and more fundamental, drawback with the current compiler is that it busy-waits for all I/O to complete. There are several things a more integrated compiler could choose to do with that time:

• Interleave multiple communications operators' I/O. For example, if the application wants to perform a shift in one direction at the same time as a broadcast in the other, it may be better to interleave the reads and writes to match the scheduled patterns in the router. This could substantially reduce I/O time when multiple operators are to be used at effectively the same time.
• More generally, communication can be interleaved with computation. If the HLL compiler determines that a given operator has 1/3 of the bandwidth from the node, it can schedule two routing-cycles' worth of computation between each read or write to the processor interface, thus reducing the overall application time.

The number of cycles between each slot where the network can accept a data word is known as the gap [65,49]. Before attempting to optimize this number to a lower level, it is important to make sure that no other bottleneck exists: in particular, the processor may be unable to inject messages faster than one cycle in two (as is the case for the current NuMesh/SPARC prototype). In this case, the I/O wait time will generally be less of an issue.

Split-language techniques do exist for hiding I/O wait time. Interestingly, interleaved I/O is already used for the implementation of NuMesh online routing, as discussed in Section 4.2. A similar technique could be used for scheduled operators: the write function could place a message buffer in a queue for that operator and set up an interrupt handler which would send the message.