Data-Oriented Design (или почему, используя ООП, вы, возможно, стреляете себе в ногу)

[questor]

Понимаю, что перевод, но несколько примеров известных ААА-игр с подобным подходом органично бы вписалось в статью.

[Defersa]

Мне кажется в ААА играх кодовая база напоминает такую кашу из технологий, подходов и методик, что разбор их может привести к неправильных выводам. Данная статья все же больше для любителей, индюшников и тех, кто всегда хотел, но не мог.

[marsermd]

Overwatch, например, весь на ECS.

Ребята из Larian (которые Divinity делают) тоже на него перелезают.

[Defersa]

Близарды скорее исключение на рынке — они как рокстар могу себе позволить делать игру лет 10, поменять ее концепцию и полностью переделать на несколько лет. Однако весь остальной рынок старается удовлетворить потребности инвесторов, поэтому кранчи, игроки — альфатестеры, сырое в прод и прочее.

[Suvitruf]

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

Вообще нет. Мисы кеша — копейки на фоне тормозов того же GUI. Любители (и не очень) Unity поймут.

[nicholas_k]

Data-oriented design — это другой способ проектирования программ, предназначенный для решения всех этих проблем. Основным элементом процедурного программирования являются вызовы процедур, а ООП в основном имеет дело с объектами. Заметьте, что в обоих случаях в центр ставится код: в одном случае это обычные процедуры (или функции), в другом — сгруппированный код, связанный с неким внутренним состоянием.

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

Основная причина мощи концепции data-oriented design заключается в том, что она очень хорошо работает с большими группами объектов. ООП, по определению, работает с одним объектом.

Давайте откровенно — любой высокоуровневый подход будет где то там преобразован в последовательную работу с каждым отдельным объектом, пусть даже параллельно в нескольких потоках.
Соответственно простейший цикл по массиву будет лежать внутри вашей дата-ориентированной абстракции.

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

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

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

В данном случае data-oriented design — это разделение массивов данных на независимые друг от друга кучи, которые можно обрабатывать в нескольких потоках? Ну создайте объект IndependentBatch c кучей данных и обрабатывайте в разных потоках.

На мой взгляд, вместо того, чтобы объяснить суть data oriented design, чтобы читатель мог сам сделать выводы, автор поделился печальной историей про то, что с помощью ООП можно выстрелить себе в ногу.

Кстати сравнивать надо было с Object Oriented Design, а не с Object Oriented Programming.

[biteyobik]

Основной профит от Data-Oriented Design — это векторизация, через sse/avx и да, распараллелить после этого тоже можно. И есть еще одно общепринятое название этого всего — AoS(Array of Structures — более привычное для ООП) and SoA(Structure of Arrays — то, что в статье). Уменьшение кэшмиссов — это даже скорее как приятный бонус.

[gandjustas]

А можно примеры кода? Архитектура "на словах" всегда хороша, а на деле бывает по-разному.

[Tzimie]

Классические базы данных и SQL хороший пример такого дизайна

[maydjin]

Имхо, тут слегка перепутанно тёплое с мягким, либо переводчик налажал.

Есть ООП — это парадигма программирования, она про интерфейсы в основном, про реализацию архитектуры и удобное/интуитивное API. Есть ООД(OOD) — объектно ориентированный дизайн, и вот это — да про архитектуру(всякие модели акторов и т.п.). Так вот, ничто не мешает упаковывать DOD в ООП API, это может упрощать как поддержку, так и тестирование. Но как совершенно верно заметил автор — эффективный код в наши дни пляшет именно от формата представления состояния ПО.

[IGR2014]

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

Мне кажется, современные компиляторы достаточно умны чтоб оптимизировать код лучше человека (по крайней мере, в C/C++)

[IGR2014]

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

[gandjustas]

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

[IGR2014]

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