Joseph Schuchart

> their are some things gaspi is not capable of, like remote completion for a put. Interesting. We rely on remote completion quite significantly. Our memory model dictates that remote...

Looks like you need to use `gaspi_wait` to guarantee sequential ordering. There seems to have been some confusion among the GASPI peeps about the term "remote completion": https://github.com/cc-hpc-itwm/GPI-2/issues/22 We should...

> The GASPI people said the way to guarantee remote completion is to send a notification back to the sender. That sounds horrible :( IMO, a daemon is not an...

Mhh, that code looks fishy in multiple places (for example: why do `send1_count` and `send3_count` have different values on both processes?). Have you tried doing the same thing in MPI...

I apologize, it was late last night. You're right, for ~allgatherv~ `alltoallv` it makes sense. However, I cannot find the implementation of `dart_alltoallv`. Is that implemented in a private branch?...

I meant this line: ``` int send2 = 5; std::vector recv2(2); dart_allgather(&send2, recv2.data(), sizeof(std::size_t), DART_TYPE_BYTE, dash::Team::All().dart_id()); ``` `send2` is an int (4 Byte) but you are treating it as size_t...

MPI 3.1 standard, p. 169: > The “in place” option for intracommunicators is specified by passing MPI_IN_PLACE to the argument sendbuf at *all* processes. This is an optimization that is...

Please check whether anyone actually calls collectives with `NULL == sendbuf` before you remove this feature. I'm fine with changing the convention to `sendbuf == recvbuf` triggering the use of...

> For *v* collectives, in_place only makes sense, if both sendbuf AND recvbuf are NULL and that is already covered with the sendbuf== recvbuf condition Again, the MPI standard states:...

> Yes, in_place also makes sense here. Just not the `sendbuf==NULL` part which is why I don't think that checking whether this is used somewhere is actually needed. You're right....