什么是性能？时间的倒数
和干体力劳动很像，好比搬东西。衡量指标。
（1）响应时间（Response time）或者叫执行时间（Execution time）。让计算机“跑得更快”。性能监测工具 NewRelic 中的响应时间：每个外部的 Web 请求的执行时间
（2）吞吐率（Throughput）或者带宽（Bandwidth），提升这个指标，让计算机“搬得更多”。一定时间内，能处理多少事情。
缩短程序的响应时间，都会提升吞吐率。还可以多找几个人来搬，类似服务器都是 8 核、16 核的。
响应时间提升不容易，CPU 的性能提升10 年前就处于“挤牙膏”的状态
性能 = 1/ 响应时间
Intel 最新 CPU Coffee Lake 上， 30s 运行完成， 5 年前 CPU Sandy Bridge 上， 1min 完成。
手机跑分软件，把多个预设好运行，根据运行时间，算出手机的性能评估。SPEC（Standard Performance Evaluation Corporation）的第三方机构，指定各种“跑分”的规则。
SPEC 提供的 CPU 基准测试程序，就好像 CPU 届的“高考”，通过数十个不同的计算程序，对于 CPU 的性能给出一个最终评分。这些程序丰富多彩，有编译器、解释器、视频压缩、人工智能国际象棋等等，涵盖了方方面面的应用场景。
计算机的计时单位：CPU 时钟
用时间来衡量性能时，有两个问题。
（1）时间不“准”。
程序统计程序运行的时间，有可能这次 45ms，下次 53ms。
为什么会不准呢？用类似于“掐秒表”一样，时间也叫 Wall Clock，Time 或者 Elapsed Time，程序运行程序期间，钟走掉的时间。
但可能同时运行着好多个程序，CPU 实际不停地在各个程序之间进行切换。在这些走掉的时间里面，很可能 CPU 切换去运行别的程序了。而且，程序运行时，可能要从网络、硬盘去读取数据，给到内存和 CPU。所以说，要想准确统计某个程序运行时间，进而去比较两个程序的实际性能，我们得把这些时间给刨除掉。
Linux time 命令，统计实际在 CPU 上花了多少时间。
第一个是real time，就是 Wall Clock Time，流逝掉的时间；
第二个是user time，CPU 在运行你的程序，用户运行指令的时间；
第三个是sys time，CPU 在运行你的程序，在操作系统内核里运行指令的时间。
程序实际花费的 CPU 执行时间（CPU Time），就是 user time 加上 sys time。比 Elapsed Time 要少不少
（2）CPU 时间，不一定可以直接“比较”出两个程序的性能差异。
同一台计算机上，CPU满载运行也可能降频运行，自然花时间多。还会受到主板、内存影响。
CPU 执行时间 =CPU 时钟周期数×时钟周期时间
1.时钟周期时间 CPU 主频： Intel Core-i7-7700HQ 2.8GHz（就是 主频Frequency/Clock Rate）。CPU 1 秒时间可执行 2.8G 条指令。
晶振（晶体振荡器Oscillator Crystal）：CPU 内部，和电子石英表类似。每一次“滴答”，就是时钟周期时间=1/2.8G。主频越高，走得越快。
超频：把CPU 内部钟调快，CPU也就变快。散的压力大，超过极限就崩。
2.CPU 时钟周期数：减少提升性能 =“指令数×每条指令的平均时钟周期数（Cycles Per Instruction，CPI）”。
不同指令需要的 Cycles 是不同，加法和乘法都对应着一条 CPU 指令，但是乘法需要的 Cycles 就比加法要多，自然也就慢
性能优化：
（1）主频，取决于硬件。我摩尔定律提主频。
（2）每条指令的平均时钟周期数 CPI，就是一条指令到底需要多少 CPU Cycle。在后面讲解 CPU 结构的时候，我们会看到，现代的 CPU 通过流水线技术（Pipeline），让一条指令需要的 CPU Cycle 尽可能地少。因此，对于 CPI 的优化，也是计算机组成和体系结构中的重要一环。
（3）指令数，代表执行我们的程序到底需要多少条指令、用哪些指令。这个很多时候就把挑战交给了编译器。同样的代码，编译成计算机指令时候，就有各种不同的表示方式。
总结延伸
“响应时间”拆解成了计算机时钟周期、CPI 以及指令数这三个独立的指标的乘积，优化计算机性能的三条康庄大道。也就是，提升计算机主频，优化 CPU 设计使得在单个时钟周期内能够执行更多指令，以及通过编译器来减少需要的指令数。
课后思考
1.能针对“跑分”作弊么？怎么做到呢？“作弊”出来的分数对于手机性能还有参考意义么？
停止其他全力跑跑分。提高时钟频率，停止温度检测和低级中断
没做过弊，猜测
2.为什么user + sys 运行出来会比real time 多呢
因为“并行原因”的运行的。虽seq和wc都是单线程运行的，在多核cpu运行下，分别分配到两个不同的cpu，就可能超过real的时间。这样来快速验证：time seq 100000000 | wc -l & 让这个命令多跑一会儿，并且在后台运行。
top 命令看不同进程的cpu占用情况，top的前几行里seq和wc的cpu占用都接近100，实际被分配到不同cpu执行。
我写文稿测试的时候开了一个1u的最小的虚拟机，只有一个cpu所以不会遇到这个问题。