AoS vs SoA — 데이터 레이아웃이 CPU 성능을 만든다

// [1] AoS (Array of Structures)
struct Player {
    float x, y, z;   // 12 bytes
    float hp;         //  4 bytes
    float speed;      //  4 bytes
    int   pid;        //  4 bytes
};                    // 합계 24 bytes
Player players[10000];

// [2] SoA (Structure of Arrays)
struct PlayerSystem {
    float x[10000];
    float y[10000];
    float z[10000];
    float hp[10000];
    float speed[10000];
    int   pid[10000];
};

메모리 레이아웃:
[ x y z hp speed pid ][ x y z hp speed pid ][ x y z hp speed pid ] ...

캐시에 올라오는 것  →  [ x | y | z | hp | speed | pid ]  (24 bytes)
실제 필요한 것      →  [ x | y | z ]                      (12 bytes)

for (int i = 0; i < 10000; i++) {
    players[i].x += vx;
    players[i].y += vy;
    players[i].z += vz;
    // hp, speed, pid는 쓰지 않지만 같은 cache line에 올라옴
}

메모리 레이아웃:
x[] → [ x x x x x x x x x x x x x x x x ... ]
y[] → [ y y y y y y y y y y y y y y y y ... ]
z[] → [ z z z z z z z z z z z z z z z z ... ]

for (int i = 0; i < 10000; i++) {
    x[i] += vx;  // Sequential access → cache line 100% 활용
    y[i] += vy;
    z[i] += vz;
}

파이프라인 정상:   IF → ID → EX → MEM → WB → IF → ID → EX ...
Cache Miss 발생:   IF → ID → EX → [STALL ×100 사이클] → MEM → WB

// 스칼라 연산: 4번의 명령어
x[0] += vx; x[1] += vx; x[2] += vx; x[3] += vx;

// SIMD 연산: 1번의 명령어
[x[0] x[1] x[2] x[3]] += [vx vx vx vx]

// AoS: 배열에서 하나 제거
players.erase(players.begin() + i);  // 끝

// SoA: 모든 배열에서 같은 인덱스를 동기화해야 함
x.erase(x.begin() + i);
y.erase(y.begin() + i);
z.erase(z.begin() + i);
hp.erase(hp.begin() + i);
speed.erase(speed.begin() + i);
pid.erase(pid.begin() + i);
// → 필드 추가할 때마다 여기도 추가해야 함 → 실수하면 데이터 불일치

void remove(int i, int last) {
    x[i] = x[last];
    y[i] = y[last];
    z[i] = z[last];
    // ... 모든 배열 동일하게
    size--;
}
// 순서 보장이 필요하면 사용 불가

// AoS: 의도가 명확하다
if (players[i].hp <= 0) {
    players[i].state = DEAD;
    players[i].deathTime = now;
}

// SoA: i라는 인덱스가 여러 배열을 묶는 암묵적 계약이 된다
if (hp[i] <= 0) {
    state[i] = DEAD;
    deathTime[i] = now;
}
// → 이 계약이 깨지는 순간 찾기 어려운 버그가 생긴다

// AoS: 엔티티 하나에 락 하나
mutex player_lock[N];
player_lock[i].lock();
players[i].hp -= damage;
player_lock[i].unlock();

// SoA: 배열별로 락 범위가 달라지거나, 교착 상태(Deadlock) 가능성 증가
// → ECS 엔진(Unity DOTS Job System 등)이 프레임워크 레벨에서 해결하는 이유

Player 구조체: 24 bytes
24 bytes × 1,000개 = 24 KB  → L2 캐시(보통 256KB~1MB)에 완전히 들어감

N < ~500     → 차이 미미
N ~ 1,000    → 차이 체감 시작
N > 10,000   → SoA 효과 극대화

// 이런 루프라면 AoS가 더 낫다
for (int i = 0; i < N; i++) {
    players[i].x     += vx;
    players[i].y     += vy;
    players[i].z     += vz;
    players[i].hp    -= damage[i];
    players[i].speed *= friction;
}
// → AoS는 players[i] 하나만 캐시에 올리면 끝
// → SoA는 x[], y[], z[], hp[], speed[] 배열을 각각 따로 접근

// 전통 Unity (AoS)
GameObject → [Transform][Renderer][Collider][Script ...]

// ECS / DOTS (SoA)
Position[]  → [p p p p p p p p ...]
Velocity[]  → [v v v v v v v v ...]
Health[]    → [h h h h h h h h ...]

-- Row DB: 모든 컬럼(name, age, salary)을 캐시에 올려야 age를 읽을 수 있음
-- Column DB: age[] 배열만 Sequential Read → 캐시 효율 극대화
SELECT AVG(age) FROM users;

// 외부 인터페이스는 OOP 그대로 유지
class Player {
public:
    float getX() const { return system.x[index]; }
    void  setX(float v) { system.x[index] = v; }
private:
    PlayerSystem& system;  // 내부는 SoA 참조
    int index;
};

// 한 구조체에 다 넣으면 hot loop에서 cold 데이터까지 캐시에 올라옴
struct Player {
    float x, y, z;         // 매 프레임 (hot)
    float hp, mana;        // 전투 시 (warm)
    char  name[32];        // 거의 안 씀 (cold)
    int   achievement[50]; // 매우 가끔 (cold)
};

// Hot/Cold 분리
struct PlayerTransform { float x, y, z; };            // 매 프레임
struct PlayerCombat    { float hp, mana; };            // 전투 시
struct PlayerProfile   { char name[32]; int ach[50]; }; // 가끔