Amdahl 定律——从哪来、为什么、有什么用
Amdahl 定律——从哪来、为什么、有什么用 钩子：你花大价钱把训练从 1 张卡扩到 8 张，满心期待快 8 倍，结果只快了 3 倍；给服务加了 16 个线程，吞吐量却卡在 4 倍上不去。问题往往不在你并行得不好，而在那段"怎么也并行不掉"的串行代码，给整体加速焊死了一个天花板。 这条天花板，就是 Amdahl 定律。 0. 一个反直觉的事实先抛个问题：一段程序，90% 能并行、10% 必须串行。给你无限多的核，它最快能快多少倍？ 直觉可能是"无限倍"——毕竟 90% 都能并行嘛。但答案冷冰冰：最多 10 倍。因为那 10% 的串行部分，无论你堆多少核，它都得一个人慢慢走，而总耗时里永远含着这一段。串行占比，就是加速比的天花板。 1. 它从哪来：1967 年，一场对"并行狂热"的泼冷水1967 年，IBM 的计算机架构师 Gene Amdahl 在 AFIPS 会议上提出这条定律（原称 Amdahl's Argument），本意是给当时方兴未艾的并行机热潮"降降温"。那时候业界流行一种乐观...
局部性原理——从哪来、为什么、有什么用
局部性原理——从哪来、为什么、有什么用 面试官问：为什么 Redis 查一次很快，而同样的数据放远程 MySQL 上要慢几十倍？为什么数组遍历比链表快，明明两者都是"一个接一个读"？为什么 CPU 造了三级缓存，却无论如何不肯做大一点？—— 答案都指向同一条规律：局部性原理。 0. 钩子：一个几乎不可能的缓存假设没有局部性原理，会发生一件很滑稽的事：CPU 花了几百亿造的 L1 Cache 几乎没有命中，命中率趋近于 0，缓存白装。为什么？因为缓存能起作用，靠的是"你读写过的数据，大概率很快还会再读写"——如果每次访问都落在完完全全随机的新位置，那缓存里存的旧东西永远派不上用场，装缓存等于没装。可现实是，几乎所有真实程序都有强局部性，所以缓存这条产业链才成立。局部性不是假设出来的，它是真实工作负载的结构性特征，缓存只是顺着这个特征搭的脚手架。 1. 它从哪来：Peter Denning 与工作集模型1965 到 1968 年，虚拟内存（分页）刚铺开不久，系统遇到一个棘手问题：程序一多、内存一紧张，页面就在内存和磁盘之间疯狂换入换出，系统陷...
每天一个计算机原则：专栏介绍
每天一个计算机原则：专栏介绍 学一个框架，三年后它可能就过时了；懂一条原则，十年后它还在帮你做判断。 写代码写到一定年头，你会发现真正决定一个人水平的，不是背了多少 API，而是脑子里装了多少条原则——那些在无数系统里反复出现、反复被验证的规律。Redis 的缓存、CPU 的多级 Cache、MySQL 的索引，看似毫不相干，底下踩的是同一条"局部性原理"；加线程不加性能、分布式怎么都绕不开取舍，背后是同一句"Amdahl 定律"。这个专栏要做的，就是每天一条，把计算机世界里这些"地基级"的原则一个个挖出来，讲清楚三件事：它从哪来、为什么需要它、它有什么用。 一、这个专栏是什么 是什么：每天一篇，讲解一个计算机领域反复出现的原则 / 定律 / 规律——从 Amdahl 定律、CAP 定理，到幂等性、背压、写前日志，再到 SOLID、KISS、最小权限。 不是什么：不追框架、不贴 API 文档、不做工具教程。原则讲的是"为什么世界被设计成这个样子"，而不是"这个按钮怎么点...
