µop 캐시와 루프 분할: 작아진 코드가 항상 빠르지는 않습니다

디코딩 결과의 재사용은 데이터 캐시와 다른 경로입니다

Intel의 DSB는 이미 디코딩한 명령의 재사용 경로입니다. AMD의 Op Cache도 프런트엔드에서 디코딩 결과를 공급하지만, 서로의 저장 단위와 용량을 같은 수치로 일반화할 수 없습니다. 데이터 L1 위에 있는 공통 캐시라는 의미가 아닙니다.

명령 공급 경로의 자체 개념도 · 특정 코어의 전체 블록도가 아님

바이트 → 디코더 ┐
캐시된 결과 ────┤
               ↓
           µop/Op 큐
               ↓
              실행

Intel 최적화 매뉴얼 Vol. 2, 050판의 Sandy Bridge 예에서는 32 sets × 8 ways × 6 µops = 이상적 1,536 µops입니다. 32바이트 코드 구간과 분기 등 배치 제약 때문에 단순 총량만으로 적중을 예측할 수 없습니다. AMD GDC 2023 Zen 4 자료의 4K → 6.75K ops는 그 세대 변화의 설명이지 모든 x86 코어의 용량이 아닙니다.

바이너리의 명령어 수·바이트 수와 캐시된 µop 수는 다른 단위입니다. GCC의 루프 정렬은 hot loop 시작 위치를 맞추기 위해 패딩을 넣을 수 있습니다. 어셈블리에서 NOP을 찾았다는 사실만으로 DSB 적중을 확인한 것은 아닙니다.

순서를 바꿔도 되는지 먼저 확인합니다

Intel Vol. 1의 loop fission 설명은 큰 계산 루프가 Decoded ICache를 넘을 때 작은 루프로 나누는 방안을 다룹니다. 아래 C 코드는 개념 예이며 벤치마크가 아닙니다. a·b·c가 서로 겹치지 않는 유효 배열이고 반복 간 의존성·관측 가능한 부수효과가 없으며 연산이 정의된 범위라는 조건이 필요합니다.

/* Before: distinct, non-overlapping arrays. */
for (size_t i = 0; i < n; ++i) {
    a[i] += b[i];
    c[i] = a[i] * scale;
}
/* After: preserve the producer before its consumer. */
for (size_t i = 0; i < n; ++i)
    a[i] += b[i];
for (size_t i = 0; i < n; ++i)
    c[i] = a[i] * scale;

분할하면 a를 다시 순회하고 루프 제어도 늘어납니다. 본문은 작아져도 데이터 캐시 재사용·대역폭·벡터화·명령어 수준 병렬성은 나빠질 수 있습니다. Clang loop distribution도 분할이 항상 이득이 아니라고 설명합니다.

별칭 반례도 있습니다. a = [1,2,3], b = [10,20], scale = 2, n = 2이고 c가 a의 두 번째 원소부터 겹친다고 합시다. 원래 루프는 첫 반복에서 다음 a를 바꿔 최종 [11,42,84]가 됩니다. 분할 루프는 [11,22,44]가 됩니다. 이 경우 속도를 재기 전에 변환 자체를 거부해야 합니다. 예제의 작은 정수로 계산한 논리 반례이며 C 컴파일·실칩 실행 결과가 아닙니다.

원본·정렬만 변경·분할을 따로 비교합니다

CPU 모델과 리비전, 컴파일러 버전·옵션, 입력 크기와 스레드 배치를 고정하고 실제 hot loop를 찾습니다.
같은 작업량에서 실행 시간·명령어 수·IPC와 프런트엔드 지표를 반복 측정합니다. VTune의 Front-End Bound와 DSB Switches는 원인 후보를 좁히는 자료이지 단독 성능 판정이 아닙니다.
원본, 정렬만 바꾼 버전, 분할 버전의 코드 배치와 결과 동등성을 각각 보존합니다. 성능 개선이 입력·측정 반복에서도 유지되는지 확인합니다.

Skylake-X PMU 설명의 DSB hit→miss 전환에서 µop 공급이 최대 6사이클 지연될 수 있다는 조건을 모든 x86의 고정 디코더 비용으로 쓰지 않습니다. 이벤트 지원 여부·계산법은 대상 CPU에서 확인하며 AMD에 Intel 이벤트 이름을 그대로 적용하지 않습니다.

이 글이 확인한 것과 측정하지 않은 것

공식 문서의 용량·변환 조건과 위 예제의 정수 계산을 대조했습니다. 실제 CPU의 캐시 내용, PMU 수치, 실행 시간 개선율은 측정하지 않았습니다. Vol. 1은 공식 검색에 노출된 해당 절을 대조했으며 PDF 전체를 읽은 것으로 기록하지 않습니다.

출발 자료는 Laurie Kirk의 게시물과 보존 원고입니다. 원본의 네 이미지는 다시 열지 않았으며 성능 결과 그래프로 취급하지 않습니다. 프로세스 관측 도구와 CPU 내부 병목의 해석도 별도 단계입니다.

English summary. Decoded-instruction caches are generation-specific. Loop fission requires preserved dependencies and may trade frontend pressure for worse data reuse or parallelism. The alias counterexample is a logic check, not a CPU benchmark.