程序装载

1. 在Linux或Windows下，程序并不能直接访问物理内存
2. 内存需要被分成固定大小的页，然后通过虚拟内存地址到物理内存地址的地址转换，才能到达实际存放数据的物理内存位置
   • 程序看到的内存地址，都是虚拟内存地址

缓存一致性问题

缓存行

1
2
3
4
5
6
7

$ sysctl -a | grep -E 'cacheline|cachesize'
hw.cachesize: 17179869184 32768 262144 6291456 0 0 0 0 0 0
hw.cachelinesize: 64 # 64 Bytes
hw.l1icachesize: 32768 # 32 KB
hw.l1dcachesize: 32768 # 32 KB
hw.l2cachesize: 262144 # 256 KB
hw.l3cachesize: 6291456 # 6 MB

局部性原理

1. 局部性原理：时间局部性（temporal locality）+空间局部性（spatial locality）
2. 时间局部性：如果一个数据被访问了，在短时间内还会被再次访问
3. 空间局部性：如果一个数据被访问了，和它相邻的数据也很快会被访问

SRAM

1. CPU类比成计算机的大脑；而正在思考的东西，可以类比成CPU中的寄存器（Register）
   • 寄存器更像是CPU本身的一部分，存放极其有限的信息，但速度非常快，和CPU同步
2. 大脑中的记忆，类比成CPU Cache（高速缓存）
   • CPU Cache使用的芯片是SRAM（Static Random-Access Memory，静态随机存取存储器）
3. 静态：只要处于通电状态，里面的数据就能保持存在，而一旦断电，里面的数据就会丢失
4. 在SRAM里，1个比特的数据，需要6~8个晶体管
   • 所以SRAM的存储密度不高，同样的物理空间下，能够存储的数据有限
5. SRAM的电路简单，所以访问速度非常快
6. 在CPU里，通常会有L1、L2、L3这三层高速缓存
   • L1 Cache
     • 每个CPU核心都有一块独占的L1 Cache，通常分为指令缓存和数据缓存
     • L1 Cache通常嵌在CPU核心的内部
   • L2 Cache
     • L2 Cache同样是每个CPU核心都有，但往往不在CPU核心的内部，因此L2 Cache的访问速度会比L1 Cache稍慢
   • L3 Cache
     • L3 Cache通常是多个CPU核心共用的，尺寸更大，访问速度更慢
7. 简单类比
   • L1 Cache – 短期记忆
   • L2/L3 Cache – 长期记忆
   • 内存 – 书架

1
2
3
4
5

$ sysctl hw.l1icachesize # L1 instruction cache
hw.l1icachesize: 32768

$ sysctl hw.l1dcachesize # L1 data cache
hw.l1dcachesize: 32768

解释型虚拟机

1. 要模拟一个计算机系统，最简单的办法，就是兼容这个计算机系统的指令集
2. 开发一个应用程序，运行在操作系统上，该应用程序可以识别想要模拟的计算机系统的程序格式和指令，然后一条条去解释执行
3. 原先的操作系统称为宿主机（Host），有能力模拟指令执行的软件称为模拟器（Emulator）
   • 实际运行在模拟器上被虚拟出来的系统，称为客户机（Guest VM）
4. 这种方式和运行Java程序的JVM比较类似，只不过JVM运行的是Java中间代码（字节码），而不是一个特定的计算机系统的指令
5. 真实的应用案例：Android模拟器、游戏模拟器
6. 优势
   • 模拟的系统可以跨硬件
   • Android用的是ARM CPU，开发机用的是Intel X86 CPU，两边的CPU指令集是不一样的，但一样可以正常运行
7. 劣势
   • 无法做到精确模拟
     • 很多老旧的硬件的程序运行，需要依赖特定的电路乃至电路特有的时钟频率，很难通过软件做到100%模拟
   • 性能很差
     • 并不是直接把指令交给CPU去执行，而是要经过各种解释和翻译的工作
     • 编译优化：Java的JIT
       • 把本来解释执行的指令，编译成Host可以直接运行的指令

历史

1. 在早期，所有的CPU都是CISC
2. 实际的计算机设计和制造会严格受到硬件层面的限制，当时的计算很慢，存储空间很小
   • 为了让计算机能够尽量多地工作，每个字节乃至每个比特都特别重要
3. CPU指令集的设计，需要仔细考虑硬件限制，为了性能考虑，很多功能都直接通过硬件电路来完成
4. 为了少用内存，指令长度也是可变的
   • 常用的指令要短一些，不常用的指令要长一些
   • 用尽量少的内存空间，存储尽量多的指令
5. 计算机的性能越来越好，存储的空间也越来越大，70年代末，RISC出现
   • CPU运行程序，80%的运行代码都在使用20%的简单指令

异常

1. 异常是一个硬件和软件组合在一起的处理过程
   • 异常的发生和捕捉，是在硬件层面完成的
   • 异常的处理，是在软件层面完成的
2. 计算机会为每一种可能发生的异常，分配一个异常代码（Exception Number），别称中断向量（Interrupt Vector）
3. 异常发生的时候，通常是CPU检测到一个特殊的信号
   • 在组成原理里面，一般叫作发生了一个事件（Event），CPU在检测到事件的时候，就已经拿到了对应的异常代码
4. 异常代码
   • IO发出的信号的异常代码，是由操作系统来分配，即由软件来设定
   • 像加法溢出这样的异常代码，是由CPU预分配的，即由硬件来设定
5. 拿到异常代码后，CPU会触发异常处理流程
   • 计算机在内存里，会保留一个异常表（Exception Table），别称中断向量表（Interrupt Vector Table）
   • 存放的是不同的异常代码对应的异常处理程序所在的地址
   • CPU拿到异常代码后，会先把当前程序的执行现场（CPU当前运行程序用到的所有寄存器），保存到程序栈里面
   • 然后根据异常代码查询，找到对应的异常处理程序，最后把后续指令执行的指挥权，交给这个异常处理程序
6. 异常可以由硬件触发，也可以由软件触发

超线程 – 线程级并行

Pentium 4

1. Pentium 4失败的原因：CPU的流水线级数太深
2. 超长的流水线，使得之前很多解决冒险、提升并发的方案都用不上
3. 解决冒险、提升并发的方案，本质上是一种指令级并行的技术方案，即CPU希望在同一个时间，去并行执行两条指令
   • 但这两条指令，原本在代码里是有先后顺序的
4. 无论是流水线架构、分支预测以及乱序执行，还是超标量和超长指令字
   • 都是想通过在同一时间执行两条指令，来提升CPU的吞吐率
   • 但在Pentium 4上，上面这些方法都可能因为流水线太深，而起不到效果
   • 更深的流水线意味着同时在流水线里面的指令就很多，相互的依赖关系就多
   • 因此，很多时候不得不把流水线停顿下来，插入很多NOP操作，来解决这些依赖带来的冒险问题

吞吐率

1. 程序的CPU执行时间 = 指令数 × CPI × Clock Cycle Time
2. CPI = Clock Per Instruction
3. IPC = 1/CPI = Instruction Per Clock
   • 一个时钟周期内能够执行的指令数，代表了CPU的吞吐率
   • 最佳情况下，IPC只能到1
     • 无论做了哪些流水线层面的优化，即使做到了指令执行层面的乱序执行
     • CPU仍然只能在一个时钟周期内取一条指令！！
     • 无论指令后续无论优化得多好，一个时钟周期也只能执行一条指令，IPC只能是1
4. 但Intel CPU或者ARM CPU，一般IPC能做到2以上