Здравствуйте.
Аллокацию контейнеров, которые выделяют память поэлементно (map, list), ускорить можно и значительно, используя pools. Для vector-подобных контейнеров это не работает, так как там память выделяется большими кусками и всегда разного размера. Тот же boost::pool_allocator, примененный к вектору, не дал мне никаких выгод по сравнению со стандартной реализацией. Означает ли это, что аллокацию таких контейнеров в ощутимой мере ускорить нереально и на это можно не заморачиваться, или нужно копать в какую-то другую сторону?

Здравствуйте, Went, Вы писали:

Да, нужно копать в другую сторону. Или аллоцировать заранее с запасом.

А в чем именно у вас проблема? Какую задачу решаете? Какая цель?

Так-то именно со скоростью выделения памяти не должно быть проблем.

— у вектора есть reserve(), есть implace(), есть кастомные аллокаторы
— есть std::array
— можно сделать свою реализацию

Здравствуйте, Went, Вы писали:

W>Здравствуйте.
W>Аллокацию контейнеров, которые выделяют память поэлементно (map, list), ускорить можно и значительно, используя pools. Для vector-подобных контейнеров это не работает, так как там память выделяется большими кусками и всегда разного размера. Тот же boost::pool_allocator, примененный к вектору, не дал мне никаких выгод по сравнению со стандартной реализацией. Означает ли это, что аллокацию таких контейнеров в ощутимой мере ускорить нереально и на это можно не заморачиваться, или нужно копать в какую-то другую сторону?

А как часто у вас происходит новые выделения памяти для вектора ?
Возможно вам стоит зарезервировать заранее больше памяти, а может вам нужен другой контейнер.

Здравствуйте, _NN_, Вы писали:

_NN>А как часто у вас происходит новые выделения памяти для вектора ?
_NN>Возможно вам стоит зарезервировать заранее больше памяти, а может вам нужен другой контейнер.
Задача стоит в целом ускорить выделение и освобождение памяти в системе. Я ускорил выделение отдельных объектов и дробных контейнеров за счёт пулов. Ну, и смотрю, где ещё можно урвать. То, что правильный резерв или вообще подбор контейнера решает — я знаю.

Здравствуйте, DiPaolo, Вы писали:

DP>А в чем именно у вас проблема? Какую задачу решаете? Какая цель?
Общее ускорение там, где можно. Читайте ниже

Здравствуйте, Went, Вы писали:

W>Здравствуйте.
W>Аллокацию контейнеров, которые выделяют память поэлементно (map, list), ускорить можно и значительно, используя pools. Для vector-подобных контейнеров это не работает, так как там память выделяется большими кусками и всегда разного размера. Тот же boost::pool_allocator, примененный к вектору, не дал мне никаких выгод по сравнению со стандартной реализацией. Означает ли это, что аллокацию таких контейнеров в ощутимой мере ускорить нереально и на это можно не заморачиваться, или нужно копать в какую-то другую сторону?

Что у вас с многопоточностью? Если она отсуствует, то можно значительно ускорить выделение.

Здравствуйте, SaZ, Вы писали:

SaZ>Что у вас с многопоточностью? Если она отсуствует, то можно значительно ускорить выделение.
Присутствует

Здравствуйте, SaZ, Вы писали:

SaZ>Что у вас с многопоточностью? Если она отсуствует, то можно значительно ускорить выделение.

Может поделитись инфой или ссылками? Меня очень интересует тема максимально быстрого выделения памяти именно без многопоточности.

Здравствуйте, ksandro, Вы писали:

K>Меня очень интересует тема максимально быстрого выделения памяти именно без многопоточности.

для каких целей ? чтоб программа быстрее стартовала ?

или надо пересоздавать большие вектора в памяти или что ? тогда можешь попробовать пере использовать уже созданные пере инициализируя их или зануляя (memset'ом условно) ..

или нужно много мелких пересоздавать ?

выложи код, посмотрим что там делаешь — и напиши сколько он затрачивает времени на твоих данных и насколько ты хочешь снизить его ?

Здравствуйте, xma, Вы писали:

xma>Здравствуйте, ksandro, Вы писали:

K>>Меня очень интересует тема максимально быстрого выделения памяти именно без многопоточности.

xma>для каких целей ? чтоб программа быстрее стартовала ?

xma>или надо пересоздавать большие вектора в памяти или что ? тогда можешь попробовать пере использовать уже созданные пере инициализируя их или зануляя (memset'ом условно) ..

xma>или нужно много мелких пересоздавать ?

xma>выложи код, посмотрим что там делаешь — и напиши сколько он затрачивает времени на твоих данных и насколько ты хочешь снизить его ?

Лично у меня никаких конкретных целей нет. Но было сообщение, о том, что существуют методы значительно ускорить выделение памяти, используя именно специфику того, что программа однопоточная. Вот про это мне и интересно узнать поподробнее. Из того что написал ты, я не вижу ничего про оптимизацию, специфичную именно для программы, без использования многопоточности.

Здравствуйте, ksandro, Вы писали:

K>Здравствуйте, SaZ, Вы писали:

SaZ>>Что у вас с многопоточностью? Если она отсуствует, то можно значительно ускорить выделение.

K>Может поделитись инфой или ссылками? Меня очень интересует тема максимально быстрого выделения памяти именно без многопоточности.
Ну, очевидно, что отсутствие синхронизации (мьютексов) на функции выделения и освобождения сделает тебе очень немалый прирост. Не зря столько копий сломано вокруг "неблокирующих аллокаторов".

Здравствуйте, Went, Вы писали:

W>Ну, очевидно, что отсутствие синхронизации (мьютексов) на функции выделения и освобождения сделает тебе очень немалый прирост. Не зря столько копий сломано вокруг "неблокирующих аллокаторов".

Теоретическая часть вполне понятна. Интересна практика: какие есть реализации аллокаторов, оптимизированных для однопоточных программ, Может уже есть реализации в стандартной библиотеке в бусте или еще в каких-нибудь библиотеках. Межет быть есть какие-нибудь опции в современных компиляторах, может еще, что-то. Может где-то есть статьи по теме. Вопрос в том, в какую вообще сторону копать именно по теме оптимизации для однопоточных программ. Почти всегда очень много уделяется внимания ра,оте в многопоточной среде, а про оптимизацию для одного потока как-то вообще мало инфы.

Arena allocator

Здравствуйте, ksandro, Вы писали:

K>Теоретическая часть вполне понятна. Интересна практика: какие есть реализации аллокаторов, оптимизированных для однопоточных программ, Может уже есть реализации в стандартной библиотеке в бусте или еще в каких-нибудь библиотеках. Межет быть есть какие-нибудь опции в современных компиляторах, может еще, что-то. Может где-то есть статьи по теме. Вопрос в том, в какую вообще сторону копать именно по теме оптимизации для однопоточных программ. Почти всегда очень много уделяется внимания ра,оте в многопоточной среде, а про оптимизацию для одного потока как-то вообще мало инфы.
Да, как раз это я и ищу в ветке выше. Там порекомендовали std::pmr::unsynchronized_storage. Пока что нет возможности проверить его реальное быстродействие. Сам пока что накидал однопоточный аллокатор-кеш, который берет память через обычный new, но вместо delete "складывает" куски памяти "на будущее" в кеш. Такая "куча" есть своя на каждый заинтересованный поток, а для случая удаления объекта не из того потока, в котором он рожден, сделал простой неблокирующий алгоритм. В результате имею где-то 4х кратное ускорение на гугл-бенчмарках.

Здравствуйте, ksandro, Вы писали:

Может попробовать взять любой быстрый аллокатор и убрать из него весь код синхронизации?
https://github.com/bytemaster/fc_malloc