Почему игры не используют шаблоны выражений для математики?

Я могу придумать много причин:

• это вредит времени компиляции. Более длительное время компиляции означает, что тестирование любых изменений, внесенных вами в код, занимает больше времени. Это вредит продуктивности.
• это сложно. Скорее всего, многие разработчики в команде не знакомы с шаблонами выражений, и им будет трудно их читать и отлаживать.
• Игры часто должны работать на нескольких платформах, с различными компиляторами, которые могут иметь широкий спектр недостатков, которые могут, например, сделать проблематичным расширенный обман шаблонов.
• Это вообще не нужно. Вы можете писать эффективный код без шаблонов выражений. Он просто становится более подробным, и вам приходится больше поддерживать компилятор.
• Разработчики игр крайне скептически относятся ко всему, что еще не использовалось в играх 10 лет назад. Не так давно несколько крупных разработчиков остановились на C: не потому, что C++ был недостаточно хорош, а потому, что он был «новым». Разработчики игр чертовски консервативны.

И, конечно же, очевидный вопрос: где они будут использовать шаблоны выражений? Достаточно ли сложной математики, чтобы она действительно стоила того? Игры, как правило, полагаются на довольно небольшое количество операций линейной алгебры, которые в любом случае обычно тщательно настраиваются вручную.

Я хочу добавить еще одну причину, не указанную в приведенных выше ответах. Извиняюсь, если что и пропустил.

Добавление шаблонов к математическим классам, таким как класс vec3, может изменить значение операторов и привести к функциям, недопустимым для некоторых типов шаблонов.

Возьмем, к примеру,

vec3<int> myVec( 3, 5, 4 );
myVec.Normalize();

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

Кроме того, стоит упомянуть еще одну вещь: многие математические конструкции оптимизированы для определенных типов, потому что оптимизация очень важна в играх. GPU — это вычислительные машины с плавающей запятой. Двойники занимают в два раза больше места, чем числа с плавающей запятой, и их вычисление немного медленнее, хотя для начинающего разработчика игр это может показаться очевидным вариантом использования.

Я надеюсь, что этот пример имеет смысл. Шаблоны — отличный инструмент, но математические конструкции в играх — неподходящее место для их использования.

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

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

Я думаю, что причина того, что шаблоны выражений не используются широко, заключается в том, что они усложняют программное обеспечение (по всем причинам, описанным jalf) в код, не критичный к производительности, который на самом деле не гарантирует этого, и не охватывают все оптимизации, необходимые для действительно важный для производительности код, который отображается в верхней части профилей.