Як отримати вигоду з кеш-процесора в системному двигуні компонентної системи сутності?

Я часто читаю в документаціях на ігровий механізм ECS, що є гарною архітектурою для розумного використання кеш-пам'яті.

Але я не можу зрозуміти, як ми можемо отримати вигоду з кеш-процесора.

Якщо компоненти зберігаються в масиві (або пулі), у постійній пам'яті, це хороший спосіб використовувати кеш-процесор, АЛЕ, якщо ми читаємо компоненти послідовно.

Коли ми використовуємо системи, їм потрібен перелік об'єктів, який є переліком об'єктів, які мають компоненти з певними типами.

Але ці списки надають компоненти випадковим чином, а не послідовно.

Тож як створити ECS для максимального збільшення кешу?

Редагувати:

Наприклад, фізичній системі потрібен список сутностей для сутності, що має компоненти RigidBody та Transform (Є пул для RigidBody та пул для компонентів Transform).

Тож його цикл для оновлення об'єктів буде таким:

for (Entity eid in entitiesList) {
    // Get rigid body component
    RigidBody *rigidBody = entityManager.getComponentFromEntity<RigidBody>(eid);

    // Get transform component
    Transform *transform = entityManager.getComponentFromEntity<Transform>(eid);

    // Do something with rigid body and transform component
}

Проблема полягає в тому, що компонент RigidBody entiteta1 може знаходитись в індексі 2 свого пулу, а компонент Tranform сутності1 в індексі 0 свого пулу (тому що деякі об'єкти можуть мати деякі компоненти, а не інші, і через додавання / видалення сутності / компоненти довільно).

Тож навіть якщо компоненти несумісні в пам'яті, вони зчитуються випадковим чином, і це матиме більше пропусків кешу, ні?

Якщо тільки не існує способу попереднього вибору наступних компонентів у циклі?

Стаття Міка Веста пояснює процес лінеаризації даних компонентів сутності. Багато років тому він працював над серією "Тоні Хоук" на набагато менш вражаючому обладнання, ніж у нас сьогодні, щоб значно покращити продуктивність. В основному він використовував глобальні, попередньо виділені масиви для кожного окремого типу даних сутності (позиція, оцінка та багато чого) та посилається на кожен масив у окрему фазу його загальносистемної update()функції. Можна припустити, що дані для кожної сутності будуть мати однаковий індекс масиву в кожному з цих глобальних масивів, так, наприклад, якщо плеєр створений першим, він може мати свої дані [0]у кожному масиві.

Ще більш специфічні для оптимізації кешу, Christer Ericsson слайди для C та C ++.

Щоб детальніше ознайомитись, вам слід спробувати використовувати суміжні блоки пам'яті (найлегше виділяються як масиви) для кожного типу даних (наприклад, позиція, xy та z), щоб забезпечити хорошу локальність посилань, використовуючи кожен такий блок даних чітко. update()фази заради тимчасової локалізації, тобто для того, щоб кеш не був очищений за допомогою апаратного алгоритму LRU до того, як ви використали будь-які дані, які ви збираєтесь повторно використовувати, у межах даного update()дзвінка. Як ви вже мали на увазі, те, що ви не хочете робити, - це виділяти ваші сутності та компоненти як дискретні об'єкти через new, оскільки дані різних типів про кожен екземпляр сутності потім будуть переплетені, зменшуючи локальність посилань.

Якщо у вас взаємозалежності між компонентами (даними) такі, що ви абсолютно не можете дозволити собі, щоб окремі дані були відокремлені від пов’язаних даних (наприклад, Transform + Physics, Transform + Renderer), ви можете вибрати тиражувати дані Transform як у масивах Physics, так і в Renderer. , переконуючись, що всі відповідні дані відповідають ширині лінії кешу для кожної критичної для виконання операції.

Пам'ятайте також, що кеш L2 і L3 (якщо ви можете припустити їх для своєї цільової платформи) роблять багато для полегшення проблем, які можуть зазнати кеш-пам’яті L1, наприклад, обмежувальної ширини рядка. Тож навіть у випадку пропуску L1, це безпечні мережі, які найчастіше запобігають виклику головної пам’яті, яка на порядок повільніше, ніж опис будь-якого рівня кешу.

Примітка щодо запису даних Писання не викликає основну пам'ять. За замовчуванням у сьогоднішніх системах увімкнено кешування зворотного запису: запис значення записує його лише в кеш (спочатку), а не в основну пам'ять, тому ви не будете обмежені цим. Лише тоді, коли запитуються дані з основної пам'яті (не відбудеться, поки вони знаходяться в кеші), і основна пам'ять буде оновлена ​​з кеша.