Скільки збірки реально використовується в сучасному ігровому коді? [зачинено]

В середньому, як часто в сучасних ігрових кодах використовується збірка?

Зокрема, на платформах, у яких вже є хороші компілятори C ++, як-от x86, PPC або ARM - тому що я припускаю, що ігри на вбудованих системах широко використовують збирання.

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

З мого досвіду та анекдотичних даних людей, з якими я спілкувався:

• в браузерних іграх? Немає.
• у типових іграх на ПК? Немає. (Але їх можна побачити в бібліотеках низького рівня.)
• в iOS та Android іграх? Немає.
• Ігри на ПК та ігри консолей "AAA"? Можливо, трохи, можливо 0,05% бази коду. (З трохи більше в бібліотеках.)

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

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

В останні роки я єдиний раз, коли я бачив збірку в ігровому коді, - це __asm int 3заяви про примусові точки прориву, і моє єдине особисте використання збірки - це дивитись на розбирання функції для діагностики незвичайних помилок аварій.

Основна частина високопродуктивного коду в сучасних консольних іграх написана за допомогою свого роду середини між збіркою та C ++: властивостями компілятора . Ці конструкції виглядають і розбираються як функції C ++, але насправді переводяться в єдині машинні інструкції . Так, наприклад, виглядає моє "затискання кожного значення вектора V бути> = a і <= b"

// for each v.x, ensure v.x >= a.x && v.x <= b.x
inline __m128 ClampSIMD( const __m128 &v, const __m128 & a, const __m128 & b )
{
    return _mm_max_ps( a, _mm_min_ps( v, b ) );
}

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

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

Хоча ми можемо не кодувати в монтажі, ми все ще багато налагоджуємо в збірці. Оптимізація компіляторів агресивно реорганізує код таким чином, щоб налагоджувачі не могли йти в ногу, тому часто при налагодженні "режиму випуску" найкраще робити - це відкрити розбиральник і простежити за цим кодом. Ця розмова GDC про "криміналістичну налагодження" збоїв ілюструє багато прийомів та способів налагодження на цьому рівні.

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

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

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

Справа в тому, що ми живемо в мультиплатформенному світі, і частини нашого ігрового коду повинні бути пристосовані до локальної платформи - ну не обов’язково, але є переваги, якщо ми скористаємось місцевими апаратними речами!

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