146 lines
5.8 KiB
Markdown
146 lines
5.8 KiB
Markdown
---
|
||
tags:
|
||
- 计算机系统结构
|
||
- 重点复习
|
||
- Cache
|
||
- 3C模型
|
||
create time: 2026-06-16 21:21
|
||
---
|
||
|
||
# 小题 7 — Cache 不命中与 3C 模型
|
||
|
||
## 概述
|
||
|
||
本题考查 Cache 不命中的 **3C 分类模型**（Compulsory、Capacity、Conflict）及其各自的特点和对策。3C 模型是理解 Cache 行为和指导 Cache 优化的核心分析框架。
|
||
|
||
> [!tip] 考试重点
|
||
> 需要熟记三种不命中的名称、英文、原因和解决方法。考试常以选择题或简答题出现，题目可能给出一个场景让你判断属于哪种不命中类型。
|
||
|
||
## 正文
|
||
|
||
### 一、3C 模型概述
|
||
|
||
Cache 不命中可以按**产生原因**分为三类，合称 **3C 模型**：
|
||
|
||
```mermaid
|
||
graph TD
|
||
ROOT["Cache Miss"] --> C1["Compulsory Miss"]
|
||
ROOT --> C2["Capacity Miss"]
|
||
ROOT --> C3["Conflict Miss"]
|
||
|
||
C1 --> C1R["First Access"]
|
||
C2 --> C2R["Cache Too Small"]
|
||
C3 --> C3R["Mapping Conflict"]
|
||
```
|
||
|
||
### 二、三种不命中详解
|
||
|
||
| 类型 | 英文名 | 原因 | 发生条件 | 解决方法 |
|
||
|:----:|--------|------|----------|----------|
|
||
| **强制性不命中** | Compulsory Miss (Cold Miss) | **首次访问**某数据块 | Cache 冷启动时 | 增大块大小、硬件预取 |
|
||
| **容量不命中** | Capacity Miss | Cache **容量不足** | 工作集超过 Cache 容量 | 增大 Cache 容量 |
|
||
| **冲突不命中** | Conflict Miss | 多个块**映射到同一位置** | 直接映像或组相联中冲突 | 提高相联度、Victim Cache |
|
||
|
||
#### 2.1 强制性不命中（Compulsory Miss）
|
||
|
||
**原因**：某个数据块**第一次**被访问时，Cache 中必然没有该块。
|
||
|
||
> [!note] 特点
|
||
> - 也叫**冷启动不命中**（Cold Miss）或**首次访问不命中**
|
||
> - 与 Cache 的容量和相联度**无关**——即使 Cache 无限大、全相联，第一次访问仍然不命中
|
||
> - 在程序执行过程中只发生**一次**（对每个数据块）
|
||
> - 在长时间运行的程序中，强制性不命中占总不命中的比例**很小**
|
||
|
||
**对策**：
|
||
|
||
| 方法 | 原理 |
|
||
|------|------|
|
||
| 增大块大小 | 一次调入更多相邻数据，减少后续访问的强制性不命中 |
|
||
| 硬件预取 | 在数据被需要之前就将其调入 Cache |
|
||
| 编译器预取 | 编译器插入预取指令，提前加载数据 |
|
||
|
||
#### 2.2 容量不命中（Capacity Miss）
|
||
|
||
**原因**：程序的**工作集**（频繁访问的数据集合）超过了 Cache 的总容量，导致刚被替换出的块很快又需要被访问。
|
||
|
||
> [!note] 特点
|
||
> - 与映射方式**无关**——即使是全相联 Cache，只要容量不够就会发生
|
||
> - 在程序执行过程中**持续发生**
|
||
> - 增大 Cache 容量可以直接减少容量不命中
|
||
|
||
**对策**：
|
||
|
||
| 方法 | 原理 |
|
||
|------|------|
|
||
| 增大 Cache 容量 | 直接扩大 Cache 以容纳更多工作集 |
|
||
| 编译器优化 | 优化数据访问模式，减少工作集大小（如分块算法） |
|
||
|
||
#### 2.3 冲突不命中（Conflict Miss）
|
||
|
||
**原因**：在直接映像或组相联 Cache 中，多个主存块竞争同一个 Cache 行/组位置，相互替换。
|
||
|
||
> [!note] 特点
|
||
> - **只有直接映像和组相联 Cache 才有**——全相联 Cache 没有冲突不命中
|
||
> - 即使 Cache 总容量足够，如果两个频繁访问的块映射到同一位置，也会反复冲突
|
||
> - 典型场景：地址 A 映射到行 X，地址 B 也映射到行 X，交替访问 A 和 B 导致颠簸
|
||
|
||
**对策**：
|
||
|
||
| 方法 | 原理 |
|
||
|------|------|
|
||
| 提高相联度 | 更多路意味着更多位置，减少冲突概率 |
|
||
| Victim Cache | 用小的全相联 Cache 保存最近被替换出的块 |
|
||
| 伪相联 Cache | 先查主位置，不命中时再查次位置 |
|
||
|
||
### 三、3C 模型对比表
|
||
|
||
| 维度 | 强制性 | 容量 | 冲突 |
|
||
|:----:|:------:|:----:|:----:|
|
||
| **英文** | Compulsory | Capacity | Conflict |
|
||
| **别名** | Cold Miss | - | Collision Miss |
|
||
| **发生时机** | 首次访问 | 工作集过大 | 映射冲突 |
|
||
| **全相联 Cache 中** | 有 | 有 | **无** |
|
||
| **直接映像 Cache 中** | 有 | 有 | 有 |
|
||
| **增大 Cache 容量** | 不影响 | **减少** | 减少 |
|
||
| **提高相联度** | 不影响 | 不影响 | **减少** |
|
||
| **增大块大小** | **减少** | 可能增加 | 可能增加 |
|
||
|
||
> [!question] 思考：三种不命中的优先级？
|
||
> 在优化 Cache 时，通常按以下优先级处理：
|
||
> 1. **先减少冲突不命中**——成本最低（提高相联度或加 Victim Cache）
|
||
> 2. **再减少容量不命中**——成本较高（增大 Cache 容量）
|
||
> 3. **最后减少强制性不命中**——通常占比最小，预取技术有一定开销
|
||
|
||
### 四、3C 模型的实验验证
|
||
|
||
> [!example] 判断不命中类型
|
||
>
|
||
> **场景**：直接映像 Cache，4 行，块大小 16B。访问序列：0, 16, 0, 16, 0, 16, ...
|
||
>
|
||
> - 地址 0 → 行 0（**强制性不命中**，首次访问）
|
||
> - 地址 16 → 行 1（**强制性不命中**，首次访问）
|
||
> - 地址 0 → 行 0（**命中**，还在 Cache 中）
|
||
> - 地址 16 → 行 1（**命中**）
|
||
>
|
||
> 现在改为：Cache 只有 **1 行**（直接映像），同样的访问序列：
|
||
> - 地址 0 → 行 0（**强制性不命中**）
|
||
> - 地址 16 → 行 0（**容量不命中** + **冲突不命中**——只有 1 行，0 被替换）
|
||
> - 地址 0 → 行 0（**冲突不命中**——16 又被替换）
|
||
> - ...
|
||
>
|
||
> 如果是 **全相联** 1 行 Cache：第一次是强制性不命中，第二次是**容量不命中**（全相联无冲突不命中）。
|
||
|
||
> [!abstract]- 答案
|
||
> Cache 不命中的 3C 模型：
|
||
>
|
||
> | 类型 | 原因 | 解决方法 |
|
||
> |------|------|----------|
|
||
> | **强制性**（Compulsory） | 首次访问 | 增大块大小、预取 |
|
||
> | **容量**（Capacity） | Cache 太小 | 增大 Cache 容量 |
|
||
> | **冲突**（Conflict） | 映射冲突 | 提高相联度、Victim Cache |
|
||
|
||
## 关联笔记
|
||
- [[计算机系统结构/复习文档/存储系统与Cache]]
|
||
- [[小题6-组相联映射与标识存储器]]
|
||
- [[大题4-Cache性能计算]]
|