[TIL 프로젝트] 7일차 - CPU 캐시 히트와 캐시 미스

1. 캐시란?

CPU는 매우 빠르지만, RAM은 상대적으로 느림
그래서 CPU와 RAM 사이에 작은 고속 메모리인 “캐시(Cache)"가 존재함
- L1,L2,L3 캐시 : 점점 느리지만 크기는 커짐
- CPU가 데이터를 요청할 때:
  - 캐시에 있으면 -> Cache Hit (빠름)
  - 없으면 -> Cache Miss (느림, RAM까지 내려감)

2. Cache Hit vs Cache Miss

- Cache Hit : CPU가 찾는 데이터가 캐시에 이미 존재 : 빠름 (수 ns)
- Cache Miss : CPU가 찾는 데이터가 캐시에 없음 -> RAM에서 가져옴 (수십~수백 ns)

3. Spatial & Temporal Locality (지역성)

CPU 캐시는 지역성(Locality)을 기반으로 작동함
- Temporal Locality (시간적 지역성):
  - 최근 사용한 데이터는 또 사용할 가능성 높음
- Spatial Locality (공간적 지역성):
  - 인접한 데이터도 같이 사용할 가능성 높음
그래서 CPU는 데이터를 불러올 때, 근처 메모리 덩어리(=Cache Line) 전체를 미리 불러옴 (보통 한 cache line은 64바이트)

4. 캐시 미스가 발생하는 경우

- 불연속 메모리 접근
- 무작위 포인터 접근
- 큰 구조체를 지나치게 복사
- 다중 쓰레드에서 동일한 캐시라인 접근 (false sharing)

5. Unity/ECS 관점에서

ECS + Chunk 구조는 이 문제를 해결하기 위해 디자인됨
- Chunk는 데이터가 연속된 메모리에 저장됨
- 따라서 for-loop로 순회할 때 Cache Hit가 극대화
- 반대로, GameOjbect + MonoBehaviour는 각 데이터가 산발적으로 메모리에 있음 -> Cache Miss 자주 발생

6. 예시 코드 비교 (Cache Friendly vs Cache Unfriendly)

[Cache Unfriendly]

class Unit {
    public float posX, posY, velX, velY;
}

Unit[] units = new Unit[100000];

for (int i = 0; i < units.Length; i++) {
    units[i].posX += units[i].velX;
}

-> 각 Unit이 메모리 상 흩어져 있어 캐시 미스 발생

[Cache Friendly - ECS 스타일]

struct Position { public float x, y; }
struct Velocity { public float x, y; }

NativeArray<Position> positions;
NativeArray<Velocity> velocities;

for (int i = 0; i < positions.Length; i++) {
    positions[i].x += velocities[i].x;
}

-> 연속된 메모리, 캐시 히트율 높음

- CPU 캐시는 RAM보다 빠른 중간 저장소
- Cache Hit = 빠르게 데이터 처리 가능
- Cache Miss = RAM 접근 -> 느려짐
- 연속된 메모리 접근 & 지역성 고려가 핵심
- Unity ECS는 캐시 최적화를 위해 설계됨

멀티스레딩 성능 최적화 : False Sharing과 Data Alignment 이해하기

1. False Sharing (가짜 공유)

멀티스레딩 환경에서 두 개 이상의 스레드가 서로 다른 데이터를 접근한다고 해도, 그 데이터들이 같은 캐시 라인(Cache Line)에 존재하면 문제가 생길 수 있음
왜 문제가 되는가?
- CPU는 데이터를 캐시 라인 단위(64바이트 등)로 불러옴
- 스레드 A가 변수 a를 수정 -> 같은 캐시 라인에 있는 스레드 B의 변수 b도 불필요하게 무효화됨
- 그 결과, CPU는 캐시를 계속 동기화(sync)해야 하며, 성능 저하로 이어짐

예시

public class SharedData
{
    public int a; // Thread 1 사용
    public int b; // Thread 2 사용
}

- a와 b는 서로 다른 쓰레드가 사용하지만, 같은 64바이트 정도)에 들어가 있을 확률이 높음
- Thread 1이 a를 수정 -> CPU는 a가 있는 캐시 라인을 다른 코어와 동기화해야 함
- 그 결과 Thread 2도 b에 접근할 때 불필요하게 캐시 미스나 성능 저하 발생

해결 방법:
- 캐시 라인 패딩(Padding)을 넣어서 분리시킴
데이터를 서로 다른 캐시라인에 배치하는 것

[StructLayout(LayoutKind.Explicit, Size = 128)] // 64바이트 이상으로 분리
public struct PaddedInt
{
    [FieldOffset(64)] public int value;
}

- StructLayout을 이용해 데이터를 인위적으로 띄워서 false sharing 방지
- Unity에서도 비슷한 방식의 캐시 라인 패딩 기법이 사용됨

또는 Unity의 Burst/Jobs에서는:

[StructLayout(LayoutKind.Sequential)]
public struct Counter1 : IJob
{
    [NativeDisableParallelForRestriction]
    public NativeArray<int> array;

    public void Execute()
    {
        array[0]++;
    }
}

-> NativeArray<int>에선 false sharing이 날 수 있으니 index마다 64바이트 정도 띄워서 접근하거나 NativeArray<CustomPaddedStruct>를 사용

2. Data Alignment (데이터 정렬)

정의:
CPU는 데이터가 특정 바이트 단위로 정렬되어 있어야 효율적으로 접근 가능
잘 정렬된 데이터는 한 번에 읽을 수 있음, 그렇지 않으면 여러 번 읽거나 느려짐

struct A {
    byte a;
    int b;
}

- 위 구조체에서 byte a는 1바이트지만, int b는 4바이트 정렬이 필요함 -> 사이에 3바이트 패딩이 자동 삽입 됨

Unity에서 주의할 점:

- IComponentData 구조체는 가능한 한 4,8,16바이트 단위로 정렬하는 게 좋음
- float3는 16바이트 정렬됨 -> 뒤에 int가 오면 불필요한 정렬비용 발생 가능

정렬 최적화

// 나쁜 예
struct Bad {
    public int a;
    public byte b;
    public float3 c;
}

// 좋은 예
struct Good {
    public float3 c;
    public int a;
    public byte b;
}