Цена борьбы с аллокациями в C++
Х@habr_comмедиа / агрегатор
1 месРазбор архитектурных ограничений при разработке игрового движка: отказ от стандартных возможностей C++ ради минимизации аллокаций памяти.
Этот кейс показывает, что слепая борьба с аллокациями может стоить дороже, чем сама оптимизация.
- Жесткие архитектурные ограничения могут парализовать разработку, не принося реальной выгоды в производительности.
- Отказ от стандартных библиотек C++ требует огромных затрат времени на поддержку собственной инфраструктуры.
- Баланс между чистотой кода и техническими требованиями критически важен для выживаемости проекта.
Эти пчелы делают неправильный C++
Команда, поддерживавшая движок для прототипа Arkane, довела число выделений памяти за кадр до двадцати. Не двадцати тысяч, а двух десятков на весь фрейм, и очень этим гордилась. Заплатить пришлось стеком под 20 Мб на главный поток, компиляцией движка с нуля почти на четыре часа и запретом на значительную часть рантайма C++14. Под нож пошли исключения, RTTI, глобальные new и delete, iostream целиком, тяжёлые шаблоны, стандартные контейнеры сложнее вектора. Всё это выпилили не ради скорости, потому что быстрее код от этого по большей части не становился.
Получилась не новая версия языка, а архитектурная дисциплина с аллергией на аллокации, где время кадра покупалось временем жизни программиста. И самое странное в этой истории то, ради чего вся жёсткость затевалась.
Кратко (AI)
Автор описывает опыт команды, работавшей над движком для прототипа Arkane, где ради снижения количества аллокаций памяти до 20 на кадр пришлось отказаться от большинства стандартных возможностей C++14. В результате были запрещены исключения, RTTI, стандартные контейнеры и другие инструменты, что значительно усложнило разработку, не дав при этом существенного прироста производительности.
Обсуждение
0Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖