Указатели на функции и полиморфизм в архитектуре ECS игрового движка
Итак, у меня вопрос об ECS и о том, как его структурировать так, чтобы он работал на C++. Скажем, я хочу иметь компоненты, которые представляют собой просто данные, и системы, которые представляют собой просто логику, и я хочу выполнять все функции обновления для всех систем, передавая им список кортежей компонентов для работы.
Будет ли передача системами своих делегатов метода Update в качестве указателей на функции в список обновлений более производительной, чем добавление самих систем в этот список и использование полиморфизма для вызова виртуального метода Update? Или ему безразлично, какой вариант я выберу?
Мне также было интересно, изменится ли что-нибудь, если, скажем, это реализовано на С#, например, с помощью делегатов/действий.
Помимо делегатов и полиморфизма — это совершенно разные вещи.
вы не будете измерять разницу в производительности, вам следует избегать виртуальной диспетчеризации для вещей, которые происходят примерно несколько сотен тысяч раз за кадр (например, тестирование столкновений, физика частиц, рисование декалей и т. д.), для запуска систем, которые вы можете Имейте только десятки или сотни , разница в производительности не поддается измерению, поэтому просто выбирайте то, что выглядит лучше, под «неизмеримым» я имею в виду, что оно не появится в любом инструменте производительности, который вы используете, это почти незначительно по сравнению с другими вещами.
@MakePeaceGreatAgain ну да, это, конечно, разные вещи, но в данном случае это два способа решения одной и той же проблемы. Вот почему я спросил.
Ответы 1
Причина, по которой полиморфизм будет медленным (клише), заключается в том, что поиск в v-таблице требует чтения указателя в несвязанной (с данными вашего объекта) ячейке памяти. Ошибка страницы, которую это может вызвать, может привести к переключению контекста на ОС, если ей необходимо найти новые страницы.
Это применимо, когда у вас очень тщательно оптимизирован код и вы уделяете большое внимание тому, какие данные и когда загружаются. Например, если вы занимаетесь высокочастотной торговлей или жестким управлением роботом в реальном времени, это применимо.
В игре, где у вас будет куча разных потоков для разных подсистем и куча кода движка, выполняющего разные задачи, накладные расходы на указатель функции, полиморфизм или даже делегат будут примерно одинаковыми. Все они требуют дополнительной косвенности. Единственная разница заключается в том, где будут храниться дополнительные указатели и будут ли они уже загружены или нет.
Единственное разумное предложение: зарегистрироваться для подтверждения. Но, по всей вероятности, лучшим подходом будет то, что проще и понятнее.
Производительность никоим образом не является заботой делегатов. Вам следует хотя бы попробовать что-нибудь и посмотреть, соответствует ли это вашим потребностям. Мы не можем оказать вам общую поддержку абстрактным идеям.