…es and how the recv_displs problem of _v collectivs could be fixed
During my work on enabling user provided mpi typesin kamping (starting with alltoall and alltoallv) I've encounter some problems related to resizing the recv buffer.
We should not resize the recv_buffer if a recv_type() is given, as this custom datatype can potentially contain weird lower and upper bounds that do not match the recv_buffers's underlying value_type at all.
when recv_displs() are given to alltoallv, we currently only examine the last entry of recv_counts and recv_displs to compute the size to which the recv_buffer has to be resized. This can be, however, incorrect for non monotonically increasing recv_displs. The obvious solution is to use $\max_i(\mathrm{recv\_displs}[i] + \mathrm{recv\_counts}[i])$ what incurs an overhead in most cases and should therefore only be done if recv_displs are given and the user wants us to resize the recv buffer.
currently the only way a user can express their intent to not resize the recv_buffer is to use kamping::Span, which is somewhat arcane.
The work in this PR is not finished yet but I feel that we should discuss the itopic first, as most of the issues are somewhat dependent on each other.
Currently, I feel that a "clean" solution could be to provide to factory functions:
recv_buf(...) expressing that the user wants us to resize the recv buffer (and failing to compile if a container without a resize() method is passed)
recv_buf_static (or a more suitable name) to express that the user does not want kamping to resize the buffer.
Maybe one I think we should even reverse the defaults and use recv_buf and ref_buf_resizable.
…es and how the recv_displs problem of _v collectivs could be fixed
During my work on enabling user provided mpi typesin kamping (starting with
alltoallandalltoallv) I've encounter some problems related to resizing the recv buffer.recv_type()is given, as this custom datatype can potentially contain weird lower and upper bounds that do not match the recv_buffers's underlyingvalue_typeat all.recv_displs()are given toalltoallv, we currently only examine the last entry ofrecv_countsandrecv_displsto compute the size to which the recv_buffer has to be resized. This can be, however, incorrect for non monotonically increasingrecv_displs. The obvious solution is to use $\max_i(\mathrm{recv\_displs}[i] + \mathrm{recv\_counts}[i])$ what incurs an overhead in most cases and should therefore only be done if recv_displs are given and the user wants us to resize the recv buffer.kamping::Span, which is somewhat arcane.The work in this PR is not finished yet but I feel that we should discuss the itopic first, as most of the issues are somewhat dependent on each other.
Currently, I feel that a "clean" solution could be to provide to factory functions:
recv_buf(...)expressing that the user wants us to resize the recv buffer (and failing to compile if a container without aresize()method is passed)recv_buf_static(or a more suitable name) to express that the user does not want kamping to resize the buffer.Maybe oneI think we should even reverse the defaults and userecv_bufandref_buf_resizable.