The current Sneezy implementation supports SPMD-style systems with the client and agent communicating via sockets using either raw binary data or textual Lisp-syntax data. It is our intention that such distributed-object frameworks as CORBA [5] and ILU [12] could serve as implementation vehicles for Sneezy.
The programmer-visible part of Sneezy is realized as two APIs, one for the parallel program (server API) and one for the client (client API). These APIs depend on the agent implementation and the client language, respectively. For example, we have two client APIs: one for single-threaded C, and one for multi-threaded Scheme; their behaviors are quite different.
On the server side, The Sneezy/pC++ agent assumes that both the runtime system and the user program are appropriately instrumented; in the case of the user program, the pC++ compiler is responsible for adding calls to the appropriate server API procedures. When an event point is reached, the event signaling procedures are called, and the event is signaled to any interested clients. Alternatively, we could have had the agent perform the instrumentation at runtime by setting breakpoints in the program. This would have led to better performance and would have allowed the same program to be used both in debugging and production without recompilation. It would, however, have meant that the run-time system would need access to the symbol tables produced during compilation and it would have limited the attribute information typically carried by Sneezy events. Some of this attribute data might not be available at the event point without additional computation.
Our implementation allows communication optimization in various forms. We
estimate that eventually, the cost of moving an event from the program to
the client on a machine which supports shared memory will be a small number
of procedure calls (
), some bookkeeping, and a memory-to-memory copy of
a small structure. For further performance improvements, we will need to
exploit the ``closeness'' of a client to its target program. In general,
the client and the target do not even have to be on the same machines.
Moving them to the same machine will allow the agent to optimize
communication costs; moving them to the same address space would allow even
further improvements. Thus in specializing the agent
implementation we can expect to improve performance.
The performance of Sneezy on larger systems (where the client might be a bottleneck in terms of being a focus for messages from many nodes) is somewhat unclear. At some point we will have to consider a mechanism like that of Parasight [1], where lightweight parasites can be moved into the program and execute there for event filtering and generation. While such a mechanism is complex, it is general and can serve many purposes.