I'm not sure what situation you're optimizing for. It looks like the
main speed-up is that you're adding and removing pages way less
frequently than deallocate is being called. While I haven't checked if
this specific allocator implementation returns valid memory,
preallocating chunks and dolling them out is how custom allocators do
fast allocations and deallocations.

See: https://godbolt.org/z/d5W16MEvd

I don't see how your array of containers is supposed to help, though. In
my experience with allocators, we just grab a raw slab of memory.
Optimization comes from things like knowing its access patterns (ex:
LIFO can be dolled out as stacks) and knowing its usage (ex: items that
are used together should be placed near things that are likely to be in
cache together).

Care to elaborate?



On 7/24/2021 2:44 PM, Phil Bouchard via Std-Proposals wrote:
>
> Yeah I updated it again (disabled page_t initialization) so in general
> it's more like 3x faster. Which is good if you require low-latency
> (finance, gaming industry, ...). That's why we all use C++ after all, no?
>
>
> --
>
> *Phil Bouchard*
> Founder & CTO
> C.: (819) 328-4743
>
> Fornux Logo <http://www.fornux.com>
>
>
> On 7/24/21 12:18 PM, Phil Bouchard via Std-Proposals wrote:
>>
>> Interestingly, if I increase the LOOP_SIZE the overall time taken is
>> less thus is faster. Also please keep DATASET_SIZE to 1 because I
>> didn't test it with other sizes.
>>
>> I'll follow later this weekend, meanwhile I've put the code here:
>>
>> https://github.com/philippeb8/Flash-Alloc
>>
>>
>> --
>>
>> *Phil Bouchard*
>> Founder & CTO
>> C.: (819) 328-4743
>>
>> Fornux Logo <http://www.fornux.com>
>>
>>
>> On 7/24/21 6:19 AM, DBJ wrote:
>>> https://godbolt.org/z/T4qc5o8Mb <https://godbolt.org/z/T4qc5o8Mb>
>>>
>>> that turns out to be many times slower vs. std::allocator<> ...
>>>
>>> I must be doing something wrong?
>>>
>>> On Sat, 24 Jul 2021 at 09:40, Phil Bouchard via Std-Proposals
>>> <std-proposals_at_[hidden]
>>> <mailto:std-proposals_at_[hidden]>> wrote:
>>>
>>> And here's a more generic one that is 10x faster for straight
>>> allocations.
>>>
>>> Anyway my point being that apparently the rebind oddity has been
>>> removed from the C++20 standards but not from my system
>>> headers... So perhaps adding a similar ultra fast allocator such
>>> as this one into the stdlib would be constructive.
>>>
>>>
>>> Regards,
>>>
>>> --
>>>
>>> *Phil Bouchard*
>>> Founder & CTO
>>> C.: (819) 328-4743
>>>
>>> Fornux Logo <http://www.fornux.com>
>>>
>>>
>>> On 7/23/21 10:23 PM, Phil Bouchard via Std-Proposals wrote:
>>>>
>>>> Greetings,
>>>>
>>>> Given the default memory allocator is known to be slow, it came
>>>> to my attention that if we collect more information at
>>>> compile-time regarding not only the type being allocated but
>>>> the container type and the usage frequency then we can have
>>>> much higher performance.
>>>>
>>>> In the attached example, if we use a queue then we can speed up
>>>> the overall allocation time by 7x!
>>>>
>>>>
>>>> Regards,
>>>>
>>>> --
>>>>
>>>> *Phil Bouchard*
>>>> Founder & CTO
>>>> C.: (819) 328-4743
>>>>
>>>> Fornux Logo <http://www.fornux.com>
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> <mailto:Std-Proposals_at_[hidden]>
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>>>
>>
>