8강 / 20강

캐시 — 순서만 바꿔도 10배

캐시 라인 64바이트가 만드는 성능 차이

같은 개수의 숫자를 더하는 두 프로그램이 있습니다. 하나는 순서대로 훑고, 하나는 띄엄띄엄 훑습니다. 계산량은 똑같아요. 그런데 속도는 10배가 차이 납니다.

왜일까요? 캐시 라인 때문입니다.

고등학생순서만 바꿔도 10배

같은 자료, 같은 계산, 같은 개수. 읽는 순서만 바꿨는데 10배 차이가 납니다.

왜? — 캐시는 한 개가 아니라 한 줄을 가져온다

캐시 라인 64바이트

메모리에서 1바이트가 필요해도 CPU 는 64바이트를 통째로 가져옵니다.

필요한 것	가져오는 것
1바이트	64바이트

낭비 같지만 — 공간 지역성 때문에 대개 이득

그래서 순서가 결정적입니다

읽는 순서	64바이트 중 쓰는 것	효율
순서대로	64바이트 전부	100%
건너뛰며	8바이트만	12.5%

건너뛰면 8배를 버린다 — 그게 10배 차이의 정체

비유 — 창고에서 물건 꺼내기

창고에서 물건을 꺼낼 때 박스 단위로 가져옵니다.

방식	결과
한 박스에서 전부 꺼낸다	한 번에 끝
박스마다 하나씩 꺼낸다	박스를 여러 번 나른다

같은 개수를 꺼내는데 왕복 횟수가 다르다

캐시 라인 — 항상 64바이트씩

CPU가 메모리에서 정수 하나(4바이트)를 부탁하면, 메모리 컨트롤러는 그 주변 64바이트를 통째로 실어 옵니다. 트럭이 한 번 가는데 짐 하나만 싣고 올 이유가 없거든요.

필요한 것:  [■]
실제로 오는 것: [■][ ][ ][ ][ ][ ][ ][ ]  ← 64바이트 = 정수 16개

그래서 다음에 옆 칸을 읽으면 공짜입니다. 이미 캐시에 와 있으니까요. 반대로 다음에 100칸 떨어진 곳을 읽으면 또 다녀와야 합니다.

고등학생2차원 배열이 만드는 함정

실무에서 가장 자주 만나는 예입니다.

2차원 배열은 메모리에 한 줄로 펴져 있다

이렇게 놓입니다 (행 우선)

논리	메모리 순서
a[0][0] a[0][1] a[0][2]	a[0][0], a[0][1], a[0][2], a[1][0], a[1][1], a[1][2]
a[1][0] a[1][1] a[1][2]	a[0][0], a[0][1], a[0][2], a[1][0], a[1][1], a[1][2]

같은 행은 붙어 있고, 같은 열은 멀리 있다

그래서 순회 방향이 중요합니다

순회	메모리 접근	속도
행 우선 (i 바깥, j 안쪽)	순서대로 ✔	빠르다
열 우선 (j 바깥, i 안쪽)	건너뛴다 ✗	느리다

반복문 두 줄의 순서만 바꿔도 몇 배

얼마나 차이 나나

배열이 클수록 커집니다.

배열 크기	차이
100×100 (캐시에 다 들어감)	거의 없다
10000×10000	5~10배

작을 땐 안 보이다가 커지면 터진다 — 가장 무서운 유형

비유 — 도서관 서가

책이 가로로 꽂혀 있습니다.

한 칸을 왼쪽에서 오른쪽으로 — 서서 팔만 뻗으면 된다
여러 칸에서 같은 위치만 — 계속 걸어야 한다

같은 권수인데 걸은 거리가 다르다

간격을 늘리면 일은 줄어드는데 개당 비용은 올라갑니다.

Python 브라우저에서 실행

# 브라우저 안에서 진짜로 재 본다 (Pyodide)
import time

N = 2_000_000
데이터 = [1] * N

def 재기(간격):
    t = time.perf_counter()
    합 = 0
    for i in range(0, N, 간격):
        합 += 데이터[i]
    return (time.perf_counter() - t) * 1000, 합

print(f"{'간격':>6}{'읽은 개수':>12}{'걸린 시간':>12}{'개당 시간':>14}")
print("-" * 46)
기준 = None
for 간격 in [1, 2, 4, 16, 64, 256]:
    ms, _ = 재기(간격)
    개수 = len(range(0, N, 간격))
    개당 = ms * 1000 / 개수      # 마이크로초
    print(f"{간격:>6}{개수:>12,}{ms:>10.1f} ms{개당:>12.4f} µs")

print()
print("→ 간격이 커지면 '읽은 개수'는 줄었는데 '개당 시간'은 늘어납니다.")
print("  캐시 라인 하나에서 하나만 쓰고 버리기 때문이에요.")

실무에서 이게 나오는 곳 — 2차원 배열

파이썬 리스트든 C 배열이든 넘파이 행렬이든, 2차원 데이터는 메모리에 한 줄로 펴져 있습니다. 그래서 행 우선으로 훑느냐 열 우선으로 훑느냐가 캐시 히트율을 가릅니다.

같은 계산, 다른 순서, 다른 속도.

Python 브라우저에서 실행

import time
N = 700
행렬 = [[1] * N for _ in range(N)]

t = time.perf_counter()
합 = 0
for i in range(N):
    행 = 행렬[i]
    for j in range(N):
        합 += 행[j]              # 옆으로 옆으로 — 메모리 순서대로
행우선 = (time.perf_counter() - t) * 1000

t = time.perf_counter()
합 = 0
for j in range(N):
    for i in range(N):
        합 += 행렬[i][j]         # 아래로 아래로 — 매번 N칸씩 건너뛴다
열우선 = (time.perf_counter() - t) * 1000

print(f"행 우선 (옆으로): {행우선:8.1f} ms")
print(f"열 우선 (아래로): {열우선:8.1f} ms")
print(f"→ {열우선/행우선:.1f}배 차이")
print()
print("계산량은 완전히 같습니다. 순서만 바꿨는데요.")

고등학생쇼핑몰 관리자가 만나는 캐시 문제

note 가 실무 사례를 듭니다. "우린 배열 계산 안 하는데?" 싶겠지만 — 만납니다.

① DB 가 느려질 때

DB 도 같은 원리로 돕니다.

DB 용어	구조론 용어
버퍼 풀	캐시
페이지 (8KB)	캐시 라인
순차 스캔	순서대로 읽기
인덱스 랜덤 액세스	건너뛰며 읽기

그래서 DB 가 인덱스를 안 쓰기로 결정하는 경우가 있다

많은 행을 읽을 거면 순차 스캔이 더 빠릅니다. 건너뛰는 비용이 크니까요.

② JSON 을 큰 덩어리로 다룰 때

수십 MB JSON 을 파싱하면 메모리 여기저기에 객체가 흩어집니다.

캐시가 전혀 안 맞는다 — 그래서 느리다

③ 파이썬 리스트 vs NumPy 배열

	메모리 배치	속도
파이썬 리스트	포인터가 흩어져 있다	느리다
NumPy 배열	연속이다	10~100배

NumPy 가 빠른 이유의 절반이 이것이다

/python 강의에서 "NumPy 가 빠르다" 고 했죠. 왜 빠른지가 이제 보입니다.

진짜 CPU의 캐시 미스를 세어 봅시다

리눅스의 perf 는 CPU 안에 있는 하드웨어 계수기를 읽습니다. 캐시 미스가 몇 번 났는지, IPC가 얼마인지를 실제로 세어 줘요.

cache-misses 비율과 IPC를 봅니다.

bash 브라우저에서 실행

perf stat true

보통 이렇게 읽습니다.

IPC 2 이상 — 아주 좋음. CPU가 쉬지 않고 일하는 중
IPC 1 안팎 — 보통
IPC 0.5 미만 — CPU가 뭔가를 기다리고 있다. 대개 메모리
cache-miss 10% 이상 — 데이터 접근 패턴을 의심할 때

캐시가 여러 개일 때 — 코어끼리 싸운다

이 서버는 6코어입니다. L1·L2는 코어마다 하나씩, L3는 여섯이 나눠 씁니다.

L1/L2는 짝꿍 스레드끼리, L3는 전체가 나눠 씁니다.

bash 브라우저에서 실행

# 어느 캐시를 누구와 나눠 쓰는지
for i in 0 1 2 3; do
  echo "index$i: L$(cat /sys/devices/system/cpu/cpu0/cache/index$i/level) $(cat /sys/devices/system/cpu/cpu0/cache/index$i/type) $(cat /sys/devices/system/cpu/cpu0/cache/index$i/size) 공유=$(cat /sys/devices/system/cpu/cpu0/cache/index$i/shared_cpu_list)"
done

고등학생관리자를 위한 결론

note 의 결론을 행동 지침으로 바꿔 봅시다.

캐시는 직접 못 만진다 — 대신 맞게 접근한다

할 수 있는 것

행동	왜
순서대로 읽기	캐시 라인을 다 쓴다
작게 유지하기	캐시에 들어가면 100배
연속 자료구조 쓰기	배열 > 연결 리스트
필요한 열만 조회	SELECT * 를 피한다

SELECT * 가 왜 나쁜지가 여기서 보입니다

안 쓸 열까지 메모리로 가져오면 그만큼 캐시가 쓸모없는 것으로 찹니다.

쓰지도 않을 자료가 쓸 자료를 밀어낸다

그리고 알아야 할 한계

캐시 최적화는 대개 마지막 수단입니다.

먼저 볼 것	효과
알고리즘 (O(n²) → O(n log n))	수백 배
DB 왕복 줄이기	수십 배
인덱스 추가	수십 배
캐시 친화적으로	2~10배

큰 것부터 — 캐시는 다 하고 나서

15강의 진단 순서가 그래서 중요합니다. 어디가 병목인지 먼저 보는 거죠.

🤔 확인 문제

정수 배열을 a[0], a[1], a[2]… 순서로 읽는 것이 a[0], a[1000], a[2000]… 보다 훨씬 빠른 이유는?

🤔 확인 문제

perf stat 결과가 IPC 0.3, cache-misses 22% 로 나왔습니다. 무엇을 의심해야 할까요?