[TIL 프로젝트] 6일차 - 메모리 모델 & 캐시 일관성 (Memory Model & Cache Coherency)

1. 메모리 모델이란?

멀티쓰레드 환경에서 메모리에 접근할 때의 규칙과 보장 범위를 정의한 것
- 우리가 x = 10 같은 코드를 쓴다고 해도, 실제 실행 순서나 읽는 값은 CPU, 컴파일러, 메모리 최적화에 의해 달라질 수 있음
-> 언제 어떤 값이 보장되는지? -> 메모리 모델이 이걸 정의해서 줌

2. 왜 중요한가?

멀티코어 CPU에서는 각 코어마다 캐시가 있음
-> 변수 값을 바로 RAM에서 읽지 않고, 자기 캐시에서 읽고 쓸 수 있음
-> 그러면 문제가 생김:
A 코어가 x=10 했는데, B 코어는 x가 0인줄 알고 잘못된 계산을 할 수 있음

3. Cache Coherency (캐시 일관성)

멀티코어 CPU는 코어들 간 캐시의 값을 동기화해야 함
-> 이걸 캐시 일관성(coherency)라고 함

대표적인 프로토콜 : MESI (Modified, Exclusive, Shared, Invalid)
-> 각 캐시 라인이 어떤 상태인지 추적해서
-> 값이 변경되면 다른 코어들에게 알림 (Invalidation)

4. CPU/컴파일러의 명령어 재배치 문제

- CPU나 컴파일러는 성능을 위해 명령어 순서를 바꾸기도 함
- a = 1; b = 2; -> 실제로는 b = 2; a = 1; 이 먼저 실행될 수도 있음
- 단일 쓰레드에선 문제 없지만, 멀티쓰레드에선 Race Condition 발생 가능

5. 해결 방법: 메모리 배리어 & volatile

5-1. Memory Barrier (메모리 장벽)

- CPU가 명령어 순서 재배치를 하지 않도록 막는 명령
- 종류
  - Load Barrier: 읽기 순서 고정
  - Store Barrier: 쓰기 순서 고정
  - Full Barrier: 읽기/쓰기 모두 순서 고정

5-2. volatile 키워드 (C#)

- 변수에 volatile을 붙이면:
  - 항상 메인 메모리에서 읽고 씀
  - CPU 캐시/컴파일러 최적화 방지
  - 단점 : 완전한 동기화는 안 됨 (lock은 아님)

6. .NET 메모리 모델 요약

- C#의 lock, Interlocked, volatile은 모두 메모리 모델 보장을 기반으로 동작
- lock은 내부적으로 Memory Barrier가 포함됨 -> 안정적
- Interlocked도 원자적(더이상 쪼갤수 없는) 연산 + 메모리 베리어를 자동 삽입

7. Unity에서는?

- Unity는 기본적으로 메인 스레드에서 모든 API 동작이 이루어짐
- 하지만 Job System, Burst, NativeArray 같은 구조를 사용할 땐:
  - 메모리 접근 순서와 캐시 동기화에 신경 써야 함
  - Unity의 Jobs.WithReadOnly(), NativeContatiner 특성은 메모리 일관성을 위한 힌트 역할을 함

Burst Compiler란?
요약
C# 코드를 네이티브 머신코드로 컴파일해주는 Unity 전용 고속 컴파일러
특징
- JIT이 아니라 AOT (Ahead of Time) 방식
- 일반 C# 코드보다 수십 배 빠를 수 있음
- SIMD(벡터 명령어)와 CPU 캐시 최적화를 적극 사용
- Unity Editor에서는 Burst가 적용된 함수는 즉시 확인 가능

[BurstCompile]
public struct MyJob : IJob
{
    public void Execute()
    {
        // 고속 실행 코드
    }
}

장점
- CPU 명령 최적화
- 메모리 접근 최소화
- 쓰레드 안전 보장

Job System이란?

요약
Unity가 제공하는 멀티스레딩 작업 시스템
-> 메인 스레드를 막지 않고, 여러 작업을 동시에 실행 가능
기본 개념
- IJob : 단일 작업 (작업 단위)
- IJobParallelFor : 병렬 반복 (for 루프를 다중 코어에 분산)
- IJobChunk : ECS에서 쓰는 대용량 처리용 Job


장점
- 메인 스레드 해방
- Unity가 자동으로 작업을 쓰레드풀에 분배
- Burst + Job 조합으로 엄청난 성능 확보 가능

NativeArray란?

요약
Unity의 메모리 효율적인 배열 구조체
C#의 List<T>, Array보다 빠르고 버스트/잡 시스템에 최적화됨
특징
- GC가 발생하지 않음
- 연속된 메모리 -> CPU 캐시 친화적
- 반드시 Dispose()로 수동 메모리 해제 필요

Unity DOTS 생태계 요약

- ECS : 구조 자체를 데이터 지향적으로
- Job System : 다중 작업 스케줄링
- Burst Compiler : 실행 성능 극대화
- Native Collections : GC 없는 구조

Unity DOTS 전체 개념 요약

DOTS는 Data-Oriente Technology Stack의 약자
목표는 수십만 개 오브젝트도 부드럽게 처리하는 것

ECS 구조 핵심 정리

ECS는 OOP와 반대되는 개념
Entity에 데이터만 부착
시스템(System)이 모든 엔티티 순회 처리
순차적 데이터 중심 (캐시 친화적)

public struct Position : IComponentData {
    public float3 Value;
}

public struct Velocity : IComponentData {
    public float3 Value;
}

public partial class MoveSystem : SystemBase {
    protected override void OnUpdate() {
        float dt = Time.DeltaTime;
        Entities
            .ForEach((ref Position pos, in Velocity vel) =>
            {
                pos.Value += vel.Value * dt;
            }).ScheduleParallel(); // Job + Burst 적용 가능
    }
}

Chunk 구조

ECS는 내부적으로 동일한 Archetype (컴포넌트 조합)의 엔티티들을 Chunk라는 덩어리에 저장함
- 하나의 Chunk = 수십 개 ~ 수백 개 엔티티
- 메모리 연속 = CPU 캐시에 완전 최적화
- System은 Chunk 단위로 데이터를 순회함

Transform, Velocity, Health가 같이 있는 Entity는 같은 메모리 블록에 정렬됨

Job + Burst가 붙으면 생기는 일

- SystemBase의 .ScheduleParallel()은 내부적으로 Job을 생성함
- 이 Job은 Burst로 컴파일되면 네이티브 SIMD 명령어로 최적화돼서, 수백 개 엔티티를 한 번에 밀어냄 -> 엄청 빠름

최적화 요령

- IComponentData만 사용 : 참조형보다 value형 구조체 사용
- SharedComponentData는 신중하게 사용 : Chunk 분할을 유발하므로
- Archetype 조합 최소화 : Chunk 파편화를 방지
- System은 ScheduleParallel 우선 사용 : 병렬 처리 효율 증가
- NativeArray에 BurstCompile 적용 : 연산 성능 극대화
- math 라이브러리 적극 활용 : float3, dot, normalize 등 SIMD 최적화됨

DOTS 흐름 예시

1. 엔티티 생성
2. System이 모든 Entity 순회
3. 컴포넌트 조합에 따라 Chunk 단위로 순회
4. Job System이 쓰레드로 분산 처리
5. Burst가 내부 연산을 SIMD 기반으로 고속 실행

개발자가 신경 써야 할 부분

- 구조체로 설계 (참조 지양)
- 컴포넌트 조합을 일정하게 유지
- NativeArray, NativeList 사용 시 Dispose 처리
- 스레드 세이프한 Job 설계
- Debug 로그 사용 시 Burst 성능 저하 주의