Я завжди знаходив термін "мікрооптимізація" досить неоднозначним. Якщо деякі зміни на рівні інструкцій у макеті пам'яті та шаблонах доступу робить щось в 80 разів швидше від дисциплінованого професіонала, який вимірює їхні гарячі точки без зниження алгоритмічної складності, це "мікрооптимізація"? Для мене це "мега-оптимізація", щоб зробити щось у 80 разів швидше на справжньому випадку використання. Люди схильні говорити про такі речі, як такі оптимізації мають мікроскопічний вплив.
Я більше не працюю в gamedev, але працюю у VFX у таких областях, як трасування траєкторій, і я бачив багато реалізацій дерев BVH та KD, які обробляють ~ 0,5 мільйона променів в секунду на складній сцені (і це з багатопотокова оцінка). Грубо кажучи, я схильний бачити прямолінійну реалізацію БВХ у проміжному контексті зі швидкістю 1 мільйон променів / с навіть при багатопотоковій оцінці. За винятком того, що Embree має BVH, який може обробляти понад 100 мільйонів променів на одній сцені одним і тим же обладнанням.
Це повністю завдяки "мікрооптимізаціям", що Embree в 200 разів швидший (той самий алгоритм і структура даних), але, звичайно, причина це набагато швидше, тому що розробники в Intel за ним - це професіонали, які спираються на свої профілі та вимірювання. дійсно налаштував важливі області. Вони не змінювали код вольово-невольно з угідь та вносили зміни, які зробили поліпшення 0,000000001% за рахунок значного погіршення ремонту. Це були дуже точні оптимізації, застосовані в розумних руках - вони могли бути мікроскопічними з точки зору фокусу, але макроскопічними з точки зору ефекту.
Природно, що вимоги до частоти кадрів у режимі реального часу в іграх залежать від того, як ви працюєте з ігровим двигуном на високому або низькому рівні (навіть ігри, створені з UE 4, часто частково реалізуються в сценарії високого рівня, але, скажімо, не найважливіші частини фізичного двигуна) мікрооптимізація стає практичною вимогою в певних сферах.
Інша дуже основна область, яка нас щодня оточує, - це обробка зображень, як розмивання зображень з високою роздільною здатністю в режимі реального часу, і, можливо, виконання інших ефектів на них як частина переходу, який ми, напевно, всі десь бачили, можливо, навіть ефект ОС. Не обов’язково реалізовувати подібні операції із зображенням з нульового циклу через усі пікселі зображення і очікувати таких результатів у режимі реального часу при відповідності частоти кадрів. Якщо це процесор, ми зазвичай дивимося на SIMD та деякі мікронастроювання, або ми дивимося на шейдери графічного процесора, які, як правило, вимагають на мікрорівні настроювань для ефективного запису.
Якщо так, то чи поліпшується обладнання, чи слід очікувати, що мови вищого рівня перейдуть на ігрову індустрію?
Я скоріше сумніваюся, що лише технічний прогрес міг би це зробити, тому що в міру просування обладнання так само, як і інструкції, і технологія (наприклад, фізика на графічному процесорі), і методи, і очікування клієнтів щодо того, що вони хочуть бачити, і конкуренції в способи, з якими часто розробники знову переходять на низький рівень, як це стосується навіть випадків, коли веб-розробники зараз пишуть низькорівневі шейдери GLSL у WebGL (веб-розробка такого типу, можливо, навіть нижчого рівня, ніж це було десять-два тому, так як GLSL - це надзвичайно низький рівень C-подібної мови, і я ніколи не здогадувався десять-два тому, що деякі веб-розробники приймуть написання таких шейдерів низького рівня GPU).
Якщо буде важливим способом переміщення в критично важливих для ефективності областях на мови вищого рівня, потрібно буде отримати більше програмного забезпечення та компіляторів та інструментів, які ми маємо, як я бачу. Проблема для мене в будь-якому передбачуваному майбутньому не в тому, щоб апаратне забезпечення було недостатньо потужним. Це має більше спільного з тим, як ми не можемо знайти способів найбільш ефективно розмовляти з нею щоразу, коли вона змінюється і просувається, не повторюючи свій шлях до своєї мови знову. Насправді швидкий темп, з яким апаратні зміни змінюються, робить програмування на високому рівні досить невловимим для цих областей, як я це бачу, оскільки якщо гіпотетично наше обладнання перестало просуватися на наступний десятиліття,
Цікаво, що в ці дні, коли я працюю в справжніх критичних для продуктивності сферах, мені доводиться дещо думати більш низький рівень, ніж я почав (хоча я почав в епоху Borland Turbo C DOS). Бо тоді кеш процесора майже не існував. В основному це була лише DRAM та регістри, що означало, що я можу більше зосередитися на алгоритмічній складності та дуже просто записувати пов'язані структури, як дерева, не заважаючи на ефективність. У наші дні низькорівневі деталі кешу процесора домінують над моїм мисленням майже настільки ж, як і сам алгоритм. І так само у нас є багатоядерні машини, які повинні змусити нас думати про багатопотоковість та атоміку, мютекси та безпеку ниток та одночасні структури даних тощо, що, я б сказав, є багато в чому більш низьким рівнем уваги (як в, не так по-людськи інтуїтивно зрозумілий), ніж коли я починав.
Як не дивно, це здається мені зараз дуже правдивим. Я думаю, що сьогодні я більше впливаю на основні та низькі рівні складності та деталі обладнання, ніж 30 років тому, намагаючись зняти окуляри з ностальгією. Звичайно, ми, можливо, тут трохи поговорили про збори, і нам довелося розібратися з деякими гострими деталями, такими як XMS / EMS. Але здебільшого я б сказав, що було менше складності та обізнаності із обладнанням та компілятором, яких я потребував тоді, ніж сьогодні, коли я працюю в критичних для продуктивності сферах. І це майже здається справжнім для всієї галузі, якщо ми відкладемо, як писатиif/else висловлювання, дещо легше зрозумілі для людини, і врахуйте, наскільки люди взагалі в цей час більше замислюються про деталі апаратного забезпечення нижчого рівня (від декількох ядер від графічних процесорів до SIMD до кешу процесора та внутрішні деталі того, як їх компілятори / інтерпретатори / бібліотеки працюють тощо).
Високий рівень! = Менш ефективний
Повертаємось до цього питання:
Якщо так, то чи поліпшується обладнання, чи слід очікувати, що мови вищого рівня перейдуть на ігрову індустрію?
Для мене мова не йде про обладнання. Йдеться про оптимізатори та інструменти. Коли я починав, люди практично писали всі консольні ігри в зборах, і була справжня перевага в продуктивності, особливо, враховуючи відсутність якісних компіляторів, що генерують 6502.
Оскільки оптимізатори компіляторів C стали розумнішими у своїх оптимізаціях, тоді вони почали досягати точки, коли коди вищого рівня, написані на C, конкурували, а іноді навіть перевершували код, написаний найкращими спеціалістами з монтажу в багатьох областях (хоча і не завжди), і це зробило це так, що тоді не було розумним прийняттям C принаймні основної частини кодування для гри. І подібний зсув поступово стався в якийсь момент із C ++. Прийняття C ++ проходило повільніше, оскільки я думаю, що підвищення продуктивності переходу від збирання до C, можливо, може досягти одностайної згоди від gamedevs, що пишуть нетривіальні ігри повністю в ASM, на відміну від переходу від C до C ++.
Але ці зрушення не відбулися завдяки тому, що апаратне забезпечення стало настільки потужнішим, що оптимізатори для цих мов значною мірою роблять нижчий рівень (хоча і не завжди цілком буває, але є деякі незрозумілі випадки) застарілими.
Якщо ви можете уявити собі гіпотетичний сценарій, коли ми могли б написати код у коді найвищого рівня, який можна уявити, не турбуючись про багатопотоковість чи графічні процесори чи пропуски кешу чи щось подібне (можливо, навіть не конкретні структури даних), а оптимізатор був як штучний інтелект розумний і міг би розібратися у найефективніших компоновках пам’яті, переставляючи та ущільнюючи наші дані, з’ясуйте, що він може використовувати тут і там якийсь графічний процесор, паралелізувати якийсь код тут і там, використовувати якийсь SIMD, можливо, сам профіль і продовжувати оптимізувати його ІК як нас, люди реагуючи на гарячі точки профілера, і це робилося таким чином, що перемагає найкращих експертів у світі, тоді було б непродумано навіть тих, хто працює у найважливіших сферах продуктивності, щоб прийняти це ... і це прогрес походить від смішно розумних оптимізаторів, а не швидшого обладнання.