체셔's blog

주소는 가짜입니다.
매핑과 정책이 경계를 만듭니다.
가상화는 여기서 시작됩니다.

1. “Virtual Memory가 가상화 맞아요?”

이 시리즈를 시작하며 저는 “VM → 컨테이너 → Docker → Kubernetes” 흐름을 잡았습니다. 그런데 첫 번째 주인공으로 Virtual Memory를 꺼내면 보통 이런 질문이 돌아옵니다.

• “메모리 관리는 그냥 OS의 기본 기능 아닌가요?”
• “본격적인 가상화 이야기로 넘어가기 전에 왜 갑자기 메모리 쪽으로 새는 거죠?”

저 역시 처음에는 Virtual Memory를 ‘메모리 부족을 해결하는 기술’ 정도로만 생각했습니다. 하지만 관점을 [경계 + 매핑 + 정책]이라는 프레임으로 옮겨 보면, Virtual Memory는 오히려 가상화의 원형에 가깝다는 사실을 확인하게 됩니다.

결론은 단순합니다.

• 경계: 프로세스마다 나만의 독립된 주소 공간이 존재하는 것처럼 보이게 합니다.
• 매핑: 가상 주소를 실제 물리 메모리 위치에 연결하는 번역층을 둡니다.
• 정책: 서로의 영역을 침범하지 못하도록 보호 규칙을 강제합니다.

이 구조는 이후에 다룰 VM이나 Kubernetes에서도 이름만 바뀐 채 반복됩니다. 차이는 “무엇을 경계로 잡느냐”에 가깝습니다.

2. Virtual Memory가 만든 환상: “각 프로세스는 자기 주소 공간을 가진다”

Virtual Memory가 만든 첫 번째 효과는 단순하면서도 강합니다.

• 프로세스 A는 자신이 0번지부터 끝번지까지의 메모리를 ‘가진 것처럼’ 동작합니다.
• 프로세스 B도 똑같이 0번지를 사용하지만, A의 0번지와는 다른 세계입니다.
• 서로의 메모리가 어디에 있는지 알 수도, 볼 수도 없습니다.

여기서 핵심은 주소(Address)의 의미가 바뀐다는 점입니다. 우리는 흔히 주소를 ‘실제 메모리의 물리적 위치’라고 생각합니다. 하지만 Virtual Memory에서 주소는 그렇게 취급되지 않습니다.

• 주소는 ‘실제 위치’가 아니라, 자원을 식별하기 위한 이름에 가깝습니다.
• 실제 위치는 운영체제가 관리하고, 프로세스에는 이름(주소)만 제공합니다.

이 순간부터 주소 공간(Address Space)은 물리적 현실이 아니라 운영체제가 설계한 인터페이스가 됩니다. 저는 이 지점을 “첫 번째 가상화 레이어라고 봅니다.

3. 그럼 질문이 바뀝니다: “이름이 인터페이스라면, 실체는 누가 관리하죠?”

주소가 인터페이스라면 저는 이런 생각이 들었습니다.

• “그럼 실제 물리 메모리는 누가, 어떻게 나눠주지?”
• “프로세스들이 각자 주소를 쓰는데 충돌이 안 나는 이유가 뭐지?”

이 의문을 해소하면 Virtual Memory의 구조는 세 가지로 정리됩니다.

3-1) 경계: 주소 공간이라는 소유권 경계

운영체제는 각 프로세스가 볼 수 있는 주소의 범위를 논리적으로 확정합니다. 이 범위 밖은 프로세스 입장에서 원칙적으로 접근할 수 없는 영역입니다. 저는 이것을 격리(Isolation)의 시작이라고 봅니다.

3-2) 매핑: 가상 주소 → 물리 메모리

운영체제는 “이 주소는 실제로 여기다”를 연결하는 매핑 정보를 유지합니다. 프로세스는 주소만 사용하고, 실제 물리적 배치는 운영체제가 결정합니다. 저는 이것이 간접화(Indirection)의 핵심이라고 정리했습니다.

3-3) 정책: 보호 규칙(Permission)으로 침범을 막는다

매핑에는 위치 정보만 있는 게 아닙니다. 읽기만 가능, 쓰기 가능, 실행 가능 같은 규칙이 붙습니다. 이것은 구현 디테일을 넘어선 정책(Policy)입니다. 가상화는 환상을 보여주는 것으로 끝나지 않고, 그 환상을 유지하기 위해 정책을 강제해야 합니다.

4. Virtual Memory가 남긴 핵심: “환상은 운영 모델을 바꾼다”

여기까지 오면 질문은 이렇게 바뀝니다.

• “그래서, 주소를 가상으로 만들어서 얻는 진짜 이득이 뭔가요?”

Virtual Memory는 단순한 편의 기능을 넘어 운영 모델을 바꿨습니다.

• 프로세스는 물리 메모리의 구조를 몰라도 됩니다. (추상화)
• 운영체제는 상황에 맞춰 데이터를 배치하거나 이동시킬 수 있습니다. (유연성)
• 잘못된 접근이나 침범은 정책 위반으로 차단됩니다. (안정성)

즉, 현실 자원을 직접 다루던 방식이 [간접화 + 정책] 구조로 넘어간 것입니다. 저는 이 패턴이 뒤에서 다룰 VM / 컨테이너 / Kubernetes로 이어지는 “공통 골격”이라고 봤습니다.

5. 오늘날의 연결: 주소 공간에서 머신으로의 확장

여기까지 정리하고 나서, 저는 가상화를 보는 시각이 바뀌었습니다. 가상화는 단순한 속임수가 아니라, 경계와 매핑, 그리고 정책을 통해 자원을 운영하는 시스템 설계입니다.

그리고 그 첫 번째 성공 모델이 Virtual Memory였습니다. 그렇다면 다음 질문은 자연스럽습니다.

• “주소 공간(메모리)을 가상화할 수 있다면, CPU와 디스크를 포함한 머신 전체도 같은 방식으로 가상화할 수 있지 않을까?”

이 질문에 대한 대답이 다음 편의 주제인 Virtual Machine(VM)입니다.

멀티스레드는 더 많은 코어가 아니라
더 적은 공유 write로 빨라집니다.

멀티스레드에서 제일 흔한 착각이 있습니다.

atomic이 느린 이유 = 락(lock) 때문

 

아니요. 많은 경우 atomic이 느린 이유는 락이 아니라,
캐시 라인 소유권(ownership) 경쟁 때문에 생기는 coherency 트래픽입니다.

3편에서 본 규칙을 그대로 가져오면 됩니다.

• read는 공유(S)로 버틸 수 있지만
• write는 독점(M/E)을 요구하고
• 누가 write를 시작하면 다른 코어의 라인은 invalidate 된다

atomic은 여기서 한 단계 더 빡셉니다.
atomic은 보통 RMW(Read-Modify-Write) 이기 때문입니다.

---

1) atomic이 비싼 진짜 이유: RMW는 라인 독점을 강제한다

atomic_fetch_add 같은 연산을 생각해봅시다.

• 값을 읽고
• 수정하고
• 다시 쓴다

이 3단계를 중간에 끼어들지 못하게 보장해야 합니다.
그래서 하드웨어는 대체로 다음을 요구합니다.

해당 캐시 라인을 내가 독점(M/E)해야만 RMW를 수행할 수 있다.

 

문제는 여러 코어가 같은 atomic을 동시에 건드릴 때 터집니다.

• Core0가 라인 독점 → Core1은 invalidate
• Core1이 라인 독점 → Core0는 invalidate
• 결과: 라인이 ping-pong (False Sharing과 구조가 동일)

여기서 중요한 결론:

atomic 경쟁(contended atomic)은 연산 비용이 아니라 라인 이동 비용으로 느려진다.

 

그래서 스레드를 늘리면 오히려 느려지는 현상이 나옵니다.
CPU가 일을 더 하는 게 아니라, 서로 밀어내느라 시간을 씁니다.

---

2) Uncontended atomic vs Contended atomic (진단 기준)

atomic이 항상 나쁜 건 아닙니다. 구분이 필요합니다.

Uncontended atomic (경쟁 없음)

• 한 코어만 해당 atomic을 자주 업데이트
• 또는 업데이트 빈도가 낮아서 충돌이 거의 없음

이 경우는 대체로 괜찮습니다.

Contended atomic (경쟁 있음)

• 여러 스레드가 같은 atomic(같은 캐시 라인)을 고빈도로 RMW
• 대표: 전역 카운터, 전역 큐 인덱스, 글로벌 통계, 글로벌 work counter

이 경우는 거의 확실히 병목입니다.
락이 없어도 느립니다. (락이 아니라 coherency 경쟁이니까)

---

3) 처방의 방향은 단 하나: 공유 write-hot을 없애라

4편의 실전 처방은 여기로 수렴합니다.

1. 공유 write-hot을 스레드 로컬로 분해
2. 필요한 순간에만 합친다(reduction)
3. 합치는 지점도 가능하면 저빈도 / 배치(batch)로 만든다

즉, atomic을 잘 쓰는 법이 아니라

atomic을 ‘뜨거운 루프에서’ 치워버리는 법

이 핵심입니다.

---

4) 처방 1: per-thread counter + reduction (가장 강력하고 가장 흔함)

나쁜 예: 모든 스레드가 전역 atomic++

std::atomic<uint64_t> gCount = 0;
void Worker()
{
	for (...)
    {
    	gCount.fetch_add(1, std::memory_order_relaxed);
    }
}

이 코드는 연산이 아니라 라인 소유권 ping-pong으로 느려집니다.

좋은 예: 스레드 로컬 누적 + 마지막 합산(reduction)

std::atomic<uint64_t> gCount = 0;
void Worker()
{
	uint64_t local = 0;
    for (...)
    {
    	local++;
    }
    gCount.fetch_add(local, std::memory_order_relaxed); // 빈도 1회
}

핵심은 fetch_add 횟수를 줄이는 게 아닙니다.
라인 소유권 경쟁을 루프 밖으로 빼는 것입니다.

전역 atomic은 루프마다가 아니라 배치로 접근하라.

---

5) 처방 2: per-thread data layout (스레드별 write-hot을 구조적으로 분리)

reduction이 항상 가능한 건 아닙니다.
큐 인덱스, 작업 분배, 스레드 상태처럼 실시간으로 공유해야 하는 값이 존재합니다.

이때는 최소한 이렇게 해야 합니다.

서로 다른 스레드가 쓰는 데이터가 같은 캐시 라인에 들어가지 않게 한다.

 

즉, 2편에서 다룬 alignas(64)의 진짜 목적이 여기서 다시 등장합니다.

패턴: thread slot을 캐시 라인 단위로 고정

 

struct alignas(64) ThreadSlot
{
	uint64_t counter; // padding은 컴파일러/플랫폼에 따라 달라질 수 있음
    char pad[64 - sizeof(uint64_t)];
};

ThreadSlot slots[MAX_THREADS];
void Worker(int tid)
{
	for (...)
    {
    	slots[tid].counter++; // 각자 자기 라인만 건드림
    }
}

이 설계는 속도 최적화라기보다
coherency 트래픽 최악 케이스 제거(안정화)입니다.

---

6) 처방 3: 큐/링버퍼는 head/tail(메타데이터)을 분리하라

Lock-free 큐에서 흔한 병목은 알고리즘이 아니라 메타데이터 배치입니다.

• head와 tail이 같은 캐시 라인에 있으면
• producer/consumer가 서로 다른 변수를 업데이트해도
• 같은 라인을 두고 ping-pong이 납니다 (False Sharing)

원칙

• head와 tail을 다른 캐시 라인으로 분리
• size/flags 같은 write-hot 메타데이터도 분리

이건 구조가 복잡해지기 전에 적용할수록 효과가 큽니다.

---

7) atomic을 써야 한다면: 최소한 이 관점으로 사용해라

atomic을 완전히 없앨 수 없는 경우도 있습니다.
그럴 때의 원칙은 단순합니다.

(1) hot loop에서 atomic을 빼라

• 루프 안에서 1회를 루프 밖에서 1회로 바꿔라 (batch)

(2) 공유 write-hot을 줄여라

• write 빈도를 낮추거나, 스레드별로 나누고 합쳐라

(3) 같은 라인을 두 스레드가 건드리지 않게 배치하라

• per-thread slot
• alignas(64) 또는 명시적 padding

여기까지 하면 atomic이 락처럼 느려지는 대부분의 상황은 정리됩니다.

---

8) 체크리스트: 이 조건이면 atomic 병목을 의심해라

• 스레드를 늘렸는데 throughput이 거의 안 오르거나 떨어진다
• 전역 카운터/통계/큐 인덱스가 hot path에 있다
• 프로파일에서 모두가 같은 위치를 건드린다는 냄새가 난다
• 락은 없는데도 CPU가 바쁘고 일이 안 끝난다

이때는 먼저 묻는 게 맞습니다.

“나는 지금 연산을 하고 있나, 아니면 캐시 라인 소유권을 주고받고 있나?”

---

마무리: 멀티스레드 최적화의 본질

시리즈를 4편까지 오면 결론은 선명해집니다.

• 1편: CPU는 연산보다 물류(메모리/캐시)가 문제다
• 2편: 멀티코어는 shared cache line 때문에 무너진다 (False Sharing)
• 3편: Invalidate는 감이 아니라 MESI 규칙으로 발생한다
• 4편(오늘): atomic의 비용은 락이 아니라 라인 소유권 경쟁이다

그래서 실전 처방도 단순합니다.

1. 공유 write-hot을 없애라
2. 스레드별로 누적하고 마지막에 합쳐라(reduction)
3. 어쩔 수 없이 공유하면 라인을 분리하라(alignas(64), layout)

이전글

다른 코어가 같은 캐시 라인을 가진 상태에서,
누군가 그 라인을 write(특히 RMW)로 독점하려는 순간.
Invalidate가 터진다.

우리는 False Sharing을 캐시 라인 ping-pong으로 봤습니다.
그런데 여기서 한 단계 더 정확해져야 해요.

Invalidate는 캐시 미스가 아니라, 쓰기 권한(소유권) 경쟁 때문에 발생한다.

즉, 멀티코어에서 느려지는 이유는 데이터가 멀리 있어서가 아니라
누가 그 캐시 라인을 ‘쓰기 가능한 최신 상태’로 갖고 있느냐를 맞추느라 트래픽이 터지기 때문입니다.

이걸 설명하는 최소 모델이 MESI입니다.

0) MESI를 한 문장으로 정의

캐시 라인(보통 64B)마다 CPU는 “이 라인이 지금 어떤 상태인가”를 관리합니다.

• M (Modified): 내가 수정했고(Dirty), 최신. 다른 코어는 못 가짐
• E (Exclusive): 나만 가지고 있고 최신. 아직 수정은 안 했음
• S (Shared): 여러 코어가 읽기용으로 공유 중
• I (Invalid): 무효(없다고 봐도 됨)

여기서 핵심은 딱 하나:

쓰기(write)는 ‘독점(Exclusive)’ 상태를 요구한다.
그래서 누가 쓰려고 하면, 다른 코어의 같은 라인은 Invalidate(I) 된다.

1) 읽기만 하면 보통 큰 싸움이 없다 (Read / Read)

두 코어가 같은 주소 X를 읽기만 한다고 하자.

• Core0: X를 읽음 → E 또는 S (상황에 따라)
• Core1: X를 읽음 → 둘 다 S로 수렴

여기서는 보통 Invalidate 폭발이 없습니다.
왜냐하면 읽기는 최신성만 맞으면 되고, 독점 소유권이 필요 없기 때문입니다.

결론: Read-mostly 공유는 비교적 안전하다.

2) 누군가 쓰기를 하는 순간부터 Invalidate가 시작된다 (Read / Write)

이제 Core1이 X를 write 한다고 하자. (X++ 같은 수정)

이미 Core0이 X를 S 상태로 갖고 있었다면?

• Core1은 쓰기 위해 X를 독점 상태(M / E)로 만들어야 함
• 그래서 Core0의 X는 I(Invalid) 로 바뀜

즉, 규칙은 간단합니다.

다른 코어가 같은 캐시 라인을 가지고 있는데, 누군가 write를 하려는 순간 → Invalidate 발생

이때 Core0는 내 캐시에 분명히 있었는데(I로 바뀌어서) 다시 가져와야 하고,
이게 Coherency Miss로 관측됩니다.

3) 최악은 Write / Write: 소유권이 공처럼 튕긴다 (Ping-Pong)

False Sharing이 터지는 대표 상황이 이거죠.

• Core0: 라인 X의 어떤 필드(변수 A)를 계속 write
• Core1: 같은 라인 X의 다른 필드(변수 B)를 계속 write

둘은 논리적으로 다른 변수지만, 캐시 라인이 같으면 같은 전쟁입니다.

흐름은 이렇게 됩니다.

1. Core0 write → X를 M로 만든다 (Core1 쪽 X는 I)
2. Core1 write → X를 M로 만들려 한다 → Core0 쪽 X는 I
3. Core0 write → 다시 독점 필요 → Core1 쪽 I
   … 무한 반복

여기서 중요한 포인트:

• 값 자체의 충돌이 없어도
• 캐시 라인 소유권 때문에
• Invalidate가 매번 발생한다.

결론: False Sharing은 shared data가 아니라 shared cache line 문제다.

4) 왜 RMW(atomic)이 특히 비싼가: 독점 + 순서를 강제한다

다음 편에서 atomic을 깊게 다루겠지만, 원리만 여기서 박아두면 이렇습니다.

atomic_fetch_add 같은 연산은 단순 write가 아니라 Read-Modify-Write입니다.

• 값을 읽고
• 수정하고
• 다시 쓰는 작업

이건 의미상 중간에 다른 코어가 끼면 안 되기 때문에,
하드웨어는 보통 해당 라인을 더 강하게 독점하려고 합니다.

즉, 경쟁 상황에서 atomic은 이렇게 동작해요.

• 여러 코어가 동일 라인에 대해 RMW를 시도
• 각 코어가 “내가 지금 독점해서 처리해야 함”을 강제
• 결과적으로 invalidate + 소유권 이동이 더 자주, 더 비싸게 발생

그래서 atomic 비용을 락이니까 느리다고만 보면 진단이 반쯤 틀립니다.

atomic의 핵심 비용은 락이 아니라, 캐시 라인 소유권 경쟁(= coherency 트래픽)이다.

이게 4편의 주제가 됩니다.

5) 이 규칙을 코딩 관점으로 번역하면

MESI를 외우는 목적은 상태도를 잘 그리자는 게 아닙니다.
코드를 이렇게 분류하기 위해서예요.

안전한 패턴(대체로)

• read-mostly 공유 (초기화 후 읽기 전용)
• 스레드마다 자기 데이터에 write (서로 다른 라인)

위험한 패턴(거의 확실히 터짐)

• 여러 스레드가 같은 라인에 write
• 서로 다른 변수라도 같은 캐시 라인이면 동일하게 위험
• 경쟁 상황의 atomic RMW (특히 hot counter)

여기서 2편에서 말한 alignas(64)가 다시 의미를 갖습니다.

• alignas(64)는 단순히 빠르게 하는 것이 아니라
• write-hot 데이터가 같은 캐시 라인을 공유하지 않게 하는 장치
• 즉 Invalidate 규칙을 회피하는 설계입니다.

마무리

여기까지 정리하면, 멀티스레드에서 성능이 무너지는 이유는 CPU가 느려서가 아닙니다.

CPU는 연산보다
데이터를 가져오는 방식에
훨씬 민감하다.

CPU 최적화를 연산을 줄이는 일로만 보면, 체감 성능이 잘 안 나옵니다. 실전 병목은 대개 계산(ALU)이 아니라 메모리 접근(Load/Store)에서 터집니다. CPU는 load => execute => add 같은 일을 파이프라인으로 겹쳐서 처리할 수 있지만, 데이터가 제때 도착하지 않으면 실행 유닛은 그냥 놀게 됩니다.

1) 패러다임 전환: 연산이 아니라 물류(Load/Store)가 문제다

CPU 내부엔 역할 분리가 있습니다.

• LSU(Load/Store Unit): 메모리를 읽고/쓰는 담당
• ALU/FPU/SIMD: 실제 계산 담당

코드가 느릴 때 계산량이 많아서일 수도 있지만, 더 흔한 케이스는 이겁니다.

• 계산은 준비됐는데 로드가 늦어서 실행이 멈춘다.
• 실행 중에 다음 데이터를 추가로 로드하려다가 캐시 미스로 브레이크가 걸린다.

그래서 최적화의 시작점은 연산 줄이기가 아니라 캐시 히트율을 올리는 데이터 배치입니다.

2) 캐시의 작동 원리: CPU는 64B ‘박스’ 단위로 움직인다

캐시는 바이트 단위로 움직이지 않습니다. 보통 캐시 라인(Cache Line) 단위(대부분 64B)를 최소 단위로 가져오고 버립니다.

여기서 지역성이 나옵니다.

• 공간 지역성(Spatial): 다음에 접근할 메모리가 인접해 있다.
• 시간 지역성(Temporal): 방금 접근한 메모리를 곧 다시 쓴다.

즉, 우리가 코드를 예측 가능하게 만든다는 말의 실체는 대부분 이겁니다.

• 인접 데이터를 연속으로 쓰게 만들고(공간)
• 최근에 쓴 데이터를 다시 쓰게 만들면(시간)
• 캐시 히트율이 올라가고, 로드 지연이 줄어듭니다.

3) 예측 실패보다 무서운 설계 실수: 캐시 미스는 4C로 보자

교과서적 분류는 3C(Cold/Capacity/Conflict)지만, 멀티코어까지 다루려면 4C가 더 정합적입니다.

4C Cache Miss

1. Cold (Compulsory) Miss
   처음 접근이라 캐시에 없어서 발생.
2. Capacity Miss
   캐시 용량 자체가 부족해서, 담아두지 못하고 밀려남.
3. Conflict Miss
   캐시에 공간은 있는데 매핑/세트 충돌 때문에 교체가 과하게 발생.
   특히 stride 패턴이 캐시 인덱스와 맞물리면 계속 갈아엎는 현상이 나옵니다.
4. Coherency Miss (일관성 미스)
   다른 코어가 내가 들고 있던 캐시 라인을 수정해서 Invalidate가 걸린 경우.
   이게 나중에 말할 False Sharing의 바로 그 뿌리입니다.

여기서 중요한 건, 미스를 예측 실패 하나로 뭉개면 원인 진단이 틀어진다는 점입니다.
Capacity인지, Conflict인지, Coherency인지에 따라 처방이 완전히 달라집니다.

4) Stride 프리패처: CPU는 일정 보폭을 좋아한다

하드웨어 프리패처는 다음 줄을 무조건 읽어오기만 하지 않습니다. 규칙적인 보폭(Stride)을 학습합니다.

예를 들어:

• [0] -> [4] -> [8] -> [12] 처럼 일정하면
  → 4칸씩 뛴다는 점을 학습하고 미리 끌어옵니다.

반대로,

• stride가 너무 크거나(Large Stride)
• 접근 주소가 불규칙하게 튀면(Random)
  → 프리패처가 포기하거나 정확도가 떨어집니다.

이 지점이 CPU가 좋아하는 데이터 배치의 현실적인 기준입니다.
연속 배열 + 규칙적 루프는 프리패처, 캐시, SIMD까지 한 번에 정렬됩니다.

5) 구조체 설계의 정석: 무조건 alignas가 아니라 데이터 구겨넣기(Packing)가 먼저다

정렬(Alignment)은 분명 도움이 됩니다. 특히 캐시 라인을 걸치지 않게 만들거나, 멀티스레드에서 라인 공유를 피하는 데도 쓰입니다. 하지만 무작정 alignas(64)부터 박으면 이런 문제가 생깁니다.

• 구조체가 작아도 64B 패딩이 붙어 캐시 오염(cache pollution)이 생김
• 결과적으로 실제 유효 데이터 대비 로드량이 늘어서 히트율이 떨어질 수 있음

그래서 우선순위는 보통 이 순서가 맞습니다.

1. 필드 재배치 / 타입 정리로 패딩을 줄인다.
2. 남는 공간은 자주 쓰는 필드로 메꿔서 64B를 꽉 채운다. (패킹)
3. 그래도 필요할 때만 alignas(64) 같은 강제 정렬을 쓴다.

그리고 여기서 다음 글 떡밥이 자연스럽게 이어집니다.

• 구조체를 64B 정렬하는 이유는 속도만이 아니라
  멀티코어에서 False Sharing(거짓 공유)를 피하기 위한 목적도 큽니다.
  (서로 다른 스레드가 같은 캐시 라인을 건드리면 Coherency Miss가 폭발합니다.)

6) AoS vs SoA: 데이터의 본질이 아닌 접근 패턴으로 결정한다

여기서 정답을 단정하면 항상 사고가 납니다. 결론은 하나입니다.

AoS/SoA는 취향이 아니라,
루프의 형태로 결정한다.

AoS (Array of Structures)

• 개체 하나를 잡고 여러 필드를 같이 만지는 패턴에 유리
• 단점: 특정 필드만 훑을 때 불필요한 데이터까지 같이 로드될 수 있음

struct Agent { float pos, vel, health; };
Agent agents[100];

SoA (Structure of Arrays)

• 같은 필드를 대량으로 훑는 패턴(예: pos만 10만 개 업데이트)에 유리
• 장점: 캐시/프리패처/SIMD와 궁합이 좋은 경우가 많음
• 단점: 개체 단위로 여러 필드를 동시에 만지면 오히려 산개 접근이 될 수 있음

struct AgentGroup { float pos[100], vel[100], health[100]; };

※ 참고로 Epic Games의 Unreal Engine 쪽에서 ECS 계열(예: Mass 같은 접근)을 떠올릴 수 있는데, 엔진 기능 자체보다 중요한 건 “내 루프가 무엇을 연속으로 훑는가”입니다. 기능 이름보다 접근 패턴이 먼저입니다.

7) 현대 하드웨어의 복잡성: L3 포함 정책은 유연해지는 추세

마지막으로, 멀티코어 시대에 L3 정책 이야기를 안 하면 반쪽입니다.

• L1/L2: 코어 전용, 빠르고 작음
• L3: 여러 코어가 공유, 상대적으로 크고 느림

여기서 Inclusive / Non-Inclusive 얘기가 나오는데, 포스팅에서 중요한 태도는 이겁니다.

• 제조사별 경향성은 참고 가치가 있지만
• 최근에는 코어 수 증가와 L3 효율 문제 때문에
  두 진영 모두 정책을 더 유연하게 가져가는 추세라는 점을 같이 적는 게 신뢰도가 높습니다.

즉, 브랜드로 단정하기보단 마이크로아키텍처/제품군 기준으로 확인하는 게 맞습니다.
(특히 서버/워크스테이션 라인업은 정책이 다르게 나타나는 경우가 많습니다.)

여기서 Intel / AMD 비교를 할 때도 단정이 아니라 확인이 핵심입니다.

이 글의 결론, “캐시를 설계하라”

CPU 최적화는 결국 이 두 문장으로 요약됩니다.

1. 연산보다 로드가 먼저 병목이다.
2. 캐시는 라인 단위로 움직이고, 미스는 4C로 구분해야 한다.

다음 글에서 이어설명할 주제는 아래와 같습니다.

• Coherency Miss와 False Sharing
• 왜 alignas(64)가 속도가 아니라 멀티코어 안정성의 문제인지
• 그리고 멀티스레드에서 캐시 라인을 어떻게 분리/배치할지

이전글

Coherency Miss(일관성 미스)로 보는
캐시 라인 전쟁과 해결 전략,
alignas(64)는 속도가 아니라
멀티코어 안정성이다.

싱글 스레드 최적화는 보통 캐시 히트율로 설명이 끝납니다.
하지만 멀티스레드에 들어가면 캐시 미스의 얼굴이 하나 더 늘어납니다.

Coherency Miss(일관성 미스).

이건 캐시에 없어서가 아니라, 다른 코어가 내 캐시 라인을 건드려서 내 캐시가 무효화(invalidate)되는 미스입니다. 즉, 데이터가 원래 캐시에 있었는데도, 멀티코어 환경 때문에 있었지만 없어진 것이 됩니다.

1) Coherency Miss란 무엇인가

멀티코어 CPU는 각 코어가 L1/L2 같은 빠른 캐시를 따로 들고 있습니다.
그럼 문제가 생겨요.

• 코어 A가 어떤 메모리 주소 X를 캐시에 들고 있음
• 코어 B도 같은 주소 X를 캐시에 들고 있음
• 코어 B가 X를 쓰기(write) 하면?
• 코어 A가 들고 있던 X는 더 이상 최신이 아님

그래서 CPU는 캐시 일관성 프로토콜(MESI 계열)로 누가 최신인지를 맞춥니다.
이때 흔히 일어나는 현상이:

• invalidate(무효화): 다른 코어가 수정한 라인을 내 캐시에서 폐기
• 다음에 내가 읽을 때는 다시 가져와야 함 → coherency miss

이게 Coherency Miss의 정체입니다.
핵심은 데이터가 멀리 있어서 느린 게 아니라, 서로 방해해서 느린 것입니다.

2) False Sharing: 같은 데이터를 공유한 적이 없는데 공유가 발생한다

False Sharing(거짓 공유)은 더 악질입니다.

두 스레드가 서로 다른 변수를 쓰는데도 느려져요.
왜냐하면 캐시는 변수 단위가 아니라 캐시 라인(보통 64B) 단위로 일관성을 맞추기 때문입니다.

예를 들어, 같은 캐시 라인 안에 아래 두 변수가 들어있다고 하자.

• counterA (스레드 A가 계속 증가)
• counterB (스레드 B가 계속 증가)

둘은 다른 변수고, 논리적으로는 공유가 아닙니다.
하지만 캐시 라인 단위로 보면 둘은 같은 64B 박스 안에 들어 있음.

그러면 벌어지는 일:

1. 스레드 A가 counterA++
   → 해당 캐시 라인(64B)을 쓰기 가능한 최신 상태로 만들기 위해 독점화
2. 스레드 B가 counterB++
   → 똑같은 캐시 라인을 독점화하려고 함
   → A 쪽 라인 invalidate
3. A가 또 counterA++
   → 다시 라인 가져오고 invalidate 반복

이게 흔히 말하는 ping-pong입니다.
캐시가 공처럼 튕기면서 coherency 트래픽이 폭발하고, 성능이 급격히 떨어집니다.

즉, False Sharing은 데이터 공유가 아니라
캐시 라인 공유가 문제입니다.

3) 왜 alignas(64)는 속도가 아니라 안정성인가

많은 사람들이 alignas(64)를 빠르게 하려고 붙입니다.
하지만 멀티스레드에서 alignas(64)의 진짜 목적은 다른 쪽입니다.

서로 다른 스레드가 쓰는 데이터가 같은 캐시 라인에 들어가지 않게 보장하는 것.

즉, False Sharing을 구조적으로 차단하는 장치입니다.

여기서 속도라는 표현이 위험한 이유가 있어요.

• 싱글 스레드에서 alignas(64)는 오히려 패딩이 늘어 캐시 효율을 떨어뜨릴 수 있음
• 멀티스레드에서 alignas(64)는 패딩을 감수하더라도 coherency 폭발을 막아 성능을 안정화함

그래서 alignas(64)는 평균 성능 상승이 아니라
최악의 경우를 제거하는 안정성 장치에 가깝습니다.

4) 멀티스레드에서 캐시 라인을 분리/배치하는 실전 전략

아래는 현업에서 바로 적용하는 순서입니다.

(1) 쓰기를 분리하라: write-hot 데이터부터 격리

False Sharing은 거의 항상 write-write 또는 write-read에서 터집니다.
그래서 먼저 찾아야 하는 건:

• 여러 스레드가 자주 쓰는 변수(카운터, 플래그, 상태값, work queue head/tail 등)

이런 변수는 각 스레드 전용 구조체로 분리하거나, 최소한 캐시 라인을 분리해야 합니다.

(2) Thread-local(스레드 로컬)로 바꾸고 마지막에 합쳐라

공유 카운터를 매번 증가시키는 대신:

• 스레드별 로컬 카운터에 누적
• 프레임 끝/작업 끝에 한 번 합산(reduction)

이건 캐시 최적화라기보다 coherency 최적화입니다.

(3) 구조체를 역할로 쪼개라: read-mostly vs write-hot

AoS/SoA와 같은 결로, 멀티스레드에서도 데이터는 성격이 갈립니다.

• read-mostly(거의 안 변함): 공유해도 비교적 안전
• write-hot(자주 변함): 공유하면 폭발

write-hot만 따로 빼서 alignas(64)를 주는 식으로,
전체 구조체에 무작정 패딩을 박지 않는 게 포인트입니다.

(4) 캐시 라인 패딩 패턴(실전 템플릿)

가장 흔한 패턴:

struct alignas(64) ThreadCounter
{
	std::atomic<uint64_t> value;
	char pad[64 - sizeof(std::atomic<uint64_t>)];
};

핵심은 변수 하나를 64B 박스 하나에 고정시키는 것.
이러면 서로 다른 스레드의 카운터가 같은 라인에 섞일 일이 없습니다.

(5) 큐/링버퍼는 헤더와 테일을 분리한다

멀티프로듀서/멀티컨슈머 구조에서 자주 터지는 포인트가:

• head / tail
• size / flags

이런 메타데이터가 같은 캐시 라인에 붙어있으면 False Sharing이 쉽게 납니다.
헤더와 테일을 다른 캐시 라인으로 분리하면 체감이 크게 바뀌는 경우가 많습니다.

5) 체크리스트: 이 증상이면 False Sharing을 의심해라

• 스레드를 늘렸는데 성능이 안 오르거나 오히려 떨어진다
• CPU 사용률은 높은데 처리량이 늘지 않는다
• 특정 공유 카운터/플래그를 제거하면 성능이 갑자기 좋아진다
• 동일 코드를 단일 스레드로 돌리면 안정적이다

이 경우는 연산 최적화가 아니라
coherency/false sharing 최적화를 먼저 의심하는 게 맞습니다.

마무리

Coherency Miss와 False Sharing은 캐시가 부족해서가 아니라
캐시가 서로 싸워서 생기는 성능 붕괴입니다.

그래서 alignas(64)는 “빠르게 만들기”가 아니라
멀티코어에서의 안정성(최악 제거)을 위한 설계 도구입니다.

다음글