Дешевые оптимизации

[nekonomicon]

Это не однократно обсуждалось, но как-то все забывается потому что не столь критично.
Ниже привожу список возможных оптимизаций, которые практически не требуют правки кода, а в основном предполагают включения дополнительных опций компилятора или подключения библиотек/заголовков.
Никаких замеров производительности разумеется не привожу.

• Можно включить флаги /Gr или /Gv для MSVC, чтобы зафорсить загрузку аргументов функций в регистры. В теории это может дать лишние 5% к общей производительности на x86 windows, но может потребовать добавления макроса GAME_EXPORT в объявления некоторых функций. В любом случае, gcc и clang выполняют загрузку в регистры по умолчанию.
• CSMoE утверждает, что есть бутылочное горлышко в выполнении алгоритмов AngleQuaternion и QuaternionSlerp, и предлагает использовать вручную векторизованные версии векторных и матричных функций.
• Можно взять вручную векторизованную матлибу из rehlds и заголовки из проекта SIMD everywhere. Это может сильно поднять общую производительность на большом числе платформ.
• Можно подключить библиотеку MATH-NEON чтобы повысить производительность на arm.
• Есть предложение перенести исходники libmpg123 в 3rdparty и синхронизировать их с апстримом. В новых версиях libmpg123 декодер использует SIMD на множестве платформ, правда не факт, что мы тут где-то упираемся в производительность.
• Можно ускорить время вычисления CRC32 и декомпрессии PK3/PNG подключив libdeflate.
• В старом движке мы уже использовали stb_sprintf, не факт, что он нам будет полезен в новом, но в теории может быть можно, например немного ускорить логирование.

[a1batross]

Я не вижу смысла пытаться обгонять libc и libm там, где они скорее всего уже оптимизированы под систему. На одной платформе NEON версия libm будет быстрее, на другой будет медленнее. На первой sprintf упрощен, на другой нет. Это бесконечная гонка, в которой мы не выиграем в долгосрочной перспективе.

Матлиба из rehlds конечно хороша, можно было бы на её базе создать что-то своё. Но SSE код по моему опыту плохо накладывается на NEON. С другой стороны, эту проблему возможно решили в simde, тогда этой библиотеки не было. Функции работы с кватернионами переписал не только CSMoE, но @Crow-bar в своём PSP порте.

libmpg123 вообще хорошо было бы обновить до апстрима, а потом уже решать что с ним делать. Дядя Миша туда вносил какие-то изменения, но вроде бы это только упрощенное API. Можно ли его реализовать только с публичным API пока тоже никто не проверял.

GAME_EXPORT на данный момент ничего не делает под MSVC. И тем более, уже давно никто не проводил ревизию, проставлен ли он везде. Мне кстати интересно, достаточно ли умён MSVC чтобы такую оптимизацию применять к static или inline функциям. Я последнее время стал везде static проставлять, но скорее из привычки, нежели, чем какой-то реальной цели.

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

Это release сборка. Прямо сейчас почти весь фрейм занимает отрисовка. Хотя если походить по функциям отрисовки, то из математических функций и правда сходу можно отметить кватернионы, матрицы и внезапно BoxOnPlaneSide в R_RecursiveWorldNode.

[nekonomicon]

Мне кстати интересно, достаточно ли умён MSVC чтобы такую оптимизацию применять к static или inline функциям

ЕМНИП, static функции MSVC не инлайнит по умолчанию, даже если функция используется только 1 раз.
А так эти флаги меняют только соглашение о вызовах, и по идее должны применяться вообще ко всем функциям если только там явно в коде не указано другое соглашение о вызовах вроде _cdecl или _stdcall.

[a1batross]

static функции MSVC не инлайнит по умолчанию, даже если функция используется только 1 раз

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