setup archive types that use copy/move constructors to optimize intranode accessors

[jjwilke]

If known that "sending" within the same process, avoid sizing and directly copy from one object into another.

[dhollman]

I did this in the latest checkin, but you still can’t get away from a sizing pass because you need to collect the sum of the sizeof(T)s. If we’re careful with marking things constexpr, though, the compiler should be able to compile out the sizing pass at compile time in many cases. (Unless, for instance, there are dynamic branches, in which case the tuple-like Archive type approach won’t work either)

[dhollman]

See commit DARMA-tasking-internal/darma-serialization@f7ee865

[jjwilke]

The sizing pass shouldn't really be a performance problem. I assume this can also be skipped if you just pick a buffer size that you can "guarantee" is big enough.

Are these new archive types just in the copy_constructor_archive.cc file? Or are they accessible in an installed header file?

[dhollman]

I assume this can also be skipped if you just pick a buffer size that you can "guarantee" is big enough.

Yes, that's the idea behind FixedSizeSerializationBuffer. I need to do some work to tighten up the SerializationBuffer concept, but at the very least whatever we come up with should be compatible with a fixed size "guarantee" like this.

Are these new archive types just in the copy_constructor_archive.cc file? Or are they accessible in an installed header file?

I stuck them there by way of example (as to how "easy" it would be to write your own thing that does this), but I can move it to some place more formal. I can work some more on cleaning this up today. It would be nice to hand serialization to Matt as an independent piece he can start using for his own purposes, at the very least.

[dhollman]

@jjwilke The code you requested is in 2561e1d. Let me know if you need help with it.