Add StaticDeque

[wthrowe]

Proposed changes

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[teukolsky]

Hi Will,
What is the proposed use of this?

[wthrowe]

Yeah, probably should have mentioned that somewhere.

It's to store the past values for multistep time steppers. The usage pattern makes this naturally a deque, and knowing what time steppers we have we know the queue will never have more than 8 elements.

I'm pretty sure libstdc++'s implementation of std::deque will keep allocating blocks at one end and deallocating them at the other. (The libstdc++ code is a bit dense, so it is possible I'm not interpreting it correctly.) For something as large as the GH variables, I think each block will hold one step, so there will be one allocation per step.

I think libc++'s implementation is actually smart enough to keep and reuse its storage blocks, so it would be fine for the main history. It's not clear whether the initial allocation of space would be significant in the IMEX code, which creates a temporary History<double>. We can't rely on using this implementation anyway, so it's academic.

This idea was also mentioned in passing in some unrelated recent PR, but I don't remember which or how useful it would actually have been there.

[nilsdeppe]

Ah, I think @kidder used a std::deque in some AMR code

[nilsdeppe]

This looks good, a couple requests for a bit more C++ comments that I think would make it clearer to readers in the future. Please squash them in directly :)

[nilsdeppe]

If we end up with this class holding a fundamental types (I currently don't see that we would get that a lot), then we would want this to use PUP_array that serializes a byte stream directly (might be more efficient). I don't think that's important now, but just want to mention it :)

[wthrowe]

For fundamentals (and I think any trivially copyable types), I'm pretty sure we can just serialize the byte stream and the other member variables and restore the exact state. For more complicated things, we have to be careful not to try to pup the unused memory as objects of type T, so the current version just accesses the objects through the public interface and doesn't try to restore the details of the internal representation. (The elements may be "rotated" in the internal circular buffer after deserializing.) Switching to the first implementation when allowed would certainly be possible, but let's put it off for now. I've added a comment summarizing this.

[nilsdeppe]

I agree with you! Thanks for adding the nice comment!

[wthrowe]

I have expanded the comment explaining the meaning of the member variables and the logical treatment of the storage, and added some short comments for the other things.

[wthrowe]

For fundamentals (and I think any trivially copyable types), I'm pretty sure we can just serialize the byte stream and the other member variables and restore the exact state. For more complicated things, we have to be careful not to try to pup the unused memory as objects of type T, so the current version just accesses the objects through the public interface and doesn't try to restore the details of the internal representation. (The elements may be "rotated" in the internal circular buffer after deserializing.) Switching to the first implementation when allowed would certainly be possible, but let's put it off for now. I've added a comment summarizing this.

[nilsdeppe]

I agree with you! Thanks for adding the nice comment!