Come beneficiare della cache della CPU in un motore di gioco del sistema di componenti di entità?

Leggo spesso nelle documentazioni del motore di gioco ECS che è una buona architettura per usare saggiamente la cache della CPU.

Ma non riesco a capire come possiamo beneficiare della cache della CPU.

Se i componenti vengono salvati in un array (o in un pool), nella memoria contigua, è un buon modo di usare la cache della CPU MA solo se leggiamo i componenti in sequenza.

Quando usiamo i sistemi, hanno bisogno di un elenco di entità che sono un elenco di entità che hanno componenti con tipi specifici.

Ma questi elenchi forniscono i componenti in modo casuale, non in sequenza.

Quindi, come progettare un ECS per massimizzare l'hit della cache?

MODIFICARE :

Ad esempio, un sistema fisico necessita di un elenco di entità per entità con i componenti RigidBody e Transform (esiste un pool per RigidBody e un pool per i componenti Transform).

Quindi il suo ciclo per l'aggiornamento delle entità sarà così:

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
}

Il problema è che il componente RigidBody dell'entità1 può trovarsi nell'indice 2 del suo pool e il componente Tranform dell'entità1 nell'indice 0 del suo pool (perché alcune entità possono avere alcuni componenti e non l'altro e a causa dell'aggiunta / eliminazione di entità / componenti casualmente).

Quindi, anche se i componenti sono contigui in memoria, vengono letti in modo casuale e quindi avrà più cache miss, no?

A meno che non ci sia un modo per precaricare i componenti successivi nel ciclo?

L'articolo di Mick West spiega integralmente il processo di linearizzazione dei dati dei componenti delle entità. Ha funzionato per la serie Tony Hawk, anni fa, su hardware molto meno impressionante di quello che abbiamo oggi, per migliorare notevolmente le prestazioni. In pratica ha usato array globali pre-allocati per ciascun tipo distinto di dati di entità (posizione, punteggio e quant'altro) e fa riferimento a ciascun array in una fase distinta della sua update()funzione a livello di sistema. Si può presumere che i dati per ciascuna entità siano nello stesso indice di array in ciascuno di questi array globali, quindi, per esempio, se il player viene creato per primo, potrebbe avere i suoi dati [0]in ogni array.

Ancora più specifici per l'ottimizzazione della cache, le slide di Christer Ericsson per C e C ++.

Per dare un po 'più di dettaglio, dovresti provare a usare blocchi di memoria contigui (più facilmente allocati come array) per ogni tipo di dati (ad es. Posizione, xy e z), per garantire una buona località di riferimento, utilizzando ciascuno di questi blocchi di dati in distinti update()fasi per il bene della località temporale, ad esempio per garantire che la cache non venga scaricata tramite l'algoritmo LRU dell'hardware prima di riutilizzare tutti i dati che si intende riutilizzare, all'interno di una determinata update()chiamata. Come hai sottinteso, ciò che non vuoi fare è allocare le entità e i componenti come oggetti discreti tramite new, poiché i dati di tipi diversi su ciascuna istanza dell'entità verranno quindi interlacciati, riducendo la località di riferimento.

Se si hanno interdipendenze tra componenti (dati) tali da non poter assolutamente permettersi di separare alcuni dati dai dati associati (ad es. Transform + Physics, Transform + Renderer), è possibile scegliere di replicare Transform data sia negli array Physics che in Renderer , assicurando che tutti i dati pertinenti si adattano alla larghezza della linea della cache per ogni operazione critica per le prestazioni.

Ricorda anche che la cache L2 e L3 (se puoi assumerle per la tua piattaforma di destinazione) fanno molto per alleviare i problemi che possono subire la cache L1, come una larghezza della linea restrittiva. Quindi, anche in mancanza di L1, si tratta di reti di sicurezza che spesso impediranno callout alla memoria principale, che è ordini di grandezza più lenti rispetto ai callout a qualsiasi livello di cache.

Nota sulla scrittura dei dati La scrittura non richiama la memoria principale. Per impostazione predefinita, i sistemi odierni hanno abilitato la memorizzazione nella cache del write-back : la scrittura di un valore lo scrive solo nella cache (inizialmente), non nella memoria principale, quindi non sarete colli di bottiglia da questo. È solo quando i dati vengono richiesti dalla memoria principale (non accadrà mentre è nella cache) ed è obsoleto, quella memoria principale verrà aggiornata dalla cache.