⚡ CPU는 어떻게 그렇게 빠를까?

— 레지스터(Register) 완전 정복

핵심 요약: CPU가 연산할 때 매번 RAM에서 데이터를 가져오면 너무 느리다.
그래서 CPU 내부에 초고속 임시 저장 공간을 두었는데, 그것이 바로 레지스터(Register) 다.

1️⃣ 레지스터란?

레지스터는 CPU 칩 내부에 설계된 가장 빠른 소규모 저장 공간이다.

• 물리적 위치: CPU 칩 내부에 직접 설계
• 속도: L1 캐시보다도 수십 배 빠름
• 용량: CPU 비트 수(32bit / 64bit)에 맞는 워드(Word) 단위, 수십 개 수준

💡 왜 레지스터 수와 용량을 늘리지 않을까?
레지스터는 CPU 다이(Die) 위에 직접 새겨지는 회로다. 개수가 늘수록 칩 면적, 발열, 전력 소비가 기하급수적으로 증가한다. 그래서 "소수의 초고속" 전략을 유지한다.

2️⃣ 왜 레지스터가 필요한가? — 메모리 계층 구조

CPU 연산 속도와 RAM 접근 속도 사이에는 엄청난 격차가 있다.

CPU 연산:  1 나노초 (0.000000001초)
RAM 접근: 약 100 나노초 → CPU 입장에서 100배나 기다려야 함

이 병목을 해결하기 위해 계층형 저장 구조를 사용한다.

도서관 비유로 이해하기

3️⃣ 주요 레지스터의 종류

CPU 내부에는 역할에 따라 다양한 레지스터가 존재한다.

🔄 명령어 실행 사이클과 레지스터

CPU가 명령어 하나를 실행하는 과정에서 레지스터들이 어떻게 협력하는지 보자.

① PC → 다음 실행할 명령어 주소 확인
② MAR ← PC의 주소값 복사
③ RAM → MBR로 해당 주소의 명령어 로드
④ IR ← MBR의 명령어 저장
⑤ PC → 다음 주소로 증가 (PC++)
⑥ AC ← 연산 수행 후 결과 저장
⑦ 반복

4️⃣ Java 개발자 관점 — JVM과 레지스터

Java는 스택 기반(Stack-based) 가상 머신이라 개발자가 레지스터를 직접 건드리지 않는다.
그러나 JVM 내부에서 레지스터 개념은 핵심적으로 사용된다.

📌 JVM PC Register

Java의 모든 스레드는 고유한 PC Register를 가진다.

// 멀티스레드 환경에서 스레드 전환이 일어날 때
Thread A 실행 중 → PC: 0x0042 (현재 bytecode 위치)
    → 스레드 전환 (Context Switch)
Thread B 실행
    → 다시 Thread A로 복귀
Thread A PC: 0x0042 → 정확히 이어서 실행 ✅

PC Register가 없다면 스레드가 전환되었다가 돌아왔을 때 어디까지 실행했는지 알 수 없다.

⚡ JIT 컴파일러의 레지스터 최적화

Java 코드는 처음엔 바이트코드로 실행되지만, JIT(Just-In-Time) 컴파일러가 자주 실행되는 코드를 기계어로 변환할 때 핵심 최적화를 적용한다.

// 개발자가 작성한 코드
int sum = 0;
for (int i = 0; i < 1000000; i++) {
    sum += i;
}

JIT 컴파일러가 하는 일:
① sum, i 변수를 RAM이 아닌 CPU 레지스터에 직접 할당
② 루프 반복마다 RAM 접근 없이 레지스터 내에서 연산
③ 루프 종료 후 결과를 RAM에 한 번만 저장
→ 수십 배 성능 향상!

이것을 레지스터 할당(Register Allocation) 이라고 한다.
JVM이 "느리다"는 편견과 달리, JIT 최적화 이후엔 C에 근접한 성능이 나오는 이유가 여기에 있다.

5️⃣ 핵심 정리

레지스터 = CPU의 손바닥 위 메모지
         → 가장 가깝고, 가장 빠르고, 가장 작다