Як правило, як часто і коли я повинен оптимізувати свій код?

У «звичайному» бізнес-програмуванні крок оптимізації часто залишається, поки дійсно не потрібен. Значить, не слід оптимізувати, поки це дійсно не потрібно.

Пам’ятайте, що сказав Дональд Кнут : «Ми повинні забути про малу ефективність, скажімо, про 97% часу: передчасна оптимізація - корінь усього зла»

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

Крім того, що повинен міряти оптимізацію? Кліщі? Частота кадрів? Загальний час?

Де я працював, ми завжди використовуємо кілька рівнів профілювання; якщо ви бачите проблему, просто перемістіть список трохи більше, поки не з’ясуєте, що відбувається:

• "Профілер людини", він просто грає в гру ; відчуваєш себе повільно чи «зачепиш» час від часу? Помічаєте ривкові анімації? (Зауважте, як розробник, ви будете більш чутливі до деяких видів продуктивності та не звертаєте уваги на інші. Плануйте додаткові тестування відповідно.)
• Увімкніть FPS-дисплей , який є середньою секундою FPS з розсувним вікном. Дуже невеликі накладні витрати для обчислення та відображення.
• Увімкніть смуги профілів , що представляють собою лише серію квадроциклів (кольори ROYGBIV), які представляють різні частини кадру (наприклад, vblank, попередній кадр, оновлення, зіткнення, візуалізація, пост кадр), використовуючи простий таймер "секундомір" навколо кожного розділу коду . Для того, щоб підкреслити те, що ми хочемо, ми встановили, що ширина екрана, що стоїть на барі, повинна бути репрезентативною для цільового кадру 60 Гц, тож насправді легко зрозуміти, чи є ви, наприклад, на 50% за бюджетом (лише півбар) або на 50% більше ( брусок загортається і стає півтора бруска). Також досить легко сказати, що зазвичай їсть більшу частину кадру: червоний = візуалізація, жовтий = оновлення тощо ...
• Створіть спеціальну інструментальну збірку, яка вставляє «секундомір» як код навколо кожної функції. (Зверніть увагу, що при цьому ви можете отримати величезну продуктивність, дкаш та ікаче, тому це, безумовно, нав'язливо. Але якщо вам не вистачає належного профіля вибірки або гідної підтримки процесора, це прийнятний варіант. Ви також можете бути розумними. про записи мінімум даних про функції входу / виходу та відновлення calltraces пізніше.) Коли ми побудували наш, ми імітували багато дргоЕ «s формат виведення.
• Найкраще запустити пробірник вибірки ; VTune та CodeAnalyst доступні для x86 та x64, у вас є різні імітаційні та емуляційні середовища, які можуть давати вам тут дані.

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

Зауважте, що ви також можете робити цікаві речі, такі як графік "профільних смуг" постійно, так що ви можете бачити схеми шипів ("ми втрачаємо кадр кожні 7 кадрів") тощо.

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

• Чи слід кешувати оперативну пам’ять або перезавантажувати з диска кадри анімації стану «атаки» для програвача? Як щодо кожного ворога? У нас немає оперативної пам’яті, щоб зробити їх усі, але завантаження диска дорого! Ви можете бачити, що хитне, якщо одразу вискочить 5 чи 6 різних ворогів! (Гаразд, як щодо приголомшливого нересту?)
• Ми робимо один тип операцій над усіма частинками або всі операції над однією частинкою? (Це компроміс ікаче / дкаш, і відповідь не завжди зрозуміла.) Як щодо того, щоб роз'єднати всі частинки і зберегти позиції разом (знаменита "структура масивів") проти збереження всіх даних про частинки в одному місці (" масив структур »).

Ви чуєте це, поки не стане неприємно на будь-яких курсах інформатики університетського рівня, але: це дійсно все про структури даних та алгоритми. Витративши деякий час на розробку алгоритму та потоку даних, ви отримаєте більше грошей на долар в цілому. (Переконайтесь, що ви прочитали чудові підводні камені об'єктно-орієнтованого програмування слайдів від колеги Sony Developer Services для ознайомлення тут.) Це не "відчуває" оптимізацію; в основному це витрачено час на дошку чи інструмент UML або на створення багатьох прототипів, а не на те, щоб поточний код запускався швидше. Але це взагалі набагато доцільніше.

І ще одна корисна евристика: якщо ви близькі до «ядра» вашого двигуна, можливо, варто докласти додаткових зусиль та експериментів для оптимізації (наприклад, векторизуйте ці матричні множення!). Чим далі від основної, тим менше ви повинні турбуватися про це, якщо один із ваших інструментів профілювання не скаже вам про інше.

1. Використовуйте правильні структури даних та алгоритми вперед.
2. Не проводите мікрооптимізацію, доки ви не профіліруєте та точно не дізнаєтесь, де стоять ваші гарячі місця.
3. Не хвилюйтесь, що ви розумні. Компілятор вже виконує всі маленькі хитрощі, про які ви думаєте ("О! Мені потрібно помножити на чотири! Я зміщу ліворуч на два!")
4. Зверніть увагу на пропуски кешу.

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

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

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

Більшість оптимізацій ігрового коду зводиться до скорочення циклів процесора, необхідних для кожного кадру. Один із способів зробити це - просто оптимізувати кожен розпорядок, коли ви його пишете, і переконатися, що він проходить якнайшвидше. Однак є поширена приказка, що 90% циклів процесора витрачається на 10% коду. Це означає, що перенаправлення всієї вашої роботи з оптимізації до цих вузьких процедур матиме 10-кратний ефект оптимізації всього. Тож як ви визначаєте ці процедури? Профілювання робить це легко.

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

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

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

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

Тож будуйте деякі статистичні показники роботи з першого дня.

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

Візьміть низько висячі фрукти, коли ви йдете разом, періодично займайтеся великими речами, і вам слід добре.

Якщо подивитися на цитату Кнута в її контексті, він продовжує пояснювати, що ми повинні оптимізувати, але з інструментами, як профілер.

Ви повинні постійно профайлювати та зберігати профіль пам'яті після того, як буде закладена сама основна архітектура.

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

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

Для мого проекту я зазвичай застосовую ДУЖЕ необхідні оптимізації у своєму базовому двигуні. Наприклад, я завжди люблю реалізовувати хорошу тверду реалізацію SIMD за допомогою SSE2 та 3DNow! Це гарантує, що моя математика з плаваючою комою стоїть на полі, де я хочу, щоб це було. Ще однією хорошою практикою є створення звички з оптимізації, як ви кодуєте, а не повертаєтесь назад. Більшість часу ці маленькі практики займають стільки ж часу, скільки і те, що ви кодували. Перш ніж кодувати функцію, переконайтесь, що ви дослідили найбільш ефективний спосіб це зробити.

Підсумок, на мою думку, його РОЗПОВІСТЬ зробити ваш код більш ефективним після того, як він уже смокче.

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

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

Ви хочете оптимізувати, коли ваш кадр скоротиться до моменту, коли гра почне страждати. Найімовірнішим винуватцем буде занадто багато (100%) використання вашого процесора.

Ви повинні оптимізувати свій код ... так часто, як вам потрібно.

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

Іноді це не код. Багато проблем, з якими я стикався в минулому, були орієнтовані на gpu (надано, це було на iPhone). Заповнення проблем, занадто багато розіграшів, недостатня геометрія, неефективні шейдери ...

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

Для мене найкраще слідувати добре підготовленій моделі даних. І оптимізація - перед головним кроком вперед. Я маю на увазі, перш ніж почати впроваджувати щось нове. Інша причина оптимізації - це коли я втрачаю контроль над ресурсами, додатку потрібно багато завантаження процесора / GPU або пам'яті, і я не знаю чому :) або це занадто багато.