CPU简介

最近阅读了一些关于CPU的资料,自感收获颇丰。本文算是读后感,整理出来和大家分享。

CPU Pipeline

严格讲我不是CS专业,不清楚CS本科是否需要学习CPU架构。或者说,在这个软件高度集成的时代,软件工程师有必要掌握这些细节吗?我的答案是:学以致用的角度,不需要;如果你专注于性能优化,则有借鉴意义。

上图是一段简单的汇编以及个人注释,主要看气质。第一,所有的代码编译为汇编指令(Instruction),然后通过CPU执行,比如cmp(对比),add(加法),mulsd(浮点乘法)等。第二,在这个过程中,通过对应的寄存器,比如eax,xmm,将变量传递给CPU,寄存器有不同的类型,数目有限,通过mov指令,填补指令间的裂缝。

编译成汇编码后,运行阶段CPU会“逐条”(未必)执行每一条指令并返回结果,不同指令需要消耗不同的cycles,这个过程称之为Latency。下图是AMD K7中MOV指令对应的消耗:

CPU需要四个阶段来翻译每一条指令:

  • Fetch 从内存中获取该指令
  • Decode 解码
  • Execute 执行指令
  • Writeback 将结果写回

上图是执行一条指令的完整过程,CPI(Cycles Per Instruction) = 4。实际上,CPU也是流水线作业,同一时间执行多个指令。当这条指令将要进入execute阶段时,下一条指令也准备进入decode阶段,再下一条也开始fetch阶段,这样,单个指令花费的时间不变,但总体看,CPI = 1,性能提升了4倍,如下图所示:

人性是贪婪的,在这个基础上又不断优化,就是下面要介绍的Superpipelining & Superscalar。

不同指令的复杂度是不同的,但瓶颈总是那个最慢的指令。打个比方,马路上都是小汽车,路况流畅,突然来了一大卡,则容易阻滞。Superpipelining的思路是:以Logic gate(逻辑运算的基本组件)为最小单位,将复杂指令(大卡)拆分。结果是,CPU流水线变长(Deeper Pipeline),拆分后的指令可以达到CPI=1,且每秒能运行更多的Cycles。

Intel Pentium 4采用这种技术,将流水线扩展到31个stages,主频高达5k MHz。但在实际应用中,性能并没有太多提升,而Athlon XP和Motorola G4的性能反而更佳,因此Intel缩小到20 stages。这可以归咎于理论和现实的差距,首先,流水线变深是一种面向未来的设计方案,短时间内很难提升CPU的主频,因此性能提升有限;其次,流水线过长,会增大指令间的依赖关系,导致预判准确率下降(下面会提到)。

这样,流水线的Execute阶段实际上是功能单元的集合,各单元只负责自己的业务。这时自然会想到,是否可以并行执行指令,进而显著提升性能。但要做到这点,就要提高fetch和decode的能力,才能提供足够多的执行任务(execution resources)。实际上,Pentium 4和Athlon XP可以每个周期解码2.5个指令。而这种提供多个流水线的方式,就是superscalar。如下图,CPI = 1/3。

同样,这种策略也会有一些实际问题,比如内存存取数据性能的不足,无法获取足够多的数据,造成浪费,并行逻辑的复杂度,也容易造成预判准确率降低。

实际上还有一种VLIW(very long instruction word),如上所示,而实际中是对这几种策略的融合。

Dependencies& Prediction

按照上面的思路,扩展多条流水线,增加每条流水线的深度,不就可以提升性能吗?但实际应用则是另一个层面了。我们看下面这段代码:

a = b * c;

d = a + 1;

很简单的两行代码,第二行指令依赖第一行指令的结果。因此,处理器会挂起第二行指令,直到变量a的结果可用。这么宝贵的时间,白白浪费多么可惜,于是CPU决定调整程序的运行顺序,在挂起时找到其他合适指令来填补这些流水线bubbles。在技术上分为static(编译器)和dynamic(处理器)两种形式。

程序员应该了解编译器常见的优化选项,这个好处是编译阶段,可以提供足够多的资源和时间,编译器可以针对整段代码认真分析。但这种方案不可能做到准确的预测未来。

另外一种则是运行时的优化策略,称为OOO(out of order execution)。要做到运行时的乱序,要有能力记录指令间的依赖关系。为了简化变量间的依赖关系,一个有效的办法就是对变量重命名(Register Renaming)。这样,指令间的变量都对应独立的寄存器,进而实现并行化。这种策略的好处是动态的,同样的程序,不需重编译,自动新CPU的性能提升,但提高的CPU的逻辑复杂度。

我们再看另一种逻辑判断:

if(a>0){

...

}else{

...

}

在这,有两个branch,我们无法预知应该执行哪一个,但为了保证流水线的效率,CPU决定提前猜一个branch,猜对了就继续,猜错了就要flush,之前的准备白费。所以,问题的关键就是提高预测的准确度。

同样,这种预测分为static编译器和dynamic运行时两类。比如if逻辑则预判进入第一个分支forward,而while则预判是返回到循环体backward,但这种static预测通常只对循环较为有效。另一种则是运行时策略,比如记录上一次执行的分支,或者引用计数,作为预判的依据等,因此,需要占据一点芯片资源,随着流水线深度的加大,mispredict的可能性也加大。据统计,Pentium Pro/II/III中,30%的性能都浪费在预测失败上。因此,现代处理器分配更多的硬件资源来进行分支预测,比如不同分支间的关联,历史记录,多分支预测等,但即便如此,准确度只能达到95%。

另一种方案是提供条件判断指令(predicated instruction),在此就不介绍了。

Parallelism

讲到这,就是我自认为最有意思的讨论,提升CPU性能有两个思路,提高计算能力,让它能搬更多的砖,或者让它变得更聪明,提高效率。

我们不妨看看Intel的发展历程。早期因为CISC指令过于复杂,只能让CPU更聪明,后来,出于和AMD的竞争的需要,则专注于计算速度。同时,在IA-64上进行了大量编译器优化策略。面对IA-64的失败,Pentium 4过于追求速度带来的能耗,发热问题,以及AMD在低主频下良好的性能,Intel又重拾智慧路线。另外,在这个过程中,Intel在运行时期间对X86的指令进行简化,分解为RISC风格的微指令,称为μops。

可见,大家都属于局部激进,整体中庸的发展模式。因为大家心里都明白,在理论上,每一种方式都有一堵无法逾越的墙。

  • Thepower wall 目前,运算速度提升30%,则需要两倍的电压和发热,并且这种设计思路无法满足移动设备,也不可能长久
  • TheIPL wall 目前多数应用并没有很好的并行化设计(指令级别)
  • Thememory wall 内存和CPU在性能上的差距拉大,供不应求,后面会提到。

老一点的程序员应该都读过一篇文章《The Free Lunch Is Over》,不妨重读一下,里面有一句话“Chipdesigners are under so much pressure to deliver ever-faster CPUs that they’llrisk changing the meaning of your program, and possibly break it, in order tomake it run faster”。或者可以说,工程师在这三面墙上取得了巨大的进展,软件不做任何改进就可以等到性能的提升,但现在接近临界点了。面对窘境,Intel率先在Pentium 4支持SMT(Simultaneous multi-threading)技术,开启了多线程,多核方面的尝试。

事情的发展并非一帆风顺,多线程的价值是建立在一种假设之上:当前有很多应用程序在运行,或者一个程序内,有很多线程同时运行。然后,并不是所有场景都能符合如上的假设,比如数据库,三维图形渲染或科学运算,对并行运算有较高的要求,能很好的发挥多线程的优势(其实,也受限于带宽),但其他应用,比如浏览器,并不需要多线程或没有多线程的设计,则无法体现其价值。同时,因为是在一个Core中模拟多线程,线程切换的状态管理也是一种成本,因此,早期的SMT表现很诡异,性能跟具体程序有强连接。有时候,仿佛是两个高效的Core,有时候,就好比两个慵懒的Core,有时候,还不如一个Core实在。SMT在P4的速度的提升在-10%到30%之间,差强人意。在不断的探索后,目前Intel的Core i系列的设计方式是2^n个Cores每个Core支持两线程。在这个过程中,我们意识到,不同的应用程序,对多核和多线程的依赖程度是不一样的,因此,可以针对不同的应用场景,推出适合的CPU方案。

这样就有一个权衡:典型的SMT设计,要支持Superscalar,支持OOO,设计复杂度的提高,自然会占用更多的空间,因此,一个聪明的Core所占用的空间,可以装得下6个简单的Core(领导曾对我说:一个老员工的工资可以招三个应届生)。如上图,同样10亿个晶体管,左侧是Intel酷睿4核,共8个线程,后者是Sun的UltraSPARC,16核共128个线程。索尼PS3主机在设计上大胆创新,一个聪明的Core配N个简单的Cores,但产生很多兼容问题;再比如针对移动环境低能耗,便携和低性能,实现了CPU,GPU,网卡,IO等一体化的芯片设计。

经历了Instruction,Thread并行化后,还有Data并行化的方式,这也是本次我的一大收获:SIMD(single instruction, multiple data),也称为向量化处理。

对于C++程序员,不妨了解一下,目前Intel和Github上都有一些资料和开源库,可以学习参考,如果精力允许,不妨测试一下性能提升是否显著,特别是结合OpenMP等多线程机制,可以考虑对部分函数进行vectorization改造。

Memory Cache

上面基本上涵盖了CPU的主要知识点,还留下一个小尾巴,就是缓存。从处理器的角度而言,Cache就是处理器和内存之间一块空间小,但速度快的内存。因为人们发现程序在存取内存时,具有重复性(循环利用)和连续性(内存相邻),于是通过一种策略,将“更可能选中”的数据放在缓存中,从来缓解Memory Wall造成的Bubbles。

C++程序员不妨看一下《STL源码剖析》,里面也提到了STL的内存池概念,三级缓存的方式设计内存池。比如你看书,会把最近看的,重要的书放在桌子上,唾手可得;另外一些还不错的书放在书架上,挪一下屁股就可以找到;其他书放在箱子里,就需要折腾一翻。

一分钱一分货,给你这些空间了,如何有效的利用缓存,提高命中率,就是一件严肃的问题了。如下是时间成本的数学公式,而我们能优化的空间就是让tpp三变量尽可能小:

先从最简单的direct map,也称为One-way set associative。首先,我们看一下缓存存储方式,类似hashtable:

如上,根据内存地址的后三位,来指定映射关系,这样,缓存中有8个block,内存中平均4个block对应Cache中的一个block。

这样,就有一个问题,我只知道后三位,那如何知道当前缓存的数据对应的是四个block中的哪一个呢?这里引入一个tag概念,对应00,01,10,11四种可能,在查找时,如下图所示,判断Address的低位找到对应的Index,根据tag和高位判断是否命中。

该设计的好处是直接定位,缺点是易冲突。而且以动态的眼光来看,CPU寻址的速度会越来越快,这种设计的优势就越来越次要,而内存会越来越大,hash冲突的概率会越来越明显。这样,在Cache空间不变的情况下,如何降低冲突的可能?这里就要介绍一下目前主流的缓存设计方案:setassociative。

如上,思路就是扁平化,比如单路下的冲突属于设计问题,没有缓冲空间;而在这种情况下,N way就说明冲突的数据还有N个block并存,比如采用Least-Recently used(LRU)来提高命中率。

总结

坦白说,本文所有的思路和要点都不是我的,但每个字已融入我的血液中。而让我欣慰的是,能够把CPU的这些看似破碎的知识点连贯起来,从中窥探CPU发展的来龙去脉;再者结合软件开发中的一些经历,对一些问题的理解更深刻了,比如SIMD和Memory Cache。写到这,我很满足。

纵观CPU的发展,我觉得高速公路的例子形象。早期潜力大,我们优化路况,让每一辆车可以更快的到达目的地。当这一方式接近极限或应用成本无法接受时,我们开始扩宽路面,这样,每辆车的时间不会减少,但可以承载更多的车。其实,很多事物,甚至个人的发展,也都有共性。

同样的工资,你需要的是一个大学教授,还是三个搬砖工?当你的领导已经在考虑这个问题时,我只想说,你走你的路 直到我们无法接触。

原文发布于微信公众号 - LET(LET0-0)

原文发表时间:2018-03-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT派

如何让你的代码整洁漂亮?

IT派 - {技术青年圈} 持续关注互联网、大数据、人工智能领域 内容来源: 译者,飞鱼; 译文,http://www.zcfy.cc/article/ho...

3828
来自专栏HansBug's Lab

洛谷讲课手稿

Hello大家好,我是洛谷的HansBug。首先自我介绍下,我现在在北京航空航天大学,计算机科学与技术专业读大二,我参加过2013-2015年的提高组NOIP和...

3074
来自专栏PPV课数据科学社区

解析滴滴算法大赛---数据分析过程

目的和意义 很难有机会接触这么多的实际真实数据。 通过对于这些数据的分析,初步了解大数据的处理方式。 进一步掌握MongoDB的特性,熟练Excel的高级用法。...

35311
来自专栏程序员的诗和远方

20180722_ARTS_week04

这题寻找两个已经排好序的数组的中值,一开始思路比较简单,两个数组合一起,然后排个序就很容易找到中值了。

921
来自专栏牛客网

滴滴面试

2125
来自专栏用户2442861的专栏

笔试面试的小结 反

原文  http://blog.csdn.net/suky520/article/details/39641783

833
来自专栏数据派THU

【数据蒋堂】列式存储的另一面

来源:数据蒋堂 作者:蒋步星 本文长度为2400字,建议阅读3分钟 本文针对只读的分析计算任务探讨列存的缺点。 列存是常见的数据存储技术,在许多场景下也确实很有...

1765
来自专栏牛客网

这可能不只是一篇面经!2万字干货分享校招备战、笔试、面试的详细经验(下)

上接:http://www.jianshu.com/p/deae97625ea7 最后是面试中的技巧和经验。 1、好好对着自己写的简历一行一行看一遍,这都是你挖...

6526
来自专栏数据小魔方

sparklines迷你图系列12——Composition(Cascade)

今天继续跟大家分享的sparklines迷你图系列12——Composition(Cascade)。 不知道为啥这个图的名字英文看起来这么怪,但是其实他就是我们...

2694
来自专栏高性能服务器开发

去BAT,你应该要看一看的面试经验总结

说下我的面试经验吧,都是亲身经历,不喜勿喷: 我去年12月份从上一家公司离职,一直到今年3月份,基本上都在面试中度过来的。 先交代下背景:坐标上海,做技术开发,...

3324

扫码关注云+社区