Re-evaluate the utility of exposing fragmented_regular interface

The indexed interface exists in GASNet VIS to reduce the cost of instantiating and communicating metadata for the special case of a vector operation where all the run lengths on the source or destination happen to be equal. Because GASNet VIS is a C99 interface, the client is required to fully instantiate all of this metadata for either case before GASNet ever sees it. Therefore differentiating indexed from vector as separate APIs allows the client to optimize away this instantiation cost (and GASNet's cost to process it).

In the current UPC++ VIS vector design where the metadata is presented as ForwardIterators, I'm not sure this design decision is still well-motivated.

In particular, I suspect the client can generate a ForwardIterator for an index-style rput/rget and present it to the vector interface, while consuming at most num_elementssizeof(pointer) space for the base pointers, and constant* sizeof(size_t) space for the run length shared by every element. This means the indexed interface doesn't really save a well-written client anything in metadata costs.

On the UPC++ implementation side, I believe both the vector and indexed interfaces will always need to traverse the entire iterator to convert the metadata into GASNet's metadata format before making the call to GASNet VIS. In the vector case, I suspect that conversion process can easily discover whether all the run lengths happen to be equal, thus making this transfer a candidate for GASNet's indexed interface. The only question is whether the cost of that dynamic discovery (and subsequent adjustment of metadata marshalled for GASNet) is sufficient to motivate presenting the user with the special-case indexed (fragmented_regular) interfaces.

Comments (3)