C++ Logo

sg14

Advanced search

Re: [SG14] Colony Reserve update

From: Matthew Bentley <mattreecebentley_at_[hidden]>
Date: Sun, 9 Aug 2020 09:44:35 +1200
On Fri, 7 Aug 2020 at 00:26, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:

>
> Hi, I have some related suggestions:
> 1. Was this considered as an alternative: have a "reserve(int)" function
> that adds a new block "manually" to the chain of blocks, with at least
> enough space for the required number of elements (not counting the previous
> elements or blocks).
> I think it would be named differently from reserve, so maybe
> "reserve_block(int)".
>

Hey Joel,
couple of problems with this approach: (a) it wouldn't be any different
performance-wise from allowing multiple blocks (these're chained together
with the container just keeping track of the 'head' of the unused block
list). (b) Since there are implementation-defined limits to maximum block
sizes (specifically, constrained by the skipfield type, which determines
the maximum number of erased elements which can be skipped), multiple
unused blocks are inevitable
for any reserve size larger than the maximum block size.

Just to be clear about what I meant with reserve in the previous version of
colony's implementation, it only would reserve one block if it was the
first block in the colony, and would reallocate existing elements to that
block if some already existed - basically it worked fine if the colony was
empty but was otherwise problematic.
But thanks for that thought, regardless.

Regards benchmark results, cross-compiler results show 2% overall
performance drop with reserve enabled in MSVC2019 (with no substantial
massive per-test differences like GCC9), no difference in clang, GCC8 is
consistently a 1-2% overall performance increase with reserve enabled.
Overall performance difference between GCC8 and GCC9 with reserve enabled
is -4%, not mentioning the -11% difference for some individual tests, so
I'm going to go ahead and call "compiler bug" on that one, report it to GCC
and see where that goes.

In terms of allowing/disallowing reserve at this point, I'm unsure which
direction to go. I will completely finish the with-reserve implementation
including the necessary changes to other functions, then re-benchmark at
that point. If anyone has some answers/perspective on my previous
questions, I'd appreciate it at this point.
Thanks
Matt

Received on 2020-08-08 16:48:35