Здравствуйте, kaa.python, Вы писали:
KP>скорее интересны причины поиска.
Это совершенно ни разу не desktop-приложение.
Хочу дать больше простора для маневра вышележащим системам, чтобы они могли легче укладываться в наши временные нормативы. Поэтому после алгоритмической оптимизации, взялся за низкоуровневую. Железо у нас фиксированное.
В общем посмотрел профайлером, оказалось, что много времени тратится на синхронизацию, также у меня не нужно выравнивать адреса выдаваемых блоков памяти.
Я вполне в состоянии написать подобный аллокатор самостоятельно, но сперва решил поискать что-то готовое.
Привет, а не подскажете как пришли к мнению о том, что нужен собственный аллокатор? Какие-то тесты, теоретические размышления или ещё что-то? Не пытаюсь сказать что он вам не нужен, скорее интересны причины поиска.
Здравствуйте, wander, Вы писали:
W>Нужен для выделения буферов разного (но не больше двух-трех килобайт) размера.
Аллокатор, который распоряжается блоками одинакового размера, может быть сделан ОЧЕНЬ быстрым.
Для многих проектов подходит такое решение: делаем все блоки аллокации равными по размеру самому большому блоку. Ну или, если памяти очень жалко, можно попробовать выбрать несколько (небольшое количество) ходовых размеров, и выделять подходящий из них.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, wander, Вы писали:
W>>Нужен для выделения буферов разного (но не больше двух-трех килобайт) размера.
Pzz>Аллокатор, который распоряжается блоками одинакового размера, может быть сделан ОЧЕНЬ быстрым.
Pzz>Для многих проектов подходит такое решение: делаем все блоки аллокации равными по размеру самому большому блоку. Ну или, если памяти очень жалко, можно попробовать выбрать несколько (небольшое количество) ходовых размеров, и выделять подходящий из них.
Нужны блоки разного размера, грубо говоря о 30 байт до 1-2 килобайт.
Дополнительно напомню, что написать аллокатор самому не проблема. Пока что я спрашиваю про готовое решение.
Здравствуйте, wander, Вы писали:
W>Нужны блоки разного размера, грубо говоря о 30 байт до 1-2 килобайт.
А точно ли нужны? 30 байт обычно влезает в 2 килобайта. Или у вас много маленьких аллокаций.
W>Дополнительно напомню, что написать аллокатор самому не проблема. Пока что я спрашиваю про готовое решение.
Поддержу Капитона. Ты уже пробовал какой-нибудь jemalloc и он тебе не подошел?
Не понятно из каких соображений выбирается аллокатор. Хочется, чтобы их озвучили. "Хочу что-то быстрее стандартного" — звучит не убедительно. А для меня jemalloc очень даже стандартный и я очень сомневаюсь, что можно сделать в реальной задаче что-то быстрее.
Здравствуйте, Masterspline, Вы писали:
M>Не понятно из каких соображений выбирается аллокатор. Хочется, чтобы их озвучили.
Я их озвучил в стартовом посте. В любом general purpose аллокаторе (и в jemalloc тоже) поддерживается многопоточность и выравнивание адресов выдаваемых порций памяти. Мне это все не нужно. Собственно уже только лишь за счет этого можно ждать ускорения.
Здравствуйте, wander, Вы писали:
W>Я их озвучил в стартовом посте. В любом general purpose аллокаторе (и в jemalloc тоже) поддерживается многопоточность и выравнивание адресов выдаваемых порций памяти. Мне это все не нужно. Собственно уже только лишь за счет этого можно ждать ускорения.
jemalloc не выравнивает и он не синхронизирует, если ты в одном потоке выделяешь и удаляешь (у каждого потока кэш в TLS)
Здравствуйте, chaotic-kotik, Вы писали:
CK>jemalloc не выравнивает и он не синхронизирует, если ты в одном потоке выделяешь и удаляешь (у каждого потока кэш в TLS)
Если так, то это здорово. Однако похоже его все-таки надо настроить на, по крайней мере, работу без выравнивания,
потому что поведение по умолчанию требует, чтобы выравнивание было (иначе его нельзя было бы просто так использовать в качестве замены обычного malloc`а).
