I guess it's similar to memory(), which allows the user to enquire as to
how much memory is being used by the container as a whole, given that
implementations may vary significantly and the skipfield side of things
can make guesses at the actual memory usage impossible.

But you're right in the sense that this is really information one wants
*before* specifying custom min/max block sizes. By default my
implementation weighs the size of the block metadata, plus the
sizeof(container), against the sizeof(element_type) to determine the
most reasonable initial block capacity. It does so with the following macro:

#define PLF_MIN_BLOCK_CAPACITY (sizeof(aligned_element_type) * 8 >
(sizeof(plf::colony<element_type>) + sizeof(group)) * 2) ? 8 :
(((sizeof(plf::colony<element_type>) + sizeof(group)) * 2) /
sizeof(aligned_element_type))

(group is the name of the block metadata struct).

The main difference is that the new function would also include the
amount of memory used by the skipfield (since this would also vary
per-implementation).

Someone could do something similar to the above code with this function
if they wanted an initial block capacity that was responsive to the
sizeof(element_type) and the memory consumed by metadata, but not the
same as the implementation's default initial block capacity. Of course,
this would probably involve multiple calls to the function to find the
optimal starting block size.

In addition, it can be a function which allows a user to probe in
advance what different block sizes yield in terms of metadata memory
usage, for any given implementation, outside of live code.
M@

On 26/11/2021 5:46 am, Ben Craig wrote:
> If you can provide a short, motivational chunk of code that shows how it would be used, then that would make it a lot easier to answer the question about whether it's useful or not. I suspect the function may be providing something that is easy for the implementation to provide, but very hard for a user to use.
>
> I suspect that this is trying to help the user solve an optimization problem, where they are trying to minimize the amount of total memory used for a given range of element counts. If that's the case, then write a short code snippet that either solves, or hints at the solution to that problem.
>
>> -----Original Message-----
>> From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Matt Bentley via
>> SG14
>> Sent: Wednesday, November 24, 2021 7:35 PM
>> To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
>> <sg14_at_[hidden]>
>> Cc: Matt Bentley <mattreecebentley_at_[hidden]>
>> Subject: [EXTERNAL] [SG14] sizeof_block_metadata function, colony/hive,
>> advice wanted
>>
>> Hi all,
>> thinking about including a
>> size_type sizeof_block_metadata(const size_t block_size)
>>
>> function for colony/hive, as this would allow the user to ascertain the
>> amount of memory used by a memory block's metadata in colony (including
>> skipfield), given the number of elements stored in that memory block.
>> This is less important for colony which is a fixed implementation, more
>> important for std::hive which could potentially have many alternative
>> implementations and these might not be visible to the user in text form.
>>
>> The idea was that if someone knows how much memory is used by each
>> block outside of the actual memory used to store the elements, that might
>> aid in terms of knowing how much cache space is used by the metadata and
>> people might be able to make better decisions about the min/max capacities
>> of memory blocks (if they are specifying these manually) on that basis.
>>
>> The function would throw an exception if the block_size specified was
>> outside the minimum/maximum block capacity ranges.
>>
>> My main question to you is whether this function is worth including - as it
>> adds yet another function to the codebase.
>> Thanks,
>> M@
>>
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg
>> 14__;!!FbZ0ZwI3Qg!_EmqRo6oE_K3_0kspLt95nQkSwn6ReF6w24SgNk6c4-
>> tKwgxy1B_QABcfeZ_$
> .
>