Alternatives to malloc and new - статья про то, как происходит аллокация памяти, как и почему это ведет к фрагментации. И про то, как можно с этим бороться - управлять памятью самостоятельно. Всё с красивыми и понятными картинками.
Это актуально в разработке игр, например.
Статьи по теме:
Virtual Addressing 101
Start Pre-allocating And Stop Worrying
Region-based memory management
воскресенье, февраля 20, 2011
Статья про управление памятью
в 10:55:00
Категории: programming
Подписаться на:
Комментарии к сообщению (Atom)
9 коммент.:
Существуют ли готовые общепризнанные библиотеки для управления памятью в сфере разработки игр? Или все пишут свои велосипеды?
Свои способы, например, есть и в glib и в apr-lib.
да и не только в разработке игр свои велосипеды.
третий большой и старый проект и третий менеджер памяти, свой и недоделаный.
очень хочется заменить это на что-нибудь стандартное и отлаженое и выкинуть эту кучу подозрительного кода.
mkevac
Существуют ли готовые общепризнанные библиотеки для управления памятью в сфере разработки игр? Или все пишут свои велосипеды?
Свои велосипеды, по велосипеду на компанию. В какой-то мере это оправдано тем, что требования к менеджеру памяти зависят от конкретной игры и от платформы.
А не мог бы кто-нибудь на пальцах объяснить, как обращаются с пиковыми аллокациями в пуле? По моему представлению, при выделении, например, 100 элементов по 1Мб, а затем освобождении 97 из них, с оставшимися 3 на случайных позициях, получаем дикую фрагментацию памяти с невозможностью освободить выделенные 100Мб. И если дальше этот пул не будет использоваться, то так и останется 97Мб зарезервированной но неиспользуемой памяти, или же это как-то обходится?
R
И если дальше этот пул не будет использоваться, то так и останется 97Мб зарезервированной но неиспользуемой памяти, или же это как-то обходится?
Менеджер памяти пишется под конкретные задачи. И если возможна ситуация, когда у нас осталось 3 элемента, размазанных по пулу, то получается, что в менеджере что-то не продумано.
Можно двигать элементы в ситуации "у нас мало
элементов и они размазаны по пулу".
В геймдеве часто встречается ситуация "у нас всего три элемента в пуле, но уровень уже закончился, они нам не нужны, мы освобождаем весь пул целиком".
Ну и наверняка можно еще чего-нибудь придумать.
Алёна,
но ведь для возможности передвижения элементов понадобится косвенная адресация вместо прямой (например указатель на указатель), что будет менее эффективно - часто ли такое используется?
Получается, в геймдеве чуть ли не под каждый чих делается менеджер памяти? Сколько же их тогда существенно различных (не только по размеру блока, по алгоритму и т.п.) в среднестатистической игре, если не секрет?
R
Алёна,
но ведь для возможности передвижения элементов понадобится косвенная адресация вместо прямой (например указатель на указатель), что будет менее эффективно - часто ли такое используется?
Я такое не встречала. Просто предложила как вариант.
Получается, в геймдеве чуть ли не под каждый чих делается менеджер памяти?
Репрезентативной статистики у меня нет. Скажем так, свои менеджеры памяти в геймдеве встречаются довольно часто.
Сколько же их тогда существенно различных (не только по размеру блока, по алгоритму и т.п.) в среднестатистической игре, если не секрет?
Из того, что я видела - один. Причем не один на игру, на один на компанию. Часто в компании код на самом низком уровне можно заново использовать в разных играх.
Алёна, спасибо за ответы!
Спасибо за статью, сильно удивился очевидной в общем-то идее хранения списка свободных элементов пула в самом пуле.
Сылка по теме - выступление Андрея Плахова на КРИ 2008, озаглавленное "Дзэн":
http://www.kriconf.ru/2010/rec/KRI_2008_Programming_19apr_Neptune_03_Plahov_Andrei_Vogster.ogg. Было где-то еще видео, но не смог найти.
Мы у себя потихоньку стараемся расти в этом направлении - если в игре может быть максимум 100 пуль, сразу заведем выделим пул подо все 100. Если вылетает 101ая пуля, то она не вылетает..
Отправить комментарий