什么是性能?时间的倒数
和干体力劳动很像,好比搬东西。衡量指标。
(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所以不会遇到这个问题。