>That helps a little except for the fact that the spec is the spec and
>the APIs will be documented
>and available for all to see. I also believe that most general purpose
>MPI libraries will be aiming
>to support the full specification. So subsetting will not be a complete
>hall pass to ignore the PB
>calls nor would I recommend ignoring them.
>
>Note, I was just wondering if there was a different way to support this
>feature than doubling the
>amount of send apis.
There are two types of complexity: API complexity and implementation
complexity. Increasing the number of MPI calls relates to both but
does not correlate exactly. The inclusion of collective communication
increases both types of complexity. However, the inclusion of the
PMPI functions doubles the number of function calls in the API but
has minimal impact on both types of complexity. The piggybacking API
is really aimed to increase implementation complexity a little by
addressing a real need out there that is not served by current MPI
implementations. Regardless of how we expose this new implementation
complexity to users, we do need this new capability. Given that, the
major goal becomes: how to expose this to users in a way that
minimizes API complexity.
To this end, I think that we need to break the API up into two
components: user API and tool API. The user API makes up the bulk of
the spec and represents the portions of the spec that are meant to be
used by regular application developers. The tool API in MPI 2 is
essentially the PMPI interface. However, I am hoping that it will
grow to include the piggybacking API as well as the idea that every
non-local blocking MPI function call should have a corresponding
non-blocking variant. Seen in this light, the new additions have a
minimal impact on the complexity of the API: they simply represent
new points where tools can intercept and adjust the activities of
user API functions. For example, PMPI+piggybacking can be used by
tools to attach control information to application communication and
PMPI+nonblocking can be used to allow any tool to perform its own
synchronization without worrying that it will cause deadlock with the
application's communication. In this sense it doesn't matter if we
duplicate every call in the spec because this duplication is only
visible to tools and can be implemented fairly easily because each of
these APIs have only a single key feature that needs to be replicated
across many MPI calls. In this sense the duplication associated with
the tool API is closely related to aspect-oriented programming.
In short, I believe that function call duplication associated with
additions to the tool API is a natural part of how any tool API would
operate. Because each new duplicated function represents a new tool
attachment point for the same capability, rather than a new
capability, this duplication represents minimal increases in API and
implementation complexities. The primary complexity is in
implementing the new required functionality and is thus, a tool
complexity and not an API complexity.
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
