Сколько сборок действительно используется в современном игровом коде? [закрыто]

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

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

Ответ немного зависит от того, что вы подразумеваете под «игрой», и «используется». Я предполагаю, что «использованный» означает «написанный в ходе конкретного игрового проекта».

По моему опыту и неподтвержденным данным от людей, с которыми я разговаривал:

• в браузерных играх? Никто.
• в типичных компьютерных играх? Никто. (Но вы можете увидеть некоторые в низкоуровневых библиотеках.)
• в iOS и Android играх? Никто.
• "ААА" компьютерные и консольные игры? Может быть, немного, возможно, 0,05% кодовой базы. (С немного больше в библиотеках.)

Знание языка ассемблера не ожидается для работы в игровой индустрии, но в зависимости от типа игр, которые вы делаете, это может оказаться полезным.

Раньше был аргумент, что компилятор лучше оптимизирует код на C, чем человек с рукописной сборкой. Обычно это правда, иногда это ложь. Но в наши дни сочетание постоянно растущей сложности ЦП и необходимости масштабирования (то есть для разделения процессоров) означает, что усилия по оптимизации обычно проводятся в другом месте.

В последние годы я видел только ассемблер в коде игры с __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 - это та область, где людям все еще приходится использовать сборку, чтобы получить максимальную отдачу от процессора, например, с конвейерной инструкцией вручную, как описано здесь .

Дело в том, что мы живем в многоплатформенном мире, и части нашего игрового кода должны быть адаптированы к локальной платформе - ну, не обязательно, но есть преимущества, если мы используем преимущества местного аппаратного обеспечения!

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