ECS vs OOP

Те же яйца, только сбоку.

Твой знакомый думает что ооп - только наследование? Перестань его знать.

Я пытался объяснить ему это )) Вот что он написал:

Не уверен, что ты до конца осознал что такое ECS и в чем скрыты прелести по сравнению с ооп. Это не только игры, ты сильно заблуждаешься. Совсем другой подход, мыслить надо иначе Для серверов в плане эксплуатации всех доступных ресурсов ECS рулит, даже спорить не надо) Я говорю о классическом ECS, а не о далеком подобии Entity - Id, одно число. Контейнер компонент. Никакой логики, лишь число Component - данные без логики System - обработчики данных (компонент) Все однотипные компоненты лежат в массивах и обновляются подряд, кэш должен быть доволен. Также нет никаких виртуальных таблиц и в 90% случаев вычисления могут быть распараллелены без блокировок Тут разработка уже идет на уровне данных. И это дает бешенные преимущества

...

Я думаю, ты прекрасно знаешь как процессор работает с кэшем. Надо прочитать переменную - грузим весь кусок возле нее. И сделано это, потому что озу слоу. Чем больше подгрузок кэша - тем больше процессор мотает абсолютно бесполезные такты (для нашего приложения). Vtable и подгрузка кэша из-за неё - лишь начало. Сейчас поясню

...

Класс внутри себя хранит разношерстные данные. И их иногда довольно много. Допустим, ты захотел у всех объектов изменить угол наклона. Итерируя по объектам ты вынужден глотать в кэш мусор. Тебе нужны только Rotation, но тебе приходится также кэш забивать лишней информацией. Следовательно в скором времени придется подгружать кэш и мотать кучу бесполезных тактов процессора. Даже если повезёт и нужная инфа попадет на более медленный уровень кэша, то ты все равно ощутишь потерю скорости. Также без царя в голове компилятору будет трудно оптимизировать все под simd и т.п. Ну и из-за интерфейсов (всяких там указателей) кэш-промахов станет ещё больше Я не прям уж противник ооп, просто прекрасно осознаю недостатки Логика размазана по классам, сложно дебажить. А в ECS логика сосредоточена и ее просто поддерживать и отлаживать Также у компонентов реюзабельность выше. Куда выше. Это как конструктор

Типичный фанбой. Без примеров кода и замеров производительности не интересно.

Entity - Модель.
Component - иногда View, иногда просто так обозвали стандартные данные/методы модели, на самом деле не суть важно.
System - Контроллер.

на выходе не просто ООП, а аж стандартный MVC.

Profit

Не нужно. Только хардкор и микросервисы.

По-моему, он путает теплое с мягким. ECS это паттерн, а ООП это парадигма.

Не нужно. Только хардкор и микросервисы.

А в микросервисы нельзя ООП? Это разный уровень абстракции, у вас уже application design, а тут речь о component design.

Да он упорот, судя по его стилю сообщений. Лучше таких избегать. Если хочешь по-дискутировать с ним, обрати внимание на блог Егора Бугаенко — он популярно объясняет что в ООП не так, и как с этим жить.

А в микросервисы нельзя ООП?

Именно. Там внутри хоть голую функциональщину можно. Просто любой большой кодинг - зло, а зло лучше, когда оно мелкое и разрозненное, чем когда оно одно и большое.

Интересный блог спасибо. Ну я решил особо с ним не спорить, попытался немного, понял что это бесполезно.

Все правильно написал например. Однобоко, но правильно.

Именно. Там внутри хоть голую функциональщину можно. Просто любой большой кодинг - зло, а зло лучше, когда оно мелкое и разрозненное, чем когда оно одно и большое.

А причем тут ООП вообще? У ООП проектов есть какой-то минимальный размер?

А есть где почитать кроме вики? а то там как-то сильно расплывчато.

У ООП проектов есть какой-то минимальный размер?

Есть. Размер целесообразности применения ООП.

ECS: https://en.wikipedia.org/wiki/Entity_component_system

Кто что думает о подобной архитектуре?

если у тебя приложения сводятся к схеме: «приложение над Базой Данных», то сдавайся и не спорь.

Во всех остальных случаях следует подумать :)

Все однотипные компоненты лежат в массивах и обновляются подряд, кэш должен быть доволен.

Если компоненты однотипные, то они и в ООП будут лежать в одном массиве. Если нет — то лепить их в одно место не имеет смысла, если выборка по ним будет разная. Плюс можно получить дополнительный головняк типа false sharing'а, который сьест весь профит от его хваленого кеша.

Также нет никаких виртуальных таблиц

А их и так нету. JIT все равно заинлайнит горячие мономорфные вызовы, а в полифорфных может расставить PICи (polymorphic inline cache).

и в 90% случаев вычисления могут быть распараллелены без блокировок

Чем тут ООП виноват — неизвестно. Плюс, практика показывает что fine-grained параллелизм не так часто нужен, достаточно занимать ядра высокоуровневыми задачами (или вообще процессами).

Vtable и подгрузка кэша из-за неё

Снова vtable.

Ну и из-за интерфейсов (всяких там указателей) кэш-промахов станет ещё больше

И снова.

Допустим, ты захотел у всех объектов изменить угол наклона.

Не захотел. Зачем? Опять-таки, если обьекты семантически связаны, то они скорее всего будут лежать рядом все равно. Другое дело, что в той же Джаве список обьектов нельзя преаллоцировать чтобы они не размазались по куче, а лежали ровненько вместе. Но, кажется, в 1.9 обещали этим заняться.

По-моему, ты немного не понял в чем суть: не объекты лежат рядом, а компоненты. Толку от близости объектов, если в них по десятку полей нет никакого с точки зрения cache-oblivious model.

Да, походу не понял. Тепер понял, пасибо. Но проблема остается — модель работает хорошо только если обращения идут вширь, а не вглубь. Изменить всем одинаковое поле (компонент) это быстро, зато склонировать целиком сложный обьект (сущность) - это множество кеш-промахов вместо одного. А если автор по совету своего друга еще и «распаралелит благодаря отсутствию блокировок», то на false sharing'е просядет до скорости однопоточного решения.

Я согласен, что для игр и всяких симуляторов это хорошо подходит. Но говорить, что оно лучше в общем случае, да еще и именно благодаря перформансу — сильно лукавить, или даже врать.

Меру надо знать просто :) Твоему другу тоже :)

блог Егора Бугаенко

Уноси обратно этот ужас.

Есть видео, где его... высмеивают джависты. Очень хорошо характеризует публику, которая даже не пытается понять, что он хочет донести. Аргументы уровня «и чо, предлагаешь кирпич класть на левый бок, а не на правый? ахахаха, кто так делает?!».

P.S. Это я, как не джавист, имел удовольствие наблюдать за бурлением говен в джаватусовке. Мне не очень интересно прав он или нет, а если прав, то на сколько.

Есть видео, где его... высмеивают джависты. Очень хорошо характеризует публику, которая даже не пытается понять, что он хочет донести. Аргументы уровня «и чо, предлагаешь кирпич класть на левый бок, а не на правый? ахахаха, кто так делает?!».

Я уже давно разочаровался в так называемой java-тусовке (JUG.ru и их присные). Типичная java-конференция в России — сборище капитанов и пиарщиков, разбавленная приглашенными зарубежными «звездами» и один-два стоящих докладчика. А их аудитория радостно хавает «проверенные» рецепты и яростно хейтит тех, кто пытается заставить эту аудиторию думать головой.

Да он упорот, судя по его стилю сообщений

Судя по его стилю сообщений, это какая-то адаптированная копипаста, особенно первая часть:

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

Очень сильное чувство дежа вю вызывает. =)