Коли найкращий час для розгляду продуктивності?

45

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

Тепер питання полягає в тому, чи потрібно думати про продуктивність у кожному рядку коду при розробці гри?

Так я відчуваю, що ми не вистачаємо моделей дизайну та чистого коду. Мені було цікаво, чи існує якийсь кращий підхід в галузі розвитку ігор?

— Емад
джерело

8

Може бути корисним обговорення цього попереднього питання щодо передчасної оптимізації .

— DMGregory

10

На початку. По мірі затягування проекту продуктивність буде тільки погіршуватися.

— Томаш Зато

10

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

— Джон Ватте

1

Усі. The. Час. Заощадьте собі трохи часу і нудних завдань, просто роблячи весь час, і ви опинитеся, що ви робите дуже круті та вигадливі завдання, намагаючись додатково оптимізувати код, ніж це вже є (якщо потрібно). Ось тут і починається веселощі.

— Йейтс

6

Ефективність "врахування" повинна відбуватися в той день, коли ви вирішите зробити продукт, який має користувачів . Користувачі мають мінімальні очікування ефективності, і якщо вони не будуть виконані, то ваш продукт вийде з ладу. Продуктивність має витрати, а продукти мають бюджет . Якщо мінімально прийнятна ефективність коштує більше вашого бюджету, ваш проект буде провальним . Розумно думати про це в перший день, а не в день сто.

— Ерік Ліпперт

90

Техніка для виконання

Дотримуйтесь рекомендацій постачальника.
Використовуйте правильні структури даних.
Реалізуйте правильні схеми використання.
Не робіть нічого дурного.

Оптимізація

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

Передчасна оптимізація

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

Ці три речі не однакові .

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

Якщо не зробити інженером продуктивності, це може призвести до таких же поганих результатів, як і необхідність цілого перероблення та перезапису до моменту, коли ви помітите що-небудь не так.

Наприклад: всі постачальники GPU радять, що робити зворотний зв'язок з GPU кожен кадр відбувається повільно. Розробка коду, щоб не робити зворотного зв'язку, не є передчасною оптимізацією .

— Максим Мінімус
джерело

28

Дякую тобі дуже за те, що згадуєш про це. Розробники завжди оприлюднюють зло передчасної оптимізації порадами, які вкрай сформульовані, щоб зрозуміти, але часто менш досвідчені розробники не розуміють нюанс. Розробити це правильно з самого початку. Це НЕ передчасна оптимізація. Я говорю, що ви повинні бути обізнаними у виконанні кожного написаного рядка. Як розробник, ви повинні знати про кращі практики, щоб не робити дурних речей. Однак, не слід паралізувати себе оптимізацією. Перш за все, запускайте щось, а потім зосередьтесь на тому, що це сповільнює.

— AC

2

@AC Я також хочу зазначити, що хороший дизайн може зайняти час для початку, але, врешті-решт, це, мабуть, означатиме, що ви також зробите швидше, що означає більше часу на оптимізацію, якщо потрібно. Мій досвід (із єдиним, напівзавершеним проектом соло-хобі, щоб підкріпити його) полягає в тому, що як тільки ваш проект стає досить великим, велика витрата часу становить 1) "Як я збираюся вплести це у все, що вже є", і 2) "Блін, код, який я написав тиждень тому, який ідеально підходить, тоді зовсім не працює з тим, що я хочу робити далі". Хороший дизайн (який я ще не робив) допомагає обом цим.

— Артур

5

Невиконання належних показників продуктивності також може вважатися песимізацією дизайну. Отже, якщо передчасна оптимізація є коренем усього зла , що це означає передчасна песимізація ? ; P

— ніндзя

1

@Arthur "більше часу [залишилось] на оптимізацію"? Це хороший спосіб переконатися і в цьому, оптимізуючи власні обмежені ресурси розвитку (та робочий процес), щоб отримати оптимальний вплив від ваших зусиль з оптимізації! Крім того, я знаю, що ми не на належному рівні Stack Overflow, але мене дивує те, що ми говоримо про оптимізацію, і Принцип Парето досі не згадується у відповіді ... Я навіть не бачу слова "відсоток"!

— AC

1

Розробляючи ваші структури даних для хорошої продуктивності, ви повинні знати, що комп'ютери можуть робити ефективно, а що вони не можуть. наприклад, сучасні процесори, які перебирають масиви на масиви, можуть застосувати величезну кількість грубої сили, особливо якщо ви налаштували речі, щоб компілятори могли автоматично векторизуватися за допомогою SSE / AVX. (Наприклад , використання масиви координат х і у масивів координат, а НЕ масиви ху структур пари або А трійок Див. Stackoverflow.com/tags/sse/info для деяких посилань, особливо SIMD на Insomniac Games (GDC 2015)

— Пітер Кордес

22

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

За допомогою повільної машини ви дізнаєтесь, коли вам потрібно підвищити продуктивність.

чи потрібно думати про ефективність у кожному рядку коду при розробці гри?

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

Розмова про передчасну оптимізацію насправді не є поганою справою оптимізації. Йдеться про те, що люди не в змозі оптимізувати правильну річ. Ваш час - одна із змінних, яку потрібно оптимізувати, що досягається, не витрачаючи часу на "оптимізацію" функції, яка викликається один раз кожні 30 мілісекунд і займає 100 мікросекунд на виконання.

Іншими словами: робити щось "швидше" - безглуздо. Ваша мета - "досить швидко". Зробити щось "швидше", яке вже є "досить швидким", це марно витрачати час, а зробити щось "швидше", яке все ще не "досить швидко", просто означає, що воно все ще занадто повільне. "швидше" не має значення, актуально лише "досить швидке".

— Петро
джерело

1

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

— hoffmale

Значна розробка робиться з налагодженнями налагодження, які значно повільніші, ніж версії Release. Це означає, що для розвитку потрібна набагато швидша машина, ніж потрібно для запуску гри з прийнятною швидкістю.

— Джек Едлі

Шаблони доступу до кеш-пам'яті також важливі, і вони можуть спричинити різницю в 10 або 100. наприклад, розглянути множину наївних матриць (для великої матриці). Перекидання на один стовпчик матриці рядків-головне жахливо. наприклад, цей Q & A має коефіцієнт 13 перф. різниці для тієї ж алгоритмічної складності для додавання транспонінгу перед циклами, лише для фіксації жахливого шаблону доступу. (Ще один фактор, що становить 10 і більше, можна отримати з оптимізованої бібліотеки BLAS, яка ще більше піклується про кеш і SIMD ...)

— Пітер Кордес

9

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

Це також залежить від того, яку гру ви розробляєте. Коли ви розробляєте дуже графічно напружений 3D-шутер, вам потрібно бути набагато більш обізнаним, ніж коли ви програмуєте RPG-ігри в ретро-стилі.

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

— Філіп
джерело

3

Вам потрібно докласти достатньо зусиль, щоб хоча б піти "це потенційно може бути вузьким місцем, і якщо так, то наскільки зміна буде це виправити?".

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

Подумайте про це дещо як про ремонт квартири. Деякі рішення можуть мати тривалі наслідки ("Ой, холодильник більше не вміщується у своєму кубіку". "Ну, де я хочу поставити свою ванну, немає води"), але ви не будете думати про те, як кожен штрих вашої фарби кисті може вплинути, наприклад, на стійкість конструкції будівлі.

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

Я пов'язую швидкість оновлення гри з графічним кадром?
Я змушую синхронну економію?
Чи я змушую (не) -детермінізм?

— TLW
джерело

1

Для гри ваша основна мета - досягти цільової рамки на цільовій мінімальній технічній техніці (і, можливо, максимальний час завантаження тощо).

Щоб це зробити, ні, вам не доведеться хвилюватися після кожного рядка.

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

Далі, ви повинні турбуватися, коли щось є паралельним чи паралельним. Ігри масово паралельні, якщо не з іншої причини, то тому, що графіка є.
Тому паралель означає не лише "потоки", але також, наприклад, графічний API, доступ до диска чи мережу. Кожного разу, коли ви втрачаєте можливість мати щось, що можна легко і споконвічно виконати паралельно, запустити паралельно, наприклад, через погану синхронізацію (або через те, що зовсім не використовується асинхронний API), ви втрачаєте більше, ніж можете коли-небудь оптимізувати іншими способами.
Ви також повинні турбуватися, коли щосьдобре відомо, що це вузьке місце або джерело кіосків, або перешкода для масштабування. Наприклад, наприклад, перемикання станів візуалізації, виклик дзвінків, зчитування з GPU або відкриття файлів.

Нарешті, коли ви закінчите, і тестування показує, що ви не досягаєте цільової частоти кадрів, вам потрібно оптимізувати. Знайдіть найбільше вузьке місце, яке займає 90% часу, і оптимізуйте це. Якщо цього недостатньо, знайдіть найбільші секунди.
Якщо ви все-таки досягаєте мети, вітаю. Рухайтеся далі і забудьте про це.

— Деймон
джерело

0

Отримати реальні. Відповідь просто абсолютно НІ. Немає дискусії.

Основна проблема полягає в тому, як ви запитуєте:

чи потрібно думати про ефективність у кожному рядку коду при розробці гри?

Ви маєте на увазі також у таких речах, як екрани конфігурації? Як одноразовий аналізатор для невеликого конфігураційного файлу максимум 1 кб? Серйозно?

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

— TomTom
джерело