Я ванговал смерть ООП различными доводами 20908037 .

Но ты просто переплюнул меня

Это просто чудесно. Самое забавное что этот-же тезис приводился и на лекциях по Haskell.

Сорцы Doom https://github.com/id-Software/DOOM

Сильно сомневаюсь что нам предоставят возможность смотреть сорцы современных
игр. Игры - это дорогое ноу-хау. И разрабы не хотят давать возможность конкурентам
копи-пастить их идеи и быстро внедрять.

Реверс-инжинеринг наверное возможен но по срокам скорее всего не уложится в бизнес-планы
современного геймдева. Иногда недостаточно даже сорцов. Нужна сопроводительная документация
и ответы на вопросы от создателей. Что уж тут говорить о реверсе.

Однако мы можем посмотреть в игровые движки. Они - достаточно современные и среди них есть
опенсорцные. И по ним тоже сделать какие-то суждения о DoD.

Вот тут я 5 штук нашел https://dzone.com/articles/top-5-free-and-open-source-game-engines-you-should

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

А это означает что на кривой оптимизации мы вышли на тот уровень
когда уже "можно остановится".

Забавно, что Вулкана-то между ними как раз нет.

Вулкан это не то. Это еще более LowLevel. Насколько я понимаю это аналог OpenGL/Direct3d.
И все игровые движки дёргают API этого вулкана а он уже дергает конкретные методы
драйвера видеокарты чтоб положить в конвейер 3D модельки.

petrav, да.

Я знаком с Data-Oriented-Design не со стороны геймдева а со стороны баз данных или BigData.
Например если у нас есть бизнес-аналитика по fundamentals крупных компаний то выгрузка
такой аналитики будет представлять собой очень широкие и разрежённые таблицы (порядка 500-1000 колонок)
и в традиционном способе хранения (если их хранить как data-rows) - выборка будет неэффективной.

Примерно так-же как со звездами. Дата-аналитик может запросить например 1-ю колонку и 500-ю и 900-ю.
Специально для таких хитрых запросов данные разворачивают в векторы примитивов (по сути поворачивают
таблицу набок) и сжимают чем-то вроде Gzip/Snappy и далее - уже считывают с диска сегменты 1/500/900 колонок.
И вместо например 1 Терабайта спокойно обрабатывают 1 Гигабайт что само по себе в тыщу раз быстрее. Для этого есть спецом форматы хранения Apache Parquet, Apache ORC. И форматы эти на 99% read-only. Тоесть их 1 раз создают чтобы
хранить всю жизнь без модификаций. Тоесть они - не для транзакций. А просто для сбора сведений
и всяких там машинных обучений и поиска закономернойстей между колонками.

В базах данных (Oracle 11g) тоже была введена попытка такого колончатого хранения инфы
но я к тому времени уже не админил ораклы и не успел с этой техникой плотно поработать.
Поэтому как оно там щас работает - я не знаю.

Так что не только геймдевом одним дышит DoD.

Вообще мне кажется DoD - это не про С++ а просто про оптимизацию доступа к данным.