How can the allocator be easily optimized knowing container type and
usage frequency?


On 7/24/2021 6:24 PM, Phil Bouchard wrote:
> 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 <tel:(819)%20328-4743>
>
> Fornux Logo <http://www.fornux.com/>
>
>> 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
>>>
>>> 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>
>>>>>
>>>>
>>>