It is exactly what you referred to: a LIFO cache.

If developers can give hints on the container type and usage frequency then the allocator can be easily optimized.

--
Phil Bouchard
Founder
C.: (819) 328-4743
> On Jul 24, 2021, at 4:10 PM, Scott Michaud <scott_at_[hidden]> wrote:
> 
> 
> 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
>> 
>> 
>> 
>> 
>> 
>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 7/24/21 6:19 AM, DBJ wrote:
>>>> 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]> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> -- 
>>>>> Std-Proposals mailing list
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>> 
>>