Programming
Client optimization
ООP
Comments 18
+2

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

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

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


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

0
Близарды скорее исключение на рынке — они как рокстар могу себе позволить делать игру лет 10, поменять ее концепцию и полностью переделать на несколько лет. Однако весь остальной рынок старается удовлетворить потребности инвесторов, поэтому кранчи, игроки — альфатестеры, сырое в прод и прочее.
+5
Кто же виноват? Паттерны произвольного доступа к памяти и постоянные промахи кеша
Вообще нет. Мисы кеша — копейки на фоне тормозов того же GUI. Любители (и не очень) Unity поймут.
0
Data-oriented design — это другой способ проектирования программ, предназначенный для решения всех этих проблем. Основным элементом процедурного программирования являются вызовы процедур, а ООП в основном имеет дело с объектами. Заметьте, что в обоих случаях в центр ставится код: в одном случае это обычные процедуры (или функции), в другом — сгруппированный код, связанный с неким внутренним состоянием.


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

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


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

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


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

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


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

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

Кстати сравнивать надо было с Object Oriented Design, а не с Object Oriented Programming.
+3
Основной профит от Data-Oriented Design — это векторизация, через sse/avx и да, распараллелить после этого тоже можно. И есть еще одно общепринятое название этого всего — AoS(Array of Structures — более привычное для ООП) and SoA(Structure of Arrays — то, что в статье). Уменьшение кэшмиссов — это даже скорее как приятный бонус.
-1
Если мы применим data-oriented design, то параллелизация становится намного проще: у нас есть входящие данные, небольшая обрабатывающая их функция и выходные данные. Нечто подобное можно легко разделить на несколько потоков с минимальной синхронизацией между ними.

ну да, теперь понятно, почему игры обычно такие забагованные и тормознутые. У нас же есть только потоки со своими входными и выходными данными. Пофиг, что у данных обычно одно общее хранилище на все потоки, пофиг, что все равно есть как минимум один общий объект-синглтон (если не набор объектов таких объектов), который управляет всей игрой и пофиг на синхронизацию
0

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

0

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

+1

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


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

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

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

Нет. Даже простейшие алгоритмы на картинках для изменения цветности выигрывали от ручного написания кода с интринсиками. Иногда — на порядок-два.


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

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

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

0

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

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

Но я практически не занимался алгоритмической оптимизацией! Всего-то переписал код на SSE/AVX, кое-где максимум разложив вещи типа деления на (нагугленный) оптимальный для x86 SIMD код. Типа такого или такого (только не пинайте строго, я в этом всём не оч шарю).

Only those users with full accounts are able to leave comments., please.