Thanks Michael-
I think the main question I have for everyone (asides from general
feedback and corrections, if any) is around erasure and freeing memory
blocks.
With the reserve mechanism in place, it is possible to retain memory
blocks when they become empty of elements post-erase, to reuse at later
points. Not all memory blocks can be retained, as the smaller the memory
block, the lower the cache locality of elements overall.
And since (by default) colony has a growth factor for memory blocks, in
normal use the first memory block will be small and subsequent ones will
be larger and larger.
And, if there are many memory blocks but many of them are halfway-empty
due to erasures, it might make more sense in some scenarios not to
retain memory blocks regardless of how large them are.

I believe when we talked about this last time, there were two options:
(a) Retain no memory blocks on erasure
(b) Leave retention of memory blocks on erasure implementation-defined

The first gives a predictable pattern for programmers, but comes with
serious performance issues, for example erasing/inserting a bunch of
elements repeatedly could, depending on the location of the elements
being erased, result in memory blocks being deallocated/reallocated
repeatedly, so, worst-case performance scenario.
The second gives no predictability as to when memory blocks are freed,
but has the additional performance advantage that, for some of the
memory blocks at least, deallocation can be shifted out of hot loops and
then freed via the 'trim()' function.

My experience tells me that the best performance strategy is to only
retain the back or second-to-back memory blocks (provided the
second-to-back is not the first memory block), which will almost always
be the largest blocks in the group (splice messes with this a little,
but not much). That's what I've got in the implementation.
And I think the messiness of leaving retention implementation-defined
can be mitigated where it is problematic by people using allocators
(pool or other types).

So I think (b) gives the best option for programmers not using
allocators, may create a small amount of additional overhead for those
using allocators via the necessity to call 'trim' to make sure all
memory blocks are freed via erase and available for other
data/containers. But I'm interested to hear other's thoughts.

-Matt


On 15/10/2020 3:13 am, Michael Wong wrote:
> Thank you Matt, I dont want you to stay up to 2 am your time if there
> will not be a lot of Games experts online. We will endeavour to review
> this offline. Thank you again.
>
> On Wed, Oct 14, 2020 at 2:05 AM Matt Bentley <mattreecebentley_at_[hidden]
> <mailto:mattreecebentley_at_[hidden]>> wrote:
>
> New version of the colony paper is now available here:
> https://htmlpreview.github.io/?https://raw.githubusercontent.com/WG21-SG14/SG14/master/Docs/Proposals/D0447R11%20-%20Introduction%20of%20colony%20to%20the%20Standard%20Library.html
>
> To the best of my knowledge all the feedback from the last review has
> been actioned. And the implementation based on this draft is very close
> to being fully baked - about 2% to go.
> The ~10% performance issues mentioned last time in relation to
> reserve()
> were a GCC bug that was introduced in GCC9, and have been reported here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750
>
> This is not fixed in GCC yet. 'm not sure if it will be. However
> reduced
> tests on the current beta show equal or better performance over the
> previous non-reserve versions, about 2% performance increase across
> most
> compilers. This is largely down to the optimisation work I have been
> doing.
>
> In addition a new function, trim(), has been introduced - the reasoning
> for this is listed in the Design Decisions->'Additional notes on
> specific functions'->shrink_to_fit description.
>
> I hope I will be able to attend tomorrow, if not I welcome your
> feedback. There are a couple of minor questions I have:
> * Should assign be allowed to reduce capacity? eg. If the newly
> assigned
> fill or range is smaller than the previous capacity.
> * Should operator = (&colony) be allowed to retain existing memory
> blocks and hence have a potentially higher capacity than the source
> colony?
>
> Thanks-
> M
>
>
> On 13/10/2020 11:57 am, Michael Wong via SG14 wrote:
> > Hi all, for this Wednesday's monthly call, we will be returning to a
> > Games focus, as Security wanted to move to December. I am
> wondering if
> > there are any papers or topics for review or discussion. Thank you.
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden] <mailto:SG14_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> >
>