Поиск лучшего способа управления памятью наконец-то закончен?

Проблемы виртуального адресного пространства

С момента выпуска ArmA причиной самых больших проблем стабильности и совместимости было исчерпывание виртуального адресного пространства. Проблема в том, что игре нужно хранить много данных, используя много виртуальных адресов, но в тоже время большое количество этого пространства используется другими частями системы, самая значимая - это драйвер видеокарты. Проблема началась даже до выпуска ArmA, во времена Operation Flashpoint, когда появились первые видеокарты от 256 MB RAM. Flashpoint был ещё менее стабильным чем ArmA на той же системе, и причиной этого было то, что он использовал memory mapping для доступа к файлам. Не смотря на то, что эту систему легко и просто использовать, она сжирает много виртуального пространства. Мы сделали альтернативное решение для доступа к файлам (известный параметр -nomap в командной строке). Для ArmA мы полностью переделали доступ к файлам, без использования file mapping, вместо него обычный API. В это же время мы перешли на Overlapped I/O, чтобы мы могли фоново загружать текстуры и другие ресурсы. Мы (и вы) поняли, что этого недостаточно.

Есть ли предел?

Сейчас происходит следующее: операционная система даёт каждому приложению 2 ГБ адресного пространства. 2 ГБ звучит как-то ограниченно, но это не так уж и плохо - у некоторых людей в любом случае больше оперативной памяти. Теперь важно заметить, что мы не говорим сейчас про RAM (физическую память), мы говорим про адресное пространство. Приложение ограничивается 2 ГБайтами, поэтому независимо от того стоит ли у вас 512 МБ RAM или 4 ГБ - это совершенно не имеет значения.

Эти 2 ГБ используются для всего, что необходимо программе. Последние драйвера видеокарт съедают несколько сотен МБ. Ещё хуже то, что некоторые системные компоненты используют ресурсы то тут, то там, фрагментируя это пространство на малые регионы. Мой опыт показывает, что игровому коду практически невозможно выделить больше, чем 700-900 МБ виртуального пространства без проблем со стабильностью системы - мы не говорим про одно большое выделение, а про несколько 10-100 МБайтных кусков. Программисты драйверов, похоже, не замечают того, что адресное пространство - ограниченный ресурс, и соответственно драйверы часто не обрабатывают ошибки распределения памяти. Это значит, что когда игра выделяет слишком много виртуального пространства, могут происходить странные вещи, например, треугольники на экране, или, иногда, даже перезагрузка системы.

Будущее - 64 бита

Решение в перспективе - переход на 64-битные операционные системы и компиляция игры как 64-битное приложение. Такое решение практически невозможно для ArmA, частично из-за того, что ещё не все используют 64-битную ОС, а также частично из-за слишком больших изменений и необходимого для этого времени и ресурсов.

Мы провели различные эксперименты и оптимизации с разными результатами в нескольких патчах (смотрите тему форума), но ни один из них не работал достаточно хорошо, каждое решение ухудшало либо стабильность, либо производительность на некоторых системах. В то время, как мы продолжали разработку ArmA 2, нем необходимо было распределять ещё больше ресурсов и ещё больше памяти, и мы становились всё больше и больше ограниченными, до того момента, когда игра вообще не могла идти нормально на большинстве систем.

Память без адреса

В один день пришла идея, как и подобные идеи обычно приходят, из ниоткуда. Как обычно с подобными идеями, как только система разработана, она оказывается очень очевидной, но я никогда не слышал, чтобы что-то подобное использовали раньше, поэтому я довольно таки горжусь этой разработкой. Я называю эту технологию - Non-addressable Memory Store.

Она основана на использовании File Mapping API. Да, вы правильно понимаете, тот же API, из-за которого возникали проблемы в Flashpoint, но на этот раз он используется совсем иначе, не для чтения файлов, а как способ распределения памяти:

* при инициализации игры резервируется достаточно памяти, используя CreateFileMapping API. Это потребляет физическую память, а не виртуальную
* при сохранении или считывании страницы данных, создаётся временный вид при помощи MapViewOfFile, который уничтожается, когда в нём больше нет необходимости. При этом используется очень мало виртуального пространства (64 КБ). Обычно только несколько страниц распределяются в памяти таким образом одновременно.

Windows хорошо работает с таким алгоритмом, несмотря на то, что в теории может использоваться "файл подкачки", на практике получается, что пока есть свободная физическая память, никакого взаимодействия с файлом подкачки нет, и вся информация обрабатывается только в физической памяти. Память, которая хранится в подобном виде, не привязана ни к какому адресу, она определяется сдвигом. Адреса назначаются только временно, при считывании содержимого кэша. Это всё возможно благодаря тому, что данные, которые хранятся в файловом кэше, не зависят от расположения (не содержат указателей).

Прорыв

Этот метод в теории позволяет даже для 32-битных приложений использовать больше памяти, чем позволяет 32-битное пространство - размер ограничен только возможным размером file mapping, и свободной памятью, вследствие с 32-битной ОС можно будет управлять приблизительно 3 ГБ данных, а с 64-битной ОС даже больше. Но этого в ArmA мы делать не будем, эксперименты показали, что файл кэша размером больше 512 МБ практически ничего не улучшает потому, что мы всё равно не считываем так много данных, но для других приложений это может быть полезно. Это всё не ограничено кэшированием файлов, можно хранить любое содержимое, с одним ограничением - приложение никогда не должно указывать на участок памяти, который выделен таким образом, используя обычные постоянные указатели потому, что эти указатели станут недействительными, как только память будет выделена.

Для ArmA это значит, что внутренний файловый кэш, размер которого около 100 - 500 МБ, в зависимости от количества памяти (или в зависимости от параметра -maxmem), теперь не использует виртуальное пространство вообще. Эти несколько сотен мегабайт, похоже, что спасают остальные части системы. Похоже, что мы наконец-то решили известную ошибку "Cannot allocate system memory surface" практически на всех тестовых системах, без ограничения используемой памяти.

Это станет доступным в ближайшем патче

Этот тип работы с памятью будет включён в следующий патч 1.11, и, я надеюсь, что вам он понравится также как мне.

Источник: armedassault.kiev.ua
Перевод: © Messiah