실습: for문 순서와 CPU 캐시 (JavaScript)

영상 for문 순서를 바꿨을 뿐인데 10배 빨라졌습니다의 내용을 로컬에서 직접 재현하는 실험입니다. PPT: ../ppt/01-cpu-cache.html

실행 방법

``bash node 01-cpu-cache.js ``

Node.js만 있으면 됩니다 (별도 패키지 불필요).
1억 칸(10,000×10,000) 배열을 사용하므로 메모리 약 400MB 이상 여유가 필요합니다.
수치는 머신/Node 버전에 따라 달라집니다.

실험 구성

| 실험 | 내용 | 확인하려는 것 | |------|------|---------------| | A | 2차원 배열(배열의 배열)을 행 우선 vs 열 우선 순회 | 공간 지역성 — 순회 순서만 바꿔도 속도 차이 발생 | | B | 1차원 Int32Array(완전 연속 메모리)를 같은 방식으로 순회 | 연속 메모리에서도 열 우선은 캐시 라인을 낭비함 | | C | 행 우선끼리 2차원 vs 1차원 비교 | 언어별 배열 구조 차이의 영향 |

실측 결과 (Windows 11, Node 실행 예시)

``` --- A) 2차원 배열 (배열의 배열) --- 행 우선 arr[i][j] (i 바깥, j 안쪽) 50 ms 열 우선 arr[i][j] (j 바깥, i 안쪽) 585 ms → 열 우선이 약 11.6배 느림 ← 영상의 "10배"가 그대로 재현됨

--- B) 1차원 Int32Array (완전 연속) --- 행 우선 flat[iN + j] 102 ms 열 우선 flat[iN + j] (j 바깥) 460 ms → 열 우선이 약 4.5배 느림 ```

왜 이런 결과가 나오나

A에서 11.6배: CPU는 메모리에서 int 하나를 읽을 때 64바이트 캐시 라인(int 16개)을 통째로 가져옵니다.

행 우선은 그 16개를 연달아 사용하지만(캐시 적중), 열 우선은 15개를 쓰기 전에 다음 행으로 점프해서 매번 메모리까지 다녀옵니다(캐시 미스). 캐시 ~1ns vs 메모리 ~100ns 차이가 1억 번 누적된 결과입니다.

B에서도 4.5배: 완전 연속 메모리에서도 열 우선 순회는 N×4바이트씩 점프하므로 캐시 라인을 낭비합니다.

차이가 A보다 작은 이유는 순수하게 접근 패턴 효과만 남기 때문입니다.

주의: C 실험은 JS에서 영상과 다르게 나올 수 있음

영상(자바 기준)에서는 "2차원 배열은 행마다 별도 객체라 1차원으로 펼치면 더 빠르다"고 설명합니다. 그런데 JS에서는 2차원(행 우선)이 1차원보다 오히려 빠르게 측정될 수 있습니다.

V8 JIT가 안쪽 루프의 Int32Array 행 접근을 강하게 최적화합니다 (행 참조를 레지스터에 캐싱).
i*N + j 인덱스 계산의 곱셈 비용이 상대적으로 드러납니다.
JS의 "배열의 배열"에서 각 행을 Int32Array로 만들면 행 내부는 이미 연속 메모리입니다.

즉, "순회 순서(공간 지역성)" 교훈은 언어와 무관하게 성립하지만(A·B에서 재현), "1차원 펼치기" 최적화는 자바/C처럼 배열 구조가 다른 언어에서 뚜렷한 기법입니다. 벤치마크는 반드시 자기 언어·런타임에서 직접 재봐야 한다는 것도 이 실험의 교훈 중 하나입니다.

직접 바꿔볼 것들

N을 1,000으로 줄이면? (전체가 캐시에 들어가면 차이가 급감하는지 확인)
Int32Array 대신 일반 배열 []로 바꾸면? (박싱/희소 배열 영향)
안쪽 루프에서 읽기만(sum += arr[i][j]) 하면 쓰기와 차이가 있는지?