Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Fastest Allocator Possible (FAP) - самый быстрый в мире аллокатор, С++ (2 стр)

Fastest Allocator Possible (FAP) - самый быстрый в мире аллокатор, С++ (2 стр)

Поделиться

Страницы: 1 2 3 4 Следующая

ВийПостоялецwww28 авг. 201513:03#15
kvakvs
смотрим на картинку

Изображение

Нас интересуют случаи с 1, 2 и 3 потоками. Какой аллокатор из перечисленных взять?

kvakvsПостоялецwww28 авг. 201515:16#16
Вий
> Какой аллокатор из перечисленных взять?
Что делает тест?
Почему такой разброс размеров блоков? 32...1Мб
Какая задача решается в приложении? Игра? Что делает игра?
Какой характер алгоритма и выделяемых блоков памяти, и как часто они освобождаются?
Можно ли их группировать по размеру и освобождать все вместе? Можно ли группировать по задаче и освобождать блок одной задачи целиком? Второй вариант попутно поможет локальности данных.
Обязательно ли вперемешку выделять и освобождать память разными потоками в 1 аллокаторе?
laMer007Удалёнwww28 авг. 201515:20#17
Вий
> поддержка канареек
Ня?
laMer007Удалёнwww28 авг. 201515:22#18
kvakvs
> Зачем двум тредам общая память?
Люблю передать во владение смартпоинтер из одного треда в другой

Правка: 28 авг. 2015 15:22

MiraПостоялецwww28 авг. 201515:23#19
Самый быстрый не самый главный показатель мм.
Вернее главный но их 3:
Скорость
Оверхед блоков
Фрагментация

Как правило прокачка одной из характеристик давит другую.

xПостоялецwww28 авг. 201515:30#20
>При этом с А у тебя эффективно есть 90% памяти
>А с Б у тебя только 80%
Ты б почитал может что по теме сначала?
Ты никак не можешь гарантировать, что эффективно 80% или 90% памяти, если ты ничего для этого специально не сделал.
ВийПостоялецwww28 авг. 201516:12#21
Mira
> Как правило прокачка одной из характеристик давит другую.
Да, и вот в случае, когда есть варианты вида "чуть меньше оверхед блоков/фрагментация или чуть быстрее аллокация/деаллокация", при разработке FAP выбор будет в пользу "чуть быстрее". Да, на самом деле FAP в виде одного универсального аллокатора не выйдет, потому что быстрее всего - arena без вызова дестуркторов, и ей можно и нужно пользоваться, но только не везде она подходит. FAP будет по сути несколькими аллокаторами, начиная с аллокатора общего назначения и заканчивая аналогом арены

x
> Ты никак не можешь гарантировать, что эффективно 80% или 90% памяти, если ты
> ничего для этого специально не сделал.
Мне не надо это гарантировать, мне достаточно увидеть, что на моей конкретной игре смена аллокатора дает прирост необходимой для работы программы памяти и рост скорости аллокаций /fps/падение времени инициализации

kvakvs
> Обязательно ли вперемешку выделять и освобождать память разными потоками в 1
> аллокаторе?
Да. Иначе я бы и не захотел такой аллокатор.

Правка: 28 авг. 2015 16:56

exchgПостоялецwww28 авг. 201518:04#22
Вий
> Отговорите меня, пожалуйста.
SLAB allocator.
WindreamIceПостоялецwww28 авг. 201518:35#23
Вий
>Ну и в этом аллокаторе главное - именно скорость, а не качественная дефрагментация
Если проблем в количестве памяти нет,
То выделяешь на каждый Трид свой блок памяти и никаких блокировок,
для больших аллокаций можно юзать общий пул с мутексами )

>А проблема фрагментации при мелких аллокациях решается...
Вот в этом проблема решений много, а какие хорошие без понятия,
так как определяются по факту)

exchg
>SLAB allocator.
обычный обжект мемори пул одного типа,
к сожалению никак не решает проблем фрагментации при ограниченном объеме памяти
и большом количестве разных алокацый.
Хотя штука неплохая)

Правка: 28 авг. 2015 18:35

exchgПостоялецwww28 авг. 201518:38#24
WindreamIce
> обычный обжект мемори пул одного типа,
да ну нет, не совсем так.

WindreamIce
> к сожалению никак не решает проблем фрагментации
как не решает если весь смысл слаба какраз избавится от фрагментации и оверхэда?

BishopПостоялецwww28 авг. 201518:39#25
kvakvs
> Придумали всякое.
Например?

Вий
> Это если аллокация и освобождение из одного потока вызывались, а если из разных
> - то можно придумать много всякого гораздо лучше пула на односвязном списке
Неа. Просто делается небольшая модификация и всё.

x
> Что там с борьбой с фрагментацией?
+1. Именно это и есть главная проблема хипов.

kvakvs
> 3. Универсального решения нет.
+100500

Вий
> смотрим на картинку
Вот только выводы их неё немного не те, что ты думаешь.

WindreamIce
> обычный обжект мемори пул одного типа,
> к сожалению никак не решает проблем фрагментации при ограниченном объеме
> памяти
> и большом количестве разных алокацый.
> Хотя штука неплохая)
Ну когда такие проблемы с памятью их борят не только элокатором, но и работой с логикой приложения. Ну чтобы меньше различных размеров блоков было и т.п.

WindreamIceПостоялецwww28 авг. 201518:47#26
exchg
>как не решает если весь смысл слаба какраз избавится от фрагментации и оверхэда?

>при ограниченном объеме памяти
Ну смотри пример:
есть у тебя два блока памяти
один для обжектов в 8 байт, второй на 32.
оба дырявые - так как обжекты юзаются и удаляются.

А теперь надо в эти два блока впихнут обжект размером 200,
надо теперь фрагментирвать и уменьшат конец N пула,

а если надо обьеденить два пула - нет места под 200,
то ещё фрагментирвать начало одного и конец другого пулов.

короче решаемо но не с коробки)

(и проблемы растут по мере роста: количества и размера пулов)

Bishop
>Ну когда такие проблемы с памятью их борят не только элокатором, но и работой с логикой приложения
Не всегда, - это ж отдельная либа,
мало кто будет под либу переписывать большой проект чтоб не было цельных объектов размером больше 64 байт к примеру.
Но безусловно это решает многое.

(к примеру еслиб сделать тег во время компиляции как цельный обжект можно разбить на куски без вреда,
и если нет претензий к длине мемори пойнтеров то все будет кул, кроме прямого копирования обжектов 1 блоком =))

Правка: 28 авг. 2015 18:58

exchgПостоялецwww28 авг. 201518:56#27
WindreamIce
> А теперь надо в эти два блока впихнут обжект размером 200
> надо теперь фрагментирвать и уменьшат конец N пула
ну так слаб какраз и не будет никуда впихивать, и 200 байт будут выделены из блока который
отведен для 200 байтных "объектов".


WindreamIce
> а если надо обьеденить два пула - нет места под 200,
> то ещё фрагментирвать начало одного и конец другого пулов.
ненадо ))) смысл в том чтобы заранее отвести пямять под "объекты"
разного размера и по требованию выдавать адреса свободных блоков
заданного размера (это если сильно упростить).

WindreamIceПостоялецwww28 авг. 201518:59#28
exchg
>и 200 байт будут выделены из блока который отведен для 200 байтных "объектов".

под него нет памяти)
>при ограниченном объеме памяти
в этом и смысл фрагментации
200* - это мифическая цифра
по факту намного чаще будут ситуации есть пул на 100 обжектов, а надо пул на 300,
а через фрейм надо увеличить другой пул и места уже нет,
а в этом что на 300 занято всего 50.

Правка: 28 авг. 2015 19:03

exchgПостоялецwww28 авг. 201519:06#29
WindreamIce
> по факту намного чаще будут ситуации есть пул на 100 обжектов, а надо пул на
> 300,
> а через фрейм надо увеличить другой пул и места уже нет,
> а в этом что на 300 занято всего 50.
ну в таком случае да, аут оф мемори, все приехали, хотя за частоту такой ситуации я б еще поспорил.
Но тоже самое случится и с кучей.

Страницы: 1 2 3 4 Следующая

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр