캐시 1화. 1초도 못 참아! 캐시 메모리가 태어난 이유

"CPU는 왜 이렇게 성질이 급할까?"

CPU는 엄청 빠릅니다. 진짜 말도 안 되게 빠릅니다. 그런데 문제는 이 빠른 CPU가 필요한 데이터를 바로바로 못 받는다는 거예요. 마치 배달음식 시킨 사람이 음식이 안 오자 직접 식당으로 달려가는 것처럼요. 🤯

그 이유는 메모리(RAM)가 CPU만큼 빠르지 않기 때문입니다. 메모리는 데이터를 담고 있지만, CPU 입장에서는 너무 느려요. 그래서 CPU가 기다리다 폭발하지 않도록 중간에 '임시 저장소' 같은 걸 둔 게 캐시(Cache)입니다.

메모리 계층의 상위 클래스, 캐시(Cache)

출처 : https://woozzang.tistory.com/155

캐시는 메모리 계층 구조 상 최상단 티어에 위치한 메모리입니다.

메인 메모리보다 훨씬 작고 가격이 매우 비싸며, 그만큼 속도가 빠른 것이 특징입니다.

10 클럭 사이클 미만의 접근 시간이 걸리는 캐쉬(Caches) 가 두번째인 등급에 위치한 것을 확인할 수 있습니다.

CPU와 메인메모리의 속도 간극을 줄여주는 완충제

캐시는 CPU 와 메인 메모리 사이의 속도 간극을 줄여주는 완충재이며, 따라서 버퍼라고 불리기도 합니다.
(이 속도 간극 때문에 병목현상이 발생합니다. 추가적으로 버퍼는 완충재라는 의미를 가지고 있음)

캐시에는 보통 가격이 비싸고 속도가 빠르지만 용량 대비 크기가 큰 SRAM 을 사용하고, 메인 메모리에는 가격이 싸고 속도가 느린 DRAM 을 사용합니다.

캐시 2화: 지역성(Locality) - 왜 캐시가 효과적인가?

캐시는 CPU 가까이에 두고, 자주 쓰는 데이터를 빠르게 전달하는 역할을 해요.

그런데, 자주 쓰는 데이터는 어떻게 알까요?

캐시의 작동원리 : 지역성(Locality)의 법칙

"미리 쓸만한 데이터를 메인 메모리에서 캐시에 옮겨놓자"

캐시 메모리를 관통하는 핵심 개념은 데이터 지역성 (Locality) 입니다. 캐시 메모리는 이 원리로 작동합니다.

1. 시간 지역성 (Temporal locality): 최근에 사용한 데이터를 또 사용할 가능성이 높다.
2. 공간 지역성 (Spatial locality): 지금 접근한 데이터 근처도 곧 사용할 가능성이 높다.
3. 순차적 지역성( Sequential Locality) : 비순차적 실행이 아닌 이상 명령어들이 메모리에 저장된 순서대로 실행되는 특성을 고려하여 다음 순서의 데이터가 곧 사용될 가능성이 높다.

예를 들어, 공간 지역성은 A[0], A[1] 로 구성되는 배열과 같이 참조된 데이터 근처의 데이터가 잠시후에 사용될 가능성이 높다는 것입니다.

반복문 돌릴 때 i, i+1, i+2 이런 식으로 접근하잖아요? 이걸 미리 예측해서 데이터를 캐시에 담아두는 겁니다.

결국 캐시는 이렇게 생각하면 돼요:

"CPU가 가장 아끼는 친구! 항상 옆에 붙어 다니는 비서 같은 존재"

캐시 3화. 메모리 배달 시스템: 캐시의 3단계 작전

"아니 캐시가 한 개만 있으면 안 돼요? 왜 자꾸 계층을 나누는 거예요?"

📦 속도와 용량의 딜레마, 그래서 캐시는 계층이 필요해요

그건 바로 속도 vs 용량의 균형 때문입니다.

CPU의 성능을 이야기할 때 "L1 캐시가 얼마냐", "L2는 몇 MB냐" 같은 얘기 들어보셨을 거예요. 캐시 메모리는 CPU 바로 옆에 있는 초고속 메모리로, 속도는 빠르지만 용량은 작고 가격은 비싸다는 특징이 있어요.

그래서 단 하나의 캐시만 두기보다는, 속도와 용량 사이의 균형을 잡기 위해 계층을 나눠서 구성합니다. 이것이 바로 L1, L2, L3 캐시 구조입니다.
여기서 'L'은 Level의 줄임말로, L1이 가장 빠르고, L3로 갈수록 느리지만 더 많은 데이터를 저장할 수 있어요.

• L1 캐시는 CPU 바로 옆에 있어서 제일 빠르지만, 너무 작아요.
• L2 캐시는 L1보단 느리지만, 조금 더 크고요.
• L3 캐시는 여러 CPU 코어가 공유하면서, 가장 크지만 제일 느립니다.

이 구조는 마치 도시 안의 배달 시스템과도 비슷해요:

캐시 계층	비유	속도	용량	위치
L1	내 책상 서랍	매우 빠름	매우 작음 (8~64KB)	CPU 내부
L2	집 복도에 있는 물품함	빠름	작음~중간 (64KB~4MB)	CPU 내부 or 외부
L3	지하 창고	느림	큼 (몇 MB 이상)	메인보드 또는 CPU 공유

이렇게 다단계로 캐시를 배치하면, 자주 쓰는 건 L1에, 그보다 덜 쓰는 건 L2, 그리고 큰 데이터는 L3에 저장해서 CPU의 속도를 최대한 유지할 수 있어요.

결국 이 구조의 목표는:

"CPU가 느린 메모리를 기다리는 시간을 최소화하기 위해, 자주 쓰는 데이터를 가까운 순서대로 나눠 보관하는 것"

🧠 L1 캐시는 ‘명령어’와 ‘데이터’가 따로?

특히 L1 캐시는 구조적으로도 특이해요. 명령어 캐시(I-Cache) 와 데이터 캐시(D-Cache) 가 분리되어 있는 경우가 많습니다.

• I-Cache (Instruction Cache): 공간 지역성이 높은 명령어를 저장
• D-Cache (Data Cache): 시간 지역성이 높은 데이터를 저장

L1 캐시 메모리는 CPU에 직접 데이터를 공급해 주기 때문에 빠른 접근 지연 시간(Access latency)이 매우 중요한데,

명령어는 보통 공간 지역성이 높고 데이터는 보통 시간 지역성이 높습니다.

그러므로 이 둘을 나누어 서로 다른 지역성을 이용할 수 있습니다.

이렇게 나누면 동시에 명령어와 데이터를 불러올 수 있어서 CPU의 파이프라이닝 성능이 향상됩니다.

L2부터는 보통 I/D 구분 없이 하나의 큰 캐시로 구성되며, L1에서 데이터를 못 찾을 때 L2를, 그다음엔 L3를 탐색하는 방식이에요.

🧪 실제 구조 예시: ARM Cortex-A72

아래는 ARM Cortex-A72의 구조예시로, 각 캐시의 위치와 역할을 시각적으로 보여줍니다.

• 각 프로세서는 자신만의 L1 캐시를 가지고 있고
• 모든 프로세서가 L2 캐시를 공유합니다
• 명령어 캐시와 데이터 캐시가 분리되어 있음도 확인할 수 있죠.

💡 캐시는 어디에 있을까? 위치에 따라 달라지는 역할

캐시 메모리는 단순히 “빠른 저장 공간” 그 이상입니다. 어디에 위치하느냐에 따라 접근 속도와 용도가 달라지고, CPU 전체 성능에도 영향을 줍니다.

✅ L1 캐시: CPU 안에 꼭 붙어 있는 고속 서랍

L1 캐시는 CPU 코어 내부에 내장되어 있어요.
CPU가 무언가를 계산할 때 제일 먼저 접근하는 캐시이기 때문에, 속도가 매우 중요합니다.

• 위치: 각 CPU 코어 안
• 속도: 가장 빠름 (CPU 클럭에 거의 맞먹는 속도)
• 용량: 8KB~64KB 정도
• 특징: 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)로 분리됨

L1 캐시는 작지만 가장 빠른 저장 공간이라, 최근에 사용된 명령어와 데이터를 따로 저장하고, CPU의 파이프라인 효율을 높여줍니다.

✅ L2 캐시: 코어 옆에 살짝 붙은 중간창고

L2 캐시는 L1보다 약간 느리지만 더 많은 데이터를 담을 수 있어요. 예전에는 CPU 외부(보드 위 칩)에 있었지만, 요즘은 대부분 CPU 내부에 내장됩니다.

• 위치: 대부분은 CPU 코어 안에 있지만, 공유 방식(L2를 여러 코어가 함께 쓰는 구조)도 존재
• 속도: L1보단 느리지만 RAM보단 빠름
• 용량: 64KB~4MB 정도
• 특징: L1에서 못 찾은 데이터를 여기서 찾음

L2 캐시는 L1의 백업 역할을 하며, 요즘 CPU에선 대부분 코어마다 L2를 따로 붙이거나, 두세 개 코어가 공유하는 구조도 많아요.

✅ L3 캐시: 모두가 함께 쓰는 공용 창고

L3 캐시는 예전엔 메인보드나 칩셋에 외장 형태로 붙는 경우도 있었지만, 최근 인텔의 i5, i7 시리즈처럼 고성능 CPU는 L3도 CPU 안에 내장되어 있어요. 다만, L3는 각 코어가 공유해서 쓰는 구조입니다.

• 위치: CPU 칩 내부, 하지만 코어들과 공유하는 구조
• 속도: L2보다 느림
• 용량: 수 MB~수십 MB (예: i7에는 8MB 이상)
• 특징: 여러 코어가 데이터를 함께 빠르게 접근 가능하게 함

여러 코어가 같은 데이터를 공유해야 할 때, L3 캐시가 그 중재자 역할을 해줍니다. 공유 메모리 접근 시간을 줄이기 때문에, 멀티코어 환경에서 성능 향상에 기여해요.

최근 i5, i7의 L3 위치가 바뀌었다?

✅ L3 캐시가 CPU 안에 있으면 뭐가 좋을까?

예전에는 L3 캐시가 CPU 외부, 즉 메인보드나 다른 칩셋에 따로 붙어 있는 경우도 있었어요. 하지만 최근 인텔 i5, i7 같은 고성능 CPU는 L3 캐시도 CPU 내부에 통합해버렸습니다.

그렇게 하면 뭐가 좋냐면요:

1) 🏃‍♂️ 접근 속도가 더 빨라져요

• 외부 칩에 있는 캐시는 데이터를 가져오려면 CPU 밖으로 나갔다가 들어와야 하니까 시간이 걸렸어요.
• 하지만 내부에 L3가 있으면 데이터 왕복 시간(latency)이 훨씬 줄어들어요.

결과: 멀티코어 작업에서 데이터 공유가 빠르게 이뤄져서 전반적인 응답성과 속도가 좋아집니다!

2) 🧠 코어 간 협업이 훨씬 수월해져요

• L3는 여러 코어가 공유해서 사용하는 캐시잖아요?
• L3가 CPU 안에 있으면, 코어 간에 데이터를 주고받는 시간도 빨라지고, 캐시 일관성 유지도 더 쉬워져요.

결과: 멀티코어 병렬 작업이나 멀티스레드 프로그램 실행 시 성능이 향상됩니다.

3) 🔋 전력 소모도 줄어들어요

• CPU 외부로 왔다 갔다 하려면 전기 신호를 멀리 보내야 해서 전력 소비가 더 큽니다.
• 반대로, 내부 통합된 구조는 짧은 경로로 빠르게 통신하므로 전력 효율이 높아져요.

4) 💻 더 작고 효율적인 설계가 가능해요

• L3 캐시를 CPU 안에 넣으면, 설계가 간결해지고 회로 복잡성도 줄어듭니다.
• 결과적으로 발열 관리도 쉬워지고, 칩 면적 대비 성능 밀도도 높아져요.

"L3 캐시가 CPU 안에 있으면 더 빠르고, 전력도 적게 들고, 멀티코어 성능까지 좋아집니다!"

📌 캐시 위치가 성능에 미치는 영향은?

캐시 종류	위치	접근 속도	공유 여부	특징
L1	각 코어 내부	매우 빠름	X (개별)	명령어/데이터 분리, 초고속 접근
L2	코어 내부 또는 코어당 1개	빠름	보통 X	L1의 백업, 중간 수준 캐시
L3	CPU 내부, 모든 코어 공유	느림	O	다중 코어 협업에 최적화

• L1과 L2는 직접적인 성능에 영향을 줍니다. 클럭당 명령어 실행 효율이 여기서 갈려요.
• L3는 멀티코어 성능을 높이지만, L1/L2ほど 영향은 크지 않아서 벤치마크엔 잡혀도 체감은 약한 편이에요.
• 최신 CPU는 모든 캐시가 CPU 안에 내장되기 때문에, 데이터 왕복 시간(latency)이 더욱 줄고 전체 성능이 개선됩니다.

예: “CPU → L1 → (없으면) L2 → (없으면) L3 → (없으면) 메인 메모리 → 디스크”

어 그런데? L1, L2, L3가 여러 개가 있다고요?

L1, L2, L3는 네트워크 계층, 캐시 메모리, 이륜차 등에서 사용되는 용어로, 각각 다른 의미가 있습니다.

L1, L2, L3 스위치

네트워크의 계층에 따라 구분되는 스위치로, L1은 허브, L2는 스위칭 허브, L3는 라우터라고도 합니다.

테온의 기술이야기(L1 스위치)에 따르면:
L1 스위치는 물리 계층(Layer1)으로 모든 데이터를 전달합니다.
L2 스위치는 데이터링크 계층(Layer2)를 통해 MAC 주소를 보고 데이터를 전달합니다.
L3 스위치는 네트워크 계층(Layer3)를 통해 IP 주소를 보고 데이터를 전달합니다.

L1, L2, L3 캐시 메모리

• CPU와 가까운 순서대로 계층을 구성하는 캐시 메모리로, L1은 코어와 가장 가까운 캐시 메모리, L2는 그 다음 가까운 캐시 메모리, L3는 그 다음 가까운 캐시 메모리입니다.

💡 캐시가 크면 무조건 좋은 걸까요?

캐시 용량이 크면 성능에 긍정적인 영향을 주는 건 맞지만, 사용자가 체감할 수 있는 수준은 아닐 수도 있어요.
실제로는 벤치마크 툴에서 수치로 나타나는 정도이며, 일반적인 사용 환경에서는 큰 차이를 느끼기 어렵습니다.

결국, CPU를 선택할 때 캐시는 보조적인 판단 기준이 될 수는 있지만, 절대적인 기준은 아니라는 점을 기억해두면 좋아요.

캐시 4화. 캐시는 어떻게 우리 데이터를 찾아낼까?

캐시는 마법처럼 데이터를 기억하는 게 아닙니다. 꽤 체계적인 방식으로 동작해요. 그게 바로 매핑(Mapping) 기법입니다.

출처 : https://ssoonidev.tistory.com/35

cpu가 메모리 주소를 사용하여 메모리로 데이터를 받으려고 하지만, cpu가 쓰는 가상 메모리 주소로 메모리 입장에서는 외계어 입니다.

따라서 중간에 메모리 관리 장치(MMU)가 가운데에서 번역하여 메모리가 알아 먹을 수 있는 물리 주소로 변환해줘요!

1) 직접 매핑 (Direct Mapping)

• RAM 주소의 일부 비트를 사용해서 캐시 블록 위치를 정함
• 단순하지만 충돌이 자주 남

2) 완전 연관 매핑 (Fully Associative Mapping)

• 어떤 캐시 블록에든 저장 가능
• 유연하지만 느리고 복잡함
• 적중률이 높다는 장점

3) 집합 연관 매핑 (Set-Associative Mapping)

• 캐시를 여러 개의 '집합'으로 나눔
• 각 집합에 여러 블록이 있어서 유연성과 효율의 균형을 맞춤

태그(Tag)와 인덱스(Index)

• 캐시가 어떤 데이터가 어떤 주소에서 왔는지 기억하려면 '태그'를 붙여둡니다
• CPU가 주소를 요청하면, 먼저 인덱스를 보고, 그 위치에 있는 태그를 비교해 일치하면 히트(Hit), 아니면 미스(Miss)

이걸 마치 우체국 사서함 찾기처럼 생각하면 돼요:

• 인덱스는 사서함 번호
• 태그는 받는 사람 이름
• 데이터는 편지 내용

결국 이걸 통해서 우리는 이렇게 말할 수 있어요:

"캐시는 주소를 태그와 인덱스로 분해해서, '이 편지가 너한테 맞는지'를 판단하는 스마트한 우체통이다."

좋아요! 두 개의 글을 합치면 캐시의 구조와 주소 매핑 원리까지 흐름 있게, 쉽게 설명할 수 있습니다. 다음과 같은 형식으로 정리해볼게요.

소제목은 시리즈 형식에 맞춰서:

🧠 캐시 5화: 캐시의 구조 – 블록, 라인, 세트란 무엇인가?

이번 화에서는 캐시가 실제로 어떻게 생겼는지를 파헤쳐 봅니다.
컴퓨터 속 캐시도 결국은 정돈된 칸칸이 수납장 같은 구조니까요!

1. 캐시는 어떤 구조로 되어 있을까요?

캐시는 기본적으로 '캐시 라인(Line)' 단위로 구성되어 있어요.

각 캐시 라인에는 메인 메모리에서 가져온 '블록(Block)'이 들어가고, 이와 함께 유효 비트(Valid bit)와 태그(Tag) 정보도 함께 저장됩니다.

• 블록(Block): 메모리에서 가져온 데이터 덩어리 (예: 64바이트)
• 캐시 라인(Line): 블록 하나를 저장하는 캐시의 칸
• 태그(Tag): 동일한 세트에 들어올 수 있는 여러 블록들을 구별하기 위한 식별자
• 유효 비트(Valid bit): 해당 라인이 유효한 데이터를 담고 있는지 여부

2. 세트(Set)란 무엇일까?

캐시 라인들은 '세트(Set)'라는 단위로 묶여 있어요.

• 하나의 세트는 여러 개의 라인(칸)을 가질 수 있어요.
• 예: 4-웨이 세트 어소시에이티브 캐시 → 세트당 4개의 라인

이때 CPU가 참조하는 메모리 주소는 특정한 세트 하나에만 매핑되고, 그 세트 안의 라인 중 하나에 저장됩니다.
즉,
세트 → 라인 → 블록
이라는 구조로 기억하면 돼요.

3. 캐시 구조 시각화

캐시가 전체적으로 S개의 세트로 구성되어 있고,
각 세트에는 E개의 캐시 라인이 있으며,
각 라인은 하나의 메모리 블록을 저장해요.

따라서 총 캐시 크기는:
📦 S × E × B 바이트 (B는 블록의 크기)로 계산할 수 있어요.

4. 캐시의 구조는 어떻게 나뉘나요? 매핑 방식

세트당 라인의 수(E)에 따라 캐시의 형태도 달라집니다.

캐시 구조	설명
Direct-mapped Cache	세트당 라인이 1개 (E = 1)
→ 블록은 특정한 한 자리에만 들어갈 수 있어요
Set-associative Cache	세트당 라인이 여러 개 (E > 1)
→ 블록은 해당 세트 안의 여러 자리 중 한 곳에 들어갈 수 있어요
Fully-associative Cache	모든 블록이 모든 라인에 들어갈 수 있어요
→ E = 전체 라인 수

이제 캐시 구조를 알았어요. 메모리 블록이 어떻게 캐시에 들어가는지 알아보면, 바로 "매핑 방식" 이에요.

1) 직접 매핑 (Direct Mapped Cache)

• 아주 단순한 방식.
• 메모리 블록은 캐시의 '딱 하나의 라인'에만 들어갈 수 있어.
• 예를 들어 블록 번호 10은 캐시의 (10 mod 캐시 크기)번 라인에만 들어감.

장점: 빠르고 구현이 간단함.
단점: 충돌(Conflict)이 많이 발생할 수 있음.

2) 완전 연관 매핑 (Fully Associative Mapping)

• 아무 블록이든 캐시의 '어떤 라인에든' 들어갈 수 있음.
• 어디 들어가든 상관없기 때문에 유연함.

장점: 충돌 없음.
단점: 어떤 블록이 어디 있는지 찾으려면 모든 라인을 다 검사해야 하니 느림 (비쌈).

3) 세트 연관 매핑 (Set-Associative Mapping)

• 직접 매핑과 완전 연관의 중간 타입.
• 메모리 블록은 특정 세트에 매핑되고, 그 세트 내 어떤 라인에든 들어갈 수 있음.
• 예: 4-way 세트 연관이면 세트 하나에 라인 4개.

장점: 적당한 유연성과 속도.
단점: 구현 복잡도는 좀 있음.

4. 비교 표

방식	위치 결정	충돌 가능성	속도	유연성
직접 매핑	고정된 라인	높음	빠름	낮음
완전 연관	아무 라인	없음	느림	높음
세트 연관	세트 내 선택	중간	중간	중간

5.캐시 정책 ( 알고리즘 )

1) 캐시 정책이 중요한 이유

캐시 메모리 성능 향상을 위해 적절한 캐시 정책을 취해야 레이턴시를 줄이면서 대역폭을 끌어올릴 수 있습니다.

• 캐시 메모리는 CPU가 데이터를 빠르게 접근하기 위해 사용하는 고속 메모리입니다.
• 성능을 좌우하는 두 가지 지표:
  • 레이턴시 (Latency): 데이터를 요청하고 받기까지의 지연 시간, 입출력에 걸리는 시간
  • 대역폭 (Bandwidth): 단위 시간당 처리 가능한 데이터 양
• 적절한 캐시 정책을 세우면 이 두 가지를 모두 향상시킬 수 있습니다.

2) 왜 캐시를 'Set'으로 나누는가?

• 메모리 주소를 그대로 사용하면, 캐시 내에서 선형 탐색해야 할 수도 있음 → O(N × E)
• 그래서 메모리 블록을 정해진 위치(Set)에만 들어갈 수 있게 제한합니다.
  • 이걸 Direct-mapped Cache 라고 해요.

메인 메모리의 각 블록은 캐시 메모리의 특정 집합에만 들어갈 수 있도록 되어 있습니다.

예를 들면 메인 메모리의 2번째 블록 (00001) → 캐시의 2번째 집합(Set 2 : 001)에만 들어갈 수 있어요

왜 그런걸까요?

CPU 가 참조할 메모리 주소를 캐시에 전달할 때, 캐시는 해당 메모리 블럭이 캐시에 있는지 탐색해야 합니다.

이 때 메모리 블럭이 마구잡이로 저장되어 있다면 선형으로 탐색해야 할 것입니다. = O(N x E)
그런데 위와 같이 해시 방식으로 저장되어있으면 O(E) 로 존재 여부를 확인할 수 있습니다.

이때 E는 한정된 숫자이므로 O(1)에 수렴합니다.
덕분에 탐색은 Set 내에서만 하면 됨 → O(E), 거의 O(1) 수준!

3) 주소 구성: 메모리 주소는 이렇게 생겼어요

주소 m = t (태그) + s (세트 인덱스) + b (블록 오프셋)

이름	역할
t (Tag)	같은 Set 안에서 어떤 블록인지 구별
s (Set index)	어느 Set에 들어갈지를 결정
b (Block offset)	블록 안에서 몇 바이트 떨어졌는지 (블록 내 위치)

4) 수식으로 보는 구조 정리

• 메모리 총 크기: M = 2^m 바이트 (m비트 주소 사용)
• 블록 크기: B = 2^b 바이트
• Set 수: S = 2^s 개
• 총 블록 수: 2^m / 2^b = 2^(m-b)

→ 따라서, 주소 m비트를 다음과 같이 나눌 수 있어요:

구분	비트 수
Tag (t)	m - b - s
Set Index (s)	s
Block Offset (b)	b

💡 메모리 주소는 어떻게 캐시를 찾을까?

캐시가 하는 일 복습!

캐시는 “내가 방금 썼던 데이터”를 아주 빠르게 다시 꺼내 쓰기 위해 만들어졌어요.
그런데 CPU 입장에서는 이렇게 물어봐야 해요:

"내가 찾고 싶은 이 메모리 주소가 지금 캐시에 있니?"

이 질문에 빠르게 답하려면, 그 주소가 들어갈 '자리(위치)'가 정해져 있어야 해요.
그래야 O(1)에 가까운 속도로 찾을 수 있겠죠!

주소를 잘게 쪼개서 세트(Set)를 찾고, 구별(Tag)하고, 안쪽 위치(Offset)를 찾는다!

CPU는 메모리 주소를 사용할 때, 그 주소를 세 부분으로 쪼개서 캐시에 전달해요.

[ Tag | Set Index | Block Offset ]
   ↑         ↑           ↑
   |         |           └─ 블록 안에서 몇 번째 바이트인지
   |         └───────────── 어느 세트(Set)에 들어갈지
   └──────────────────────── 세트 안에서 어떤 블록인지

도시 비유로 이해해보자 🏙️

캐시를 아파트 단지라고 생각해볼게요:

• Set Index = 아파트 동 (어느 건물에 들어갈지)
• Tag = 같은 동의 다른 세대 중 어떤 세대인지 (집 번호)
• Offset = 집 안에서 소파냐, 책상이냐 같은 위치 (몇 번째 바이트냐)

주소 = “아파트 101동 302호, 소파 옆에 있는 책”

CPU는 이 주소를 보고 바로 101동(세트)에 들어가서, 거기서 302호(Tag)에 해당하는 데이터를 찾고, 그 안에서 소파 옆(Offset)의 값을 꺼내는 거예요.

숫자로 해볼까?

예:

• 32비트 주소 공간 (2³² 바이트 주소 가능)
• 블록 크기: 64바이트 → Block Offset = log₂(64) = 6비트
• 세트 수: 256개 → Set Index = log₂(256) = 8비트

그러면:

• 전체 주소 32비트 = Tag + Set Index + Offset
• Offset(b) = 6비트
• Set Index(s) = 8비트
• Tag(t) = 32 - 6 - 8 = 18비트

즉, CPU가 보는 주소는 이렇게 나눠져 있어요:

[  Tag (18비트)  |  Set (8비트)  |  Offset (6비트)  ]

왜 이렇게 나누면 좋은가요?

이렇게 하면 CPU는 아주 빠르게 캐시에서 데이터를 찾을 수 있어요:

1. Set Index를 보고, 해당 세트(예: 101동)로 바로 감
2. 세트 안의 라인들을 돌면서 Tag를 비교
3. 일치하면 그 라인의 Block을 가져오고, Offset으로 그 안의 정확한 위치를 찝어서 꺼냄!

덕분에 O(1)에 가까운 속도로 탐색이 가능해요.
그냥 무작정 다 뒤지는 것보다 훨씬 빠르죠!

6. 요약 📝

용어	설명
블록	메인 메모리에서 가져온 데이터 조각
라인	블록 하나를 저장할 수 있는 캐시의 칸
세트	여러 라인을 묶은 그룹
태그(Tag)	동일 세트 내 블록을 식별하는 고유 정보
Valid Bit	해당 라인이 유효한지 나타내는 플래그
Set Index	어느 세트에 들어갈지를 정함
Block Offset	블록 안에서의 위치 (몇 번째 바이트?)

캐시 6화 : 캐시 메모리의 동작 흐름부터 교체 정책, 쓰기 정책, 성능 요인까지

1) 캐시 접근 과정: 메모리 주소가 캐시에 도달하면?

m비트 주소 = [Tag (t) + Set Index (s) + Block Offset (b)]

CPU는 참조하고 싶은 메모리 주소를 캐시에 전달합니다. 그때 캐시는 이렇게 동작해요:

✅ Step 1. Set Index(s) 확인 → 해당 세트로 이동

• 캐시는 전체 메모리를 Set 단위로 나누어 관리
• s비트를 사용해 어떤 Set을 참조할지 결정

✅ Step 2. Tag(t) 비교 → 그 Set 안에서 일치하는 Tag 찾기

• Set 안에는 여러 개의 블록(Tag)이 있음
• t를 비교해 일치하는 블록이 있는지 확인

✅ Step 3. Valid Bit 확인

• 그 블록이 실제로 유효한 데이터인지 검사

💥 결과

• 세 조건이 모두 맞으면: 캐시 히트(HIT)
• 하나라도 불일치하면: 캐시 미스(MISS)

2) 캐시 히트 vs 캐시 미스

상황	설명
캐시 히트	요청한 데이터가 캐시에 존재 → Block Offset(b)를 이용해 데이터 반환
캐시 미스	데이터가 없음 → 메인 메모리에서 해당 블록 전체를 가져와 Set에 저장 후 데이터 반환

📌 블록 단위로 가져온다는 점! 잊지 마세요.
1블록 = 1캐시라인 = 바이트 여러 개 묶음

3) 캐시 교체 정책 (Replacement Policy)

Set에 이미 데이터가 꽉 차있다면, 어떤 블록을 제거하고 새 데이터를 넣을까?

대표적인 알고리즘:

알고리즘	설명
Random	무작위 블록 제거. 구현은 쉬움
FIFO (선입선출)	먼저 들어온 블록부터 제거
LRU (Least Recently Used)	가장 오랫동안 사용되지 않은 블록 제거
LFU (Least Frequently Used)	가장 사용 횟수가 적은 블록 제거

4) 캐시 쓰기 정책 (Write Policy)

💡 캐시에 데이터를 수정할 때 어떻게 할까?

① 캐시 히트일 때

정책	설명	장점	단점
Write-through	캐시와 메모리를 동시에 수정	일관성 보장	버스 병목 가능
Write-back	캐시만 수정, 나중에 메모리 반영	빠름	일관성 유지 어려움, VI bit 필요

→ Write-back은 VI (Valid-Invalid) 비트로 “수정된 상태”를 표시해둬야 함

② 캐시 미스일 때

정책	설명	특징
Write-allocate (Fetch on Write)	메모리에서 블록을 가져와 캐시에 저장 후 수정	자주 쓰는 데이터 캐시에 보관
No-write allocate (Write-around)	메모리만 수정하고 캐시는 건드리지 않음	쓰기만 일어날 때 유리

5) 캐시 성능 요소 요약

용어	정의
Hit Ratio	Hit / (Hit + Miss)
Miss Ratio	1 - Hit Ratio
Hit Time	캐시에서 데이터를 가져오는 시간
Miss Penalty	메모리에서 블록을 가져오는 데 걸리는 시간
총 레이턴시	Miss일 경우: Hit Time + Miss Penalty

6) 캐시 구성 요소가 성능에 미치는 영향

✅ Cache Size

• 커질수록 Miss Rate 감소
• 시간적 지역성(Time Locality)을 더 잘 잡음

✅ Block Size

• 작을수록 시간적 지역성 확보
• 클수록 공간적 지역성 확보
• 중간값에서 최적화됨

✅ N-Way Set Associativity (E)

N값	장단점
작을수록 (1-Way = Direct Mapped)	빠름 (Hit Time ↓), 충돌 ↑ (Conflict Miss ↑)
클수록 (Full Associative)	충돌 ↓, 탐색 느림 (Hit Time ↑)

→ 상황에 따라 Hit Time vs Miss Rate의 트레이드오프 조절

캐시메모리와 레디스

"캐시 메모리랑 레디스가 무슨 관련이 있어요?"라고 묻는 분들이 많은데,
사실 이 둘은 캐시(cache)라는 같은 철학을 바탕으로 만들어졌어요.
하지만 사용하는 환경과 목적이 달라요.

🧠 먼저 개념부터 비교해볼게요

항목	캐시 메모리(Cache Memory)	레디스(Redis)
어디서 사용?	컴퓨터 내부 (CPU와 메모리 사이)	서버 외부 (애플리케이션과 데이터베이스 사이)
역할	느린 메모리 대신 빠르게 데이터를 제공	느린 DB 대신 빠르게 데이터를 제공
저장 위치	하드웨어(CPU 칩 안쪽에 내장)	소프트웨어(메모리 기반 데이터 저장소)
저장 방식	메모리 주소 기반 자동 저장	키-값(Key-Value) 쌍으로 명시적 저장
사용 주체	CPU	웹서버, 애플리케이션 서버
데이터 휘발성	전원 끄면 사라짐	기본적으로 휘발성이지만, 영속화 설정 가능
구현 방식	하드웨어 레벨, 매우 저수준	소프트웨어 레벨, 고수준 API 제공

🎯 핵심 공통점: “자주 쓰는 데이터를 가까이에 두자!”

• 캐시 메모리는 CPU가 자주 쓰는 데이터를 RAM 대신 가까운 곳(L1/L2)에 둡니다.
• 레디스는 웹 서비스가 자주 요청하는 데이터를 DB 대신 메모리에 둡니다.

즉, 둘 다 ‘시간 절약’을 위해 데이터를 더 가까이 두는 전략이에요!

📦 예시로 이해해볼게요

상황: 인기 쇼핑몰에서 상품 상세 페이지 요청

• 클라이언트가 특정 상품 페이지를 요청하면,
  보통 서버는 DB에서 데이터를 꺼내와 화면을 구성하죠.

근데 이게 자주 조회되는 상품이라면?
매번 DB 다녀오는 건 비효율적이겠죠?

✅ 그래서 등장하는 캐시 전략:

1. 레디스 캐시 사용

• 서버는 상품 정보를 미리 레디스에 넣어둠 (예: product:1234)
• 사용자가 요청하면, DB 말고 레디스에서 빠르게 가져와서 응답

2. 하드웨어 캐시라면?

• 이건 그보다 더 하드웨어 수준에서 동작해요.
• CPU가 메모리 접근할 때, 이전에 본 주소면 캐시 메모리에서 빠르게 꺼냄

💡 공통 철학은 이거예요:

"느린 곳에서 자주 꺼내 쓰는 데이터는, 빠른 곳에 따로 복사해두자!"

🚧 차이점은?

차이점	캐시 메모리	레디스
계층 위치	CPU ↔ RAM	서버 ↔ DB
저장 대상	명령어, 데이터 블록	JSON, 문자열, 해시, 리스트 등
사용 목적	CPU 연산 속도 향상	웹서비스 응답 속도 향상
작동 방식	자동 (하드웨어 수준)	수동 또는 라이브러리로 설정 (소프트웨어 수준)
크기	수십 KB~수 MB	수 GB~수십 GB (RAM 한도까지)
제어 권한	거의 없음	완전 사용자 제어 가능 (TTL, 삭제, 업데이트 등)

🔥 쉽게 비유하면?

• 캐시 메모리는 “내 책상 서랍”
  → CPU가 자주 보는 자료를 바로 꺼내 쓰려고 넣어둔 칸

• 레디스는 “회사 복사본 폴더”
  → 사람들이 자주 찾는 문서를 미리 복사해두고, 원본(DB)을 건드리지 않게 함

✅ 요약 한 줄

캐시 메모리는 CPU를 위한 하드웨어 캐시,
레디스는 서버/애플리케이션을 위한 소프트웨어 캐시입니다.

둘 다 "빠른 응답"을 위해 비슷한 철학을 공유하지만,
쓰는 위치, 주체, 구현 방식이 다를 뿐이에요!

🚀 ARM, 어떻게 세계를 정복했을까? - M1

1) ARM은 CPU를 직접 만들지 않는 CPU 회사

ARM은 CPU를 직접 만들지 않아요. 대신, 가볍고 효율적인 CPU 설계도를 만들어서 다른 반도체 회사들에게 라이선스(설계 사용권) 형태로 팔죠.

• 회사 이름은 ARM (Advanced RISC Machine)
• RISC란? Reduced Instruction Set Computer
  → 적은 수의 단순한 명령어로 효율을 높이는 구조!

이런 단순하고 가벼운 설계는 전력 소모를 줄이면서도 빠른 연산이 가능하게 만들어줘요. 그래서 스마트폰, IoT 기기, 디지털카메라 등 저전력이 중요한 기기들에 딱이에요!

2) ARM의 탄생은 BBC 교육 방송에서부터

1980년대, 영국은 '국민에게 컴퓨터를 알리자!'라는 BBC 컴퓨터 리터러시 프로젝트를 시작해요.
BBC는 교육 방송에 쓸 컴퓨터를 만들어달라고 에이콘(Acorn) 컴퓨터사에 요청했죠.

그 결과 만들어진 게 바로 BBC 마이크로(BBC Micro).
당시로선 고성능이었고, 영국 교육 시장을 평정했어요!

하지만 에이콘은 더 강력한 CPU가 필요하다고 판단, 인텔에 협조를 요청했지만 거절당하고…

결국 “그럼 우리가 만들자!” 하고 자체 CPU 개발에 뛰어듭니다.

이렇게 탄생한 게 바로 ARM = Acorn RISC Machine이에요!

3) ARM의 첫 작품: ARM2 → 인텔을 압도하다

• 첫 ARM CPU인 ARM2 (1987) 는 단 2만 7천 개의 트랜지스터로 구성됐지만,
  인텔의 80286보다 빠른 성능을 보여줘요!

• 이 기술력 덕분에 애플도 주목하게 되고,
  에이콘은 ARM 부서를 분사시켜 지금의 ARM Holdings가 됩니다.

4) 애플, 닌텐도, 스마트폰까지 – ARM의 확장

• 애플 뉴튼에 ARM CPU를 사용했고,
• 이후 아이팟, 닌텐도 DS, 초대 아이폰까지 ARM이 들어가게 돼요!

전력 소모가 적고, 발열도 낮으면서도 충분히 빠르기 때문에
모바일 기기에서는 ARM을 따라올 수 있는 아키텍처가 없었죠.

5) ARM 아키텍처, 이제는 노트북(Mac)도 접수!

2020년, 애플이 발표한 M1 칩은 ARM 기반 CPU에요.

• 이전까지는 맥북에 인텔 CPU를 썼지만,
  M1부터는 애플이 직접 설계한 ARM 기반 SoC를 사용!

• 저전력임에도 불구하고 성능이 엄청나서,
  데스크탑 분야에서도 ARM이 경쟁력을 입증했어요.

🧠 요약 정리

구분	내용
ARM이란?	저전력 RISC 기반 CPU 설계 회사 (직접 생산 X)
설계 철학	단순한 명령어 세트 → 빠르고 전력 효율 높음
시작은?	1980년대 영국, BBC 교육용 컴퓨터에서 탄생
유명 제품	애플 M1, 아이폰, 닌텐도 DS, 스마트폰 대부분
장점	전력 효율, 저발열, 모바일/IoT에 최적화
현재	노트북(Mac), 서버, 슈퍼컴퓨터까지 확장 중!

---

“단순한 설계로, 세상을 바꾼 CPU”
이게 바로 ARM의 이야기입니다 😎

🍎 Apple Silicon 캐시 구조 정리

출처 : https://woozzang.tistory.com/155

1. 🔍 배경: 왜 Apple은 칩 정보를 숨길까?

Apple은 자사가 설계한 칩을 오직 자사 기기에서만 사용하기 때문에,
경쟁사처럼 세부 구조를 투명하게 공개하지 않습니다.
그래서 설계도 자체는 알 수 없지만, 각 파트의 스펙 수준은 다음과 같이 알려져 있습니다.

2. ⚙️ Apple Silicon 스펙 요약

항목	Firestorm (빅 코어)	Icestorm (리틀 코어)
코어 수	2코어	4코어
클럭	2.99GHz	1.82GHz
L1 명령어 캐시	192KB	128KB
L1 데이터 캐시	128KB	64KB
L2 캐시	8MB	4MB
System Cache (공통)	16MB

3. 💡 캐시 구조의 특징

✅ Firestorm (빅 코어)

• 192KB L1 I-Cache (명령어 캐시)
  → 일반적인 ARM 빅 코어보다 3배, x86 아키텍처보다 6배 큼
  → 그런데도 액세스 레이턴시는 단 3사이클!

  • 비교:
    • AMD 32KB → 4 사이클
    • Intel Sunny Cove 48KB → 5 사이클

• 128KB L1 D-Cache (데이터 캐시)
  → 크기 자체도 매우 큼

• 8MB L2 캐시
  → 코어 단독 or 공유 여부는 미공개지만, L2도 상당히 넉넉함

✅ Icestorm (리틀 코어)

• 128KB L1 I-Cache
  → 심지어 이 리틀 코어조차도 일반 빅 코어보다 큰 명령어 캐시를 가짐

• 64KB L1 D-Cache

• 4MB L2 캐시

🧠 "사이클 수"란 무엇인가요?

CPU는 내부에서 모든 동작을 클럭 사이클(clock cycle) 단위로 처리합니다.
쉽게 말하면, “틱톡 틱톡” 하는 시계처럼 동작하는 CPU의 박자라고 생각하면 돼요.

• 1 사이클 = CPU가 명령어 1단계를 수행할 수 있는 최소 단위 시간
• Access Latency = N 사이클
  → 어떤 데이터(예: 캐시, 메모리)를 가져오는데 N번의 틱이 걸린다는 뜻이에요.

📉 사이클이 적다는 건 어떤 의미?

예를 들어,

• L1 캐시 액세스 시간이 3사이클이면 → 데이터 읽는 데 3틱 걸림
• 5사이클이면 → 5틱이나 기다려야 하죠!

CPU 입장에서는 매 초마다 수십억 번(=GHz 단위) 연산을 하는데,
이렇게 1~2 사이클만 차이나도 전체 연산 속도에 상당한 영향을 줘요.

✅ 사이클이 작다 → 더 빠르게 데이터를 꺼내올 수 있다 → 성능에 더 유리

⚖️ 그런데 왜 모두가 작은 사이클을 못 쓰나요?

캐시 사이클 수를 줄이는 건 단순히 “빠르게 해주세요~” 한다고 되는 게 아닙니다. 기술적 제약이 있어요:

사이클 줄이는 게 힘든 이유
캐시 크기가 커질수록 → 데이터를 더 많이 저장해야 해서 → 탐색 시간 증가
작고 빠르게 만들려면 → 회로 복잡도가 증가 + 전력 소모 증가
전력, 발열, 설계 복잡도 등 고려해야 할 것이 많음

그래서 대부분은

• 작고 빠른 L1 캐시는 32KB~64KB, 4~5사이클
• 애플은 여기에 극한의 회로 설계 + 트랜지스터 여유를 쏟아부어
  → 192KB인데도 불구하고 3사이클을 달성한 거예요.

🔥 정리: 사이클 수, 작을수록 좋을까?

비교 항목	설명
✅ 낮은 사이클	빠른 응답 속도, 성능 유리
❌ 높은 사이클	느림, 파이프라인 stall 가능성
⚠️ Trade-off	낮추려면 캐시 크기, 전력, 설계 난이도 ↑

🔎 요약 한 줄:
캐시 접근 사이클 수는 작을수록 빠르고 좋지만, 줄이기 어려운 기술의 정수예요.
Apple Silicon이 대단한 이유도, 엄청 큰 캐시 용량을 엄청 빠른 속도(3사이클)로 운영한다는 점이에요!

4. 🧠 시스템 캐시 (System Cache)?

• 16MB System Cache는 L3 캐시 또는 SoC 레벨 공유 캐시로 추정
• 코어 간 공유 또는 GPU/메모리 컨트롤러와 연결된 통합 캐시일 가능성 있음
• 구체적인 구조는 Apple이 공식적으로 공개하지 않음

5. 🧾 한 줄 요약

Apple Silicon의 캐시는 “무지막지하게 크고 빠르다”.
특히 Firestorm의 192KB 명령어 캐시는 레이턴시 3사이클이라는 놀라운 효율을 보여주며,
ARM/AMD/Intel의 전통적 설계를 뛰어넘는 수준.

6. ✨ 참고 발언

“애플에 혁신 없다고 하는 사람들은, 애플을 잘 모르는 사람들…”

이 구조 하나만 봐도 Apple이 칩 설계에서 얼마나 극단적인 최적화를 추구하는지 알 수 있습니다.
커스텀 ISA는 아니지만, 마이크로아키텍처 설계 자체는 최고 수준이라 평가받는 이유이기도 하죠.

출처

• https://woozzang.tistory.com/155
• https://chunsubyeong.tistory.com/73
• https://ssoonidev.tistory.com/35