My vote is for (b), if only because that's ultimately the behaviour of most of the OS's under the hood, so it's worthwhile taking advantage of / acknowledging that.

-----Original Message-----
From: SG14 [mailto:sg14-bounces_at_[hidden]] On Behalf Of Matt Bentley via SG14
Sent: Wednesday, 14 October, 2020 18:46
To: Michael Wong <fraggamuffin_at_[hidden]>
Cc: Matt Bentley <mattreecebentley_at_[hidden]>; Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Subject: Re: [SG14] Soliciting Games related topics for this wednesday

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%20col
> ony%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
> >
>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg14

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.