본문으로 건너뛰기
HMYHardware Wiki

HMY-Wiki

하드웨어 / CPU

CPU Cache

CPU Cache는 자주 쓰거나 곧 다시 쓸 가능성이 높은 명령과 데이터를 DRAM보다 가까운 곳에 둔다. 프로그램은 가까운 주소를 연속으로 쓰는 공간 지역성과, 최근에 쓴 데이터를 다시 쓰는 시간 지역성을 자주 보인다. 캐시는 이 성질을 이용해 긴 메모리 대기를 줄인다. DRAM까지 갔다 오는 비용이 워낙 크기 때문에, 캐시가 맞히는 비율이 체감 성능을 크게 바꾼다.

캐시 계층

L1
코어에 가장 가깝고 작다. 명령·데이터로 나뉘는 경우가 많다
L2
L1보다 크지만 접근이 늦다
L3
여러 코어가 공유하는 설계가 흔하다
SoC 캐시
GPU·NPU·ISP가 함께 쓰기도 한다

동작

Hit / Miss
요청 주소가 캐시에 있는지 여부
Cache Line
고정 크기 단위로 데이터를 옮긴다
일관성
여러 코어의 캐시 상태를 맞춘다

L1은 코어에 가장 가깝고 작으며, 명령과 데이터 캐시로 나뉘는 경우가 많다. L2는 더 크지만 접근이 늦고, L3 또는 Last-Level Cache는 여러 코어가 공유하는 설계가 흔하다. 모바일 SoC의 System Level Cache는 CPU뿐 아니라 GPU와 NPU, ISP 같은 블록이 함께 쓰기도 한다.

캐시는 보통 고정 크기 Cache Line 단위로 데이터를 옮긴다. 요청한 주소가 캐시에 있으면 Hit, 없으면 Miss다. 연속 접근에서는 한 Line에 함께 들어온 데이터가 도움이 되지만, 큰 배열을 건너뛰며 접근하면 가져온 데이터 대부분을 쓰지 못한다.

여러 코어가 같은 메모리를 캐시에 보관하면 일관성(Coherence)을 유지해야 한다. 한 코어의 쓰기가 다른 코어에 언제 보이는지와, 프로그램이 요구하는 메모리 순서는 별도 규칙으로 관리된다. 공유 데이터에 여러 스레드가 자주 쓰면 캐시 Line이 코어 사이를 오가며 성능이 떨어진다.

캐시 용량이 크면 Miss를 줄일 수 있지만 접근 지연과 면적, 전력, 열이 함께 늘어난다. 3D 적층 캐시는 패키지 위에 캐시 다이를 쌓아 용량을 늘리지만, 열 경로와 제품별 클럭 정책도 같이 달라진다. 캐시 크기 하나만으로 CPU 전체 성능을 비교하지 않는 이유다.

False Sharing과 작업 데이터 크기

두 스레드가 서로 다른 변수를 수정해도 그 변수들이 같은 Cache Line에 놓이면 일관성 트래픽을 유발할 수 있다. 이를 False Sharing이라고 한다. 예를 들어 스레드별 카운터를 촘촘한 배열에 두면 논리적으로 독립된 업데이트가 같은 Line의 소유권을 놓고 경쟁한다. 공유 쓰기 자체가 필요한 경우와 변수 배치 때문에 생긴 경합을 구분해야 한다.

작업에 반복해서 쓰이는 데이터 집합이 캐시보다 작으면 재사용 효과가 크지만, 용량을 넘으면 교체가 잦아진다. 반대로 큰 데이터를 한 번만 순차 처리하는 작업은 캐시 용량보다 메모리 대역폭에 묶일 수 있다. 캐시 증설이 게임, 데이터베이스, 순차 스트리밍에서 서로 다른 효과를 보이는 배경이다.

관련: 파이프라인과 비순차 실행, 클럭·대역폭·지연시간

참고 링크