POPPUR爱换

标题: 关于superpipeline [打印本页]

作者: 跳海自殺的鱼    时间: 2009-9-11 21:49
标题: 关于superpipeline
今天看量化的时候发现,superpipeline似乎并非是使用更长的ALU,而是将周期更加细化,让本来需要n个周期就可以经过的指令,使其需要更多周期才可以跑过,我不太明白这到底增加了什么,直接来了一句可以带来更高的频率,这种细分有啥意义吗?鄙鱼愚拙无法通晓,望高人解答
作者: Edison    时间: 2009-9-11 22:23
stage 之间间距减少,频率就比较容易提高了。
作者: 跳海自殺的鱼    时间: 2009-9-11 23:20
本帖最后由 跳海自殺的鱼 于 2009-9-11 23:43 编辑

2# Edison

恩,可是E大,这样有啥用吗?就是让频率看起来高,那性能上有啥提升吗,这点希望E大能详细讲讲,3Q了
作者: defia    时间: 2009-9-12 01:06
外行随便回帖,流水线级数提高,就是说在1个指令还没完成的时候,可以吞吐其他指令了吧..
这也带来了分支预测失败的风险啊..
不管流水线级数多少,如果1个时钟周期能吞1个指令并且得出1个指令的结果,那不考虑分支的话,就是核算的呀..
作者: Edison    时间: 2009-9-12 01:27
对于数据吞吐率先决的应用就非常适合,如果是有大量分支的话,例如国际象棋什么的,那就比较凄凉了。
作者: 跳海自殺的鱼    时间: 2009-9-12 12:39
忽然豁然开朗。。。。。
作者: lik    时间: 2009-9-12 14:08
几年前的一次面试被问过这个问题. 简单的说就是pipeline级数增加, 不过每级pipeline的delay减少, 主频能提高. 长pipeline有助于explore ILP. Pentium IV 是个极端. 记得Intel在ISCA01还是02上面有篇文章论证pipeline级数到40-50可以达到最优. 不过Pentium IV最后死在power wall前面. 其实还有AMD K9, 最后内部cancel了, 外人不知道. 所以这么多年了AMD的architecture还都是从K8上面衍生出来的.
作者: lik    时间: 2009-9-12 14:13
外行随便回帖,流水线级数提高,就是说在1个指令还没完成的时候,可以吞吐其他指令了吧..
这也带来了分支预测失败的风险啊..
不管流水线级数多少,如果1个时钟周期能吞1个指令并且得出1个指令的结果,那不考虑分支的话, ...
defia 发表于 2009-9-12 01:06


分支是有影响, 不过CPU的branch prediction效率都还算高, 很多benchmark的branch prediction都有95%+的准确率. 所以影响有限.
流水线级数多也意味每级的FO4延迟数少, 这样频率可以提高. 即便一个周期还是完成一条指令, 频率的提高也能提高性能. 别忘了CPU的好坏取决于execution time, 不是IPC.
作者: ic.expert    时间: 2009-9-12 15:10
请教一个问题,在SMT情况下,比如Alpha21464那种8Thread SMT情况下,如何保证一个好的BTB或是PHT效果?

另外对于多层分支嵌套即便是98%也会大打折扣,而这种多层分支嵌套好像比较普遍(当然这里不考虑编译器帮忙的效果),不知道有什么好办法?

另外,Value Predication在10年前左右大概热过一阵阵,不知道现在如何了,有什么新进展么?当然,Speculated Memory Load可以看做值预测的一种应用,但是除此外还有更广泛的应用么?不限于桌面处理器。
作者: RacingPHT    时间: 2009-9-12 23:38
提示: 作者被禁止或删除 内容自动屏蔽
作者: ic.expert    时间: 2009-9-13 02:20
我来解释一下

就说最简单的情况吧,5  Stage的经典Pipeline, IF取指-〉ID译码-〉RF读寄存器-〉EX执行-〉WB写回

一般来说最经典的预测器会放在ID,应为解码以后才能知道是否是Branch指令。而Branch是否Taken,则是要Branch指令执行完成以后,而Branch执行会发生在EX Stage。所以在这种流水线里面如果branch Predication Miss的话,那么就会导致从IF到EX之间4个Stage的指令惩罚,而不是惩罚5个Stage的指令。这一理论可以推广到20 Stage Pipeline上。
作者: lik    时间: 2009-9-15 13:46
ic.expert says well. 95% 是说95%的branch指令都被准确预测, 流水线一切照常. 剩下5%的情况miss prediction, 需要drain pipeline. 所有在该branch instruction之后的指令(那些都是speculated的)都要扔掉. 这些就是penalty. 相当于一个reset, 然后一切从正确的path重新开始. 这个penalty和branch prediction的准确率无关, 是architecture决定的.

我也是懂一些而已, 互相学习.

"分支是有影响, 不过CPU的branch prediction效率都还算高, 很多benchmark的branch prediction都有95%+的准确率. 所以影响有限."

我是外行,请教一下
对于一个20 stage的处理器来说,95%的预测成功率意味着每个br ...
RacingPHT 发表于 2009-9-12 23:38

作者: ic.expert    时间: 2009-9-15 15:11
楼上大牛说的深入浅出!!!

分支预测的主要问题在于它是和Shadow Register 技术绑定的,没有Shadow Register就不能在Miss Prediction时候还原现场。而在Inorder Pipeline上作Shadow Register的代价太大。对于OOO来说,Shadow Reigster可以和Reigster Renaming技术融合,尤其是基于CAM的Register Renaming Table,支持8层预测深度和16层预测深度都没有什么太大的Cost区别。

所以想请教lik大牛一个问题,LRB用的P54c上分支预测能支持几层预测深度?好在X86这种CISC的寄存器数量不多,现在精体管又很便宜。
作者: LinuxIsHard    时间: 2009-9-15 16:49
stage 之间间距减少,频率就比较容易提高了。
Edison 发表于 2009-9-11 22:23


半桶水
super pipeline跟clock freq有毛关系!
作者: Edison    时间: 2009-9-15 17:17
半桶水
super pipeline跟clock freq有毛关系!
LinuxIsHard 发表于 2009-9-15 16:49


pipeline stage 和频率有没有关系不是你这句话能改变的吧。
作者: LinuxIsHard    时间: 2009-9-15 17:28
本帖最后由 LinuxIsHard 于 2009-9-15 17:30 编辑

我是说 super pipeline这种Arch 和 clk freq, 你没看懂?如果你说行, 我倒想请教super pipeline如何提升clk freq
作者: Edison    时间: 2009-9-15 18:03
传统的 pipelined 就是 IF/ID、memory read、EX、Memory Write 这样基本的 4、5 个 stage,Super Pipelined 就是把这些 stage 切得更细,至于多少个 stage 才算是 super pipelined 则很难说了,但是目前只有 4、5 个 stage 的主流 CPU 已经比少了。

把 stage 切细的目的就是让 cycle time 缩小。

你不会是把 super pipelined 看成是 super scalar 吧。
作者: LinuxIsHard    时间: 2009-9-15 18:38
很明显你对概念就不理解
super pipeline不是由stage数目来决定的,完全2回事
更别说super scalar了
作者: yamhill    时间: 2009-9-15 18:44
高级

和P4有点像?
作者: Edison    时间: 2009-9-15 18:50
这么说吧,你把你认为正确的 super pipeline 定义说出来好了。
作者: LinuxIsHard    时间: 2009-9-15 19:05
本帖最后由 LinuxIsHard 于 2009-9-15 19:21 编辑

阴阳怪气?高手,可否解释解释

很多人把super pipeline = super long pipeline,当然这也有历史的原因,因为真正意义上super pipeline实际上很少有人做,而且有些资料也直接将其2者画等号.
超<<长>>流水线理念结构上只是把stage分更多,每个stage仍需要一个完整的clock cycle. 超长的理念就是细分stage时间,当然可以提高clock freq. stage的多少根本不算一种新Arch, 现实中每个CPU都会根据硬件和其他限制适当调整stage数.传统的5 stage更多意义上是一种logic stage

但超<<级>>流水线的理念完全不同,虽然实现出来的感觉有点像超长流水线,超级的意思是将每个clock cyle尽量塞满,因为在惯常的logic stage分法里不是每个stage都需要同样的时间,将2个或多个stage合在一个clock cycle里完成,例如将fetch, decode合在一起,2者的共用的硬件时间和execute差不多。换言之,clock并没有变快,但实际上因为每个clock都完成更多的东西而变快。超级的理念就是平衡stage时间,实际在芯片设计中多数是引入一个invert clock,利用其edge做为2个stage之间的hard edge.

实际上super pipeline只是一种昙花一现的架构,因为各种技术发展,而且有很多技术利用了类似的概念,例如时间挪用等等都模糊了super pipeline的区别.
作者: ic.expert    时间: 2009-9-15 19:21
阴阳怪气?高手,可否解释解释

很多人把super pipeline = super long pipeline,当然这也有历史的原因,因为真正意义上super pipeline实际上很少有人做,而且有些资料也直接将其2者画等号.
超流水线理念结构上只是把s ...
LinuxIsHard 发表于 2009-9-15 19:05


LinuxIsHard大牛真的博闻多学,但是我比较孤弱寡闻,所以大牛能不能给出superpipeline的出处?我还想请教一下,我这种技术和我们平时在设计Pipeline时候的Load Balance调整技术有什么不同么,还望大牛明示
作者: Edison    时间: 2009-9-15 21:06
pipeline stage 在切割的时候本来就是要做到尽量一致的长度。
作者: LinuxIsHard    时间: 2009-9-15 21:59
1988 Jouppi N. Superscalar versus Superpipelined Machines
William Stallings. Computer Organizations & Architecture

Superpipeline的理念不是在于切割stage, 细粒度或者单纯平衡stage的长度只是停留在stage优化的程度
在那个年代, Superpipeline的概念是通过不等分stage的长度而可以做到在一个clock cycle里面多发射指令,这个目标和superscalar很相近,但硬件实现起来却和super long pipeline的方法又有异曲同工的地方.但这种概念也只能局限在当时的硬件条件和相对功能简单的结构,例如所谓的5 stage.
作者: Edison    时间: 2009-9-15 22:24
我现在下载不了 IEEE 的东西了。

不过:Superpipelined machines can issue only one instruction per cycle
作者: RacingPHT    时间: 2009-9-15 23:50
提示: 作者被禁止或删除 内容自动屏蔽
作者: ic.expert    时间: 2009-9-16 00:04
那大牛的意思就是说,比如ID比如所有部件都快2倍的freq,从而相当于双发?
作者: Edison    时间: 2009-9-16 00:35
这个我之前看过,不过没提到 issue 2 instr per cycle 吧,他在前面说的可是每个周期发射多个指令。
作者: RacingPHT    时间: 2009-9-16 09:28
提示: 作者被禁止或删除 内容自动屏蔽
作者: 跳海自殺的鱼    时间: 2009-9-25 21:45
鄙人不才,简单谈谈。
我觉得super pipeline和clock freq是有一些间接关系的,因为将stage细分,而在pipeline中clock freq又由耗时最长的stage所决定,那么如果pipeline分化的越细,clock freq更好向上彪
作者: vanwong    时间: 2009-10-13 13:32
提示: 作者被禁止或删除 内容自动屏蔽
作者: diboyvy    时间: 2010-1-13 13:15
了解了,受用了
作者: xiaoxiaoyun    时间: 2010-1-14 00:53
明白了一点~
作者: tilong-lee    时间: 2010-1-14 00:54
明白了一些,呵呵, 还是不怎么明白
作者: 中国高科    时间: 2010-2-17 02:23
提示: 作者被禁止或删除 内容自动屏蔽
作者: 中国高科    时间: 2010-2-17 02:23
提示: 作者被禁止或删除 内容自动屏蔽




欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4