Чому для активів потрібне спеціальне управління пам’яттю?

Практично всі ресурси, що стосуються програмування ігор, особливо 3D-ігри з відкритим світом, говорять про те, як вам доведеться постійно вивантажувати та перезавантажувати активи на диск і з нього, системну пам'ять та відеопам'ять. Я можу це зрозуміти на консолях, оскільки вони мають дуже прості схеми управління пам'яттю, які не можуть вирішити жоден потенційний переповнення.

Однак на ПК ситуація дуже різна. Існує віртуальна пам'ять, що надається ОС для системної пам’яті, а графічний драйвер обміняється з центрального процесора на графічний процесор. То чому ж не достатньо завантажувати все одразу, а лише мати справу з попередньою завантаженням та, можливо, переконанням у відсутності блокування під час заміни необхідного активу?

Це не означає, що все наївно виділяється, використовуючи щось подібне malloc. Все буде зберігатися безперервно і кеш-узгоджено. Можливо, простіше зробити доступ до пам’яті ефективним, якщо вам не доведеться турбуватися про підключення та виведення вручну вручну…

ОНОВЛЕННЯ:

Прочитавши трохи передачі асинхронного буфера , я розумію, що спосіб графічного драйвера може автоматично заповнювати пам'ять сторінок і надходити неоптимально. Чи справедливо це і для ресурсів процесора; тобто, чи краще завжди вручну керувати, коли певний ресурс потрібно завантажувати та вивантажувати навіть за наявності віртуальної пам'яті?

Сучасні ігри відкритого світу просто не вписуються в пам’ять. Майте на увазі, що більшість ігор все ще 32-розрядні через кількість геймерів з 32-бітовими ОС, а 32-бітний процес у кращому випадку може мати лише 4 ГБ адресованої пам’яті одночасно (незалежно від віртуальної пам’яті), але реально це обмежено 2-3 ГБ. Закидання фрагментації та фактичної кількості об'єктів, які можна використовувати у пам’яті одночасно, є дещо меншим, ніж загальна кількість даних, необхідних для великого середовища. Навіть на 64-бітній ОС вам часто потрібно націлити машини з низькими показниками, які мають лише 4 Гб пам'яті, щоб забезпечити максимальну сумісність для кінцевих користувачів. Не будемо забувати про мобільні пристрої, "недостатнє живлення" апаратних засобів, таких як WiiU тощо. Розробникам доводиться орієнтуватися набагато більше, ніж великі модні ігрові платформи.

Віртуальна пам'ять не є рішенням, по-перше, тому, що вона не скасовує обмеження адресного простору, а також тому, що вона не є оптимальною. ОС може розшифровувати речі в невідповідний час або невідповідним чином. З цією проблемою вирішували ОС, коли сплячка спливала вперше; завантаження процесів на диск, а потім їх перезавантаження в деяких випадках було значно повільніше, ніж додаток явно перетікає ресурс назад. Ви все ще можете побачити проблеми сьогодні, коли в системі не вистачає пам'яті, сторінки видаються на сторінку диск, і система не реагує, стає критичною справою, необхідною для запуску програми WM / explorer.exe. Віртуальна пам'ять була вирішенням проблеми, розробленої десятиліттями тому, коли системи мали дуже мало оперативної пам’яті, а розрив між швидкістю пам’яті та диском був значно меншим. Навіть сьогодні' s найшвидші SSD - це невелика частка швидкості дешевої / повільної оперативної пам’яті, і намагання зробити вигляд, що ви можете використовувати свій диск як віртуальну оперативну пам’ять, просто вже не найкраща ідея. Це епоха, коли деякі люди роблять навпаки і завантажують файлові системи в диски оперативної пам'яті; обмеження, які призвели до створення віртуальної пам’яті, більше не відповідають дійсності.

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

Для 32-розрядної гри, як і більшість ігор з різних причин, навіть гра, яка поставляється на одному односторонньому DVD (4,3 ГБ), вже має набагато більше вмісту, який можна помістити в 32-бітний адресний простір. І це припускаючи, що вміст не стискається на диску, і ідеально оптимально завантажувати все одразу в суміжний підхід до адресного простору. Зараз багато ігор на кількох DVD-дисках, що легко перевершує 10 Гб вмісту. З мого досвіду роботи на ПК, коли ваш адресний простір наблизиться до 2 ГБ, почне виходити з ладу, і це стає важкою межею, незалежно від того, скільки фізичної пам'яті у користувача.

Якщо ви зробите перехід до 64-розрядних версій, якщо припустити, що ваш двигун підтримує це жорстке обмеження, воно буде замінено на ефективний м'який ліміт - як тільки заміни віртуальної пам'яті почнуть відбуватися, продуктивність гри знизиться неприпустимо. Якщо основний процес коли-небудь дочекається, коли пам’ять буде перезапущена, частота кадрів буде заїкатися і збиватися. Віртуальна пам’ять може зробити це прозорим, але це не робить його виконаним. Фізично потрібен час, щоб повернути цю пам'ять з диска, і поки ви чекаєте, ваша гра затихла. Незважаючи на те, що можна обійтись (із попередньою обробкою сторінок пам'яті, які знають, що вам знадобиться незабаром), це складний і ненадійний процес, який все ще матиме наслідки для продуктивності.

Алгоритми ОС для вирішення, які сторінки потрібно замінити на диск, не знають про вашу гру і що, ймовірно, знадобиться далі. Крім того, ОС все ще повинна підтримувати інші програми, що працюють одночасно з вашою грою, а також саму ОС. Наявність затримки, коли сторінки повертаються з диска, - це величезний хіт продуктивності, і не має значення, чи це ваша гра, інше додаток чи ОС, яка впливає на неї, продуктивність гри буде серйозно страждати.

Тож незалежно від того, чи є обмеження пам'яті м'яким чи жорстким, пам'ять все ще обмежена. Але навіть якщо ви можете просто завантажити все одразу, не зачіпаючи обмеження продуктивності, все ж є причини, чому ви не хочете:

1. Ваша гра займає набагато більше часу, щоб завантажитися та дійти до інтерактивного стану, ніж потрібно, тому що вона просто завантажує все на початку та залишає її резидентом. Ви можете завантажувати близько 150 Мб / сек з жорсткого диска, і навіть найшвидший диск DVD (24x) завантажується зі швидкістю 33 МБ / сек. Це означає, що приклад завантаження вмісту DVD, розміром 4,3 Гб, потребуватиме щонайменше 30 секунд для завантаження з жорсткого диска та понад 133 секунд для завантаження з DVD. Це неприпустимо тривалий час завантаження.

2. Ваша гра займає набагато більше пам’яті, ніж виправдана. Якщо в будь-який час видно лише 10% вмісту, утримування решти решти просто марно, і заважає користувачеві використовувати цю пам'ять для чогось іншого. Користувачі, як правило, не відмовляються від ігор, для правильного використання яких потрібна непропорційно велика кількість пам'яті.

Динамічна трансляція ресурсів з диска, у фоновому режимі чи синхронно під час завантажувального екрана, дозволяє бути набагато ефективнішою у використанні пам'яті, з незначними зусиллями та лише незначним недоліком для користувача. Але це оптимізація, і як і будь-яка інша оптимізація, вона зменшується, повертається тим більше, як ви намагаєтесь її застосувати. У якийсь момент збільшення сліду пам’яті для збереження чогось резидента переважає переваги, отримані від наявності його без необхідності завантажувати. Але поки ця точка не буде досягнута, краще завантажувати лише те, що потрібно, коли це потрібно.

Якщо говорити дуже загально та спрощено, і не враховуючи деталей реалізації віртуальної пам’яті, розробник завжди має знання в передбачуваності, яких не вистачає в реалізації VM.

Розробник завжди може сказати: "Мені не потрібно зараз завантажувати цей аудіофайл. Музика всередині використовується лише для гри через екран". І одразу після гри через екран розробник може сказати: "Цей аудіокліп мені більше не потрібен у фізичній пам'яті. Він використовується лише для цієї гри через екран".

ОС не має такого передбачення. Можливо, пізніше багато помилок сторінок зможуть з’ясувати, що якийсь аудіокліп більше не потрібен фізичній пам’яті, оскільки до нього не було доступно задовго. Але перетворення передбачення на заднім число перетворюється на безліч помилок сторінки, і багато помилок сторінки перетворюється на гикавку в частоті кадрів у програмному забезпеченні, настільки ж критичному, як і відеоігра. Там передбачуваність розробника справді допомагає, якщо ви хочете уникати таких гикавок.

І це стосується концептуально незалежно від обладнання та програмного забезпечення. Якщо припустити, що пейджинг в пам'яті коштує дорого, то передбачення розробника завжди допоможе зменшити ці витрати.

Якщо говорити ще ширше, існує нескінченний цикл між дизайнером обладнання, дизайнером компілятора, дизайнером ОС / драйверів та розробником додатків. Розробники апаратних / компіляторних / ОС / драйверів часто намагаються здійснити оптимізацію для прискорення середнього додатка на основі його звичних моделей доступу до пам'яті, а може, іноді і з надією на кшталт: «Люди повинні просто вміти писати код, як вони хочуть, і це має бути швидким ».Але якщо виникала якась думка цього типу, зазвичай це не вдається для критично важливих для продуктивності полів, оскільки тоді розробники з критичними показниками продуктивності починають вивчати складні деталі свого компілятора, апаратного забезпечення, ОС, драйверів тощо і починають писати код конкретно розроблений для того, щоб якомога більше писати найшвидший код (наприклад, попередні вибори, розбиття гарячого / холодного поля, SoAs тощо для зручного кешу). І це як гра, яка ніколи не закінчується. Ці речі ніколи не розглядаються як чорні поля в критичних для продуктивності полях, оскільки розробники змагаються за продуктивність.

Особисто мені хотілося б, щоб віртуальна пам’ять не існувала, оскільки вона додає додатковий шар непередбачуваності продуктивності способами, які, як правило, занадто екстремальні і нестимучі, занадто багато штрафу за продуктивність, коли справи йдуть на південь до точки непридатності. Я іноді натрапляю на випадки, коли я використовував якусь програму, коли я випадково набрав додаткову цифру чи дві, коли опинився в якомусь полі вводу, що потім змусило його так швидко вичерпати фізичну пам'ять способами, що привели ОС до сканування, де я не міг ' t навіть натискайте кнопку "Скасувати" на панелі прогресу і мені довелося чекати 10 хвилин, поки заклинає Ctrl + Alt + Del, щоб вбити процес і проклинати себе під час розливу мого напою, щоб повернутися до моменту, коли речі знову можна використовувати, і це незважаючи на збереження файлу сторінки на SSD. У тих випадках я вважаю за краще помилку "поза пам'яттю" або щось подібне, і тоді я можу закрити деякі з моїх 17 вкладок порно (це нормально, я все-таки ставлю закладку улюблених), щоб звільнити деяку пам'ять, а потім негайно перейти відновлення мого бізнесу.