Closed erikzenker closed 7 years ago
It took a while to understand you implementation. I think the ByteCast implementation could be better with specialised versions of serialize, prepare and restore. I'm going to write a implementation for std::vector and some other types.
It is possible to get the size of the message before calling receive? It would be very useful to know it beforehand in order to allocate the right amount of memory. This would allow to prevent the multiple copies of the data and therefore increase the performance.
I am still thinking about a more elegant way than relying on the T::data() and T::size(), since they are not implemented in most of the stl and you loose knowledge that is transmitted with the message.
I'm going to write a implementation for std::vector and some other types.
Yes feal free to add functionality and provide ideas for improvement :smile:
It is possible to get the size of the message before calling receive?
Currently the CommunicationPolicy does not specify any functionality for that, so we need to add it.
On the CommunicationPolicy level there exists the function probe for MPI and for ZMQ we need to implement it.
I am still thinking about a more elegant way than relying on the T::data() and T::size()
I think the most general approach is to use a pointer and a length argument, but this also is not
supported by the most stl containers. A lot of stl container have iterators, but you never know
if an iterator iterates over a contigious amount of memory. Finaly we need a pointer (.data()) and a length (.size()). Maybe there is a nice way to transform any input into a pointer and a length, suggestions ?
Adds a serialization policy to the cage which allows to define how input data should be transformed/serialized before the data is forwarded to the communication policy.