Arm vs X86的论文

huangpobu

PS5 发表于 2013-3-15 08:26
那X86是啥意思？丹佛没必要支持X86吧！

丹佛的CPU是ARM核心呀，官博上那段话是专门写出来恶心x86的。。。。

huangpobu

complexmind 发表于 2013-3-15 05:24
好久不见了，大师~
楼主贴的论文的观点我是认可的，在CISC和RISC之争在经典教材《计算机体系结构：性能设 ...

ILP Wall啊

能发掘的指令级并行性越来越少，而且多发射的开销是随着发射宽度的提高而指数级增长的，90年代初的时候大家都觉得将来的趋势是宽发射，那时发表的论文里还有15发射这种怪兽级模型。

后来Intel做完P4，大家都发现加长流水提高发射宽度发掘ILP这种方法很难延续了，一个原因是设计复杂度太高，比如宽发射的分支预测啊什么的极麻烦，宽发射以后意味着一个周期里可能碰到多条分支指令，那么可能就要同时预测多个分支的走向，开销已经大于收获了，另一个原因也是效能太低，每瓦性能低下，而集成电路设计的功耗限制又越来越严重，再提高发射宽度意味着效能会更差，而电路上的高功耗要是按照当时的趋势继续恶化下去就会连芯片都冷却不了了。

这些道理在量化上讲的很清楚了，转向多核心并行并不是因为并行编程或者多核心更容易做，而是面对ILP Wall和Power Wall双重挑战下的无奈选择

The switch to multiple processors per chip around 2005 did not come from some breakthrough that dramatically simplified parallel programming or made it easy to build multicore computers. The change occurred because there was no other option due to the ILP walls and power walls. 书上原话

koppie

complexmind 发表于 2013-3-15 05:24
好久不见了，大师~
楼主贴的论文的观点我是认可的，在CISC和RISC之争在经典教材《计算机体系结构：性能设 ...

指令级并行ILP是有上限的，有些依赖关系是不可能完全消除的。六发射至少多一倍资源和功耗，但是性能却提高不了多少。

你看core 2一直到Haswell, 宽度都是4. 规模太大，timing closure很难做，高频就更难搞, 功耗问题严重

largewc

huangpobu 发表于 2013-3-13 21:12
我问你这个R3怎么用SIMD算，结果你回给我一个分拆，然后号称可以用SIMD写。这太扯了。不能写就不能写，没 ...

这两天比较忙，好久没过来看了。

自加是能乱序的，加法是有交换率这个基础数学规则的，在cpu最简单的寄存器重命名都是可以并发的，你乱序不乱序代码一样的结果，对于cpu没有区别。


我说过了，你要是自加再自乘有顺序完全相关的，在某些特定情况是无法simd化的。我的观点是大部分能拆循环的地方，都能simd化。

不想战斗了，反正我也不是做cpu的，看未来的发展吧，最近招人要面试，麻烦事一大堆……

你有qq没，做个朋友吧^^

PS5

huangpobu 发表于 2013-3-15 09:18
丹佛的CPU是ARM核心呀，官博上那段话是专门写出来恶心x86的。。。。

为啥要恶心X86呢？

PS5

内存墙 nv和intel都是如何面对的？

FENG950

huangpobu 发表于 2013-3-15 01:24
你的理解不对。寄存器重命名能消除假依赖，但是不能解决live-in value争用寄存器的问题。物理寄存器ISA不 ...

遇到结果相关，难道ISA加几个寄存器就解决问题了？x86-64加多8个寄存器就解决大问题了？优化寄存器使用和寄存器重命名有什么关系？现在内存大了，软件挥霍内存还不是一样被骂。隐藏的寄存器资源也是有限的，避免长时间占用不是很应该吗？x86就那些个通用寄存器，相比其它的ISA少多了，性能上因为如此被打的抬不起头了？

回到这里讨论的这篇论文，已经说的很清楚，在现今技术条件下，性能功耗之类，ISA代表的的体系结构跟它们已经扯不上干系，更多的是依靠具体的微架构的设计实现。

koppie

PS5 发表于 2013-3-15 17:55
内存墙 nv和intel都是如何面对的？

memory hierarchy啊，通过多级的cache隐藏内存的延时

PS5

koppie 发表于 2013-3-15 22:46
memory hierarchy啊，通过多级的cache隐藏内存的延时

还是不行啊！而且代价太大了

koppie

PS5 发表于 2013-3-16 00:31
还是不行啊！而且代价太大了

乱序执行一定程度上也有作用。但是memory wall是物理限制，能做的也就这么多了

huangpobu

FENG950 发表于 2013-3-15 20:07
遇到结果相关，难道ISA加几个寄存器就解决问题了？x86-64加多8个寄存器就解决大问题了？优化寄存器使用和 ...

我已经越来越看不懂你在说什么了。

我先说寄存器数量影响编译器调度。

你回复说【寄存器重命名都出现这么久了】，这句话让我非常怀疑你是否真的懂寄存器重命名还是简单百度一下就上来了。哪怕认真读过一遍书都知道寄存器重命名跟编译器调度是两个层面的事情。你硬是不信邪，可以考虑一下四个寄存器怎样面对频繁出现的8个live-in value，看看寄存器重命名怎么救得了。

然后你开始说结果相关和寄存器数量没有关系，我就开始纳闷编译器调度与结果相关和ISA可见的寄存器数量有什么联系？然后你突然又扯了一句：

【优化寄存器使用和寄存器重命名有什么关系？】

看到这里我就明白了，你这上下两句加红的话自相矛盾，麻烦你先理解清楚你自己在说什么，再来回我的帖子，行不行？

huangpobu

FENG950 发表于 2013-3-15 20:07
遇到结果相关，难道ISA加几个寄存器就解决问题了？x86-64加多8个寄存器就解决大问题了？优化寄存器使用和 ...

abcdefgh 八个live-in value, 四个通用寄存器。

load r1,a;
load r2,b;
load r3,c;
load r4,d;

几个使用abcd的算术操作序列s1；

再跟着几个使用值efg的算术操作序列s2；
需要把efg load进寄存器r1,r2,r3, abc store回存储器；//r1,r2,r3引入了假依赖，可以用重命名解决，也就是s1s2的算术操作能一起执行，但是load store避免不了，重命名根本帮不到忙

再跟着几个使用abcd的算术操作，但是现在abc已经不在r1,r2,r3里面了；
abc又要load回来，efg又要store回去；如果中间的算术操作需要同时用到abcd\efg 这两组中的任意两个，编译器就要抓瞎，再继续load store，这等于限制了live-in value的存活，要做代码优化的时候碰到的是零零散散的abcd\efg存活空间，调度能力受限

就这么简单的事情，这个东西叫做register perssure，跟寄存器重命名有个毛关系？这个问题通过增加ISA可见寄存器的数量不就很轻松地解决了？

huangpobu

largewc 发表于 2013-3-15 14:59
这两天比较忙，好久没过来看了。

自加是能乱序的，加法是有交换率这个基础数学规则的，在cpu最简单的寄 ...

好的

那个例子我想我应该写得很明白了，自加能乱序的确是没错，而且这个plus scan的例子是可以用CUDA大规模并行的，这意味着它本质上的确可以并行，具体的代码我可以QQ上发给你看，编译器要做这种优化真可谓是难如登天，我觉得这种代码在vector处理里面比较好做。

PS5

koppie 发表于 2013-3-16 06:11
乱序执行一定程度上也有作用。但是memory wall是物理限制，能做的也就这么多了

GPU上也是这么解决问题的？

huangpobu

PS5 发表于 2013-3-16 16:43
GPU上也是这么解决问题的？

差不多相同。

首先GPU上也是多级存储器结构，但是相比主要发掘ILP的CPU来说，GPU主要发掘的是线程级并行度或者是数据级并行度，比如CUDA的一个流处理器可以在48个线程中任意选择一个就绪的线程来执行，这就意味着它可以至少容忍几十个周期的存储器延迟，也就是通过重叠几十个线程的工作来隐藏延迟。

huangpobu

关于X86的寄存器数量问题，我补充一句。

1.寄存器数量影响编译器调度，这个是写在教科书上的共识性问题，我没想到居然会有争论。寄存器重命名和编译器调度扯不上关系，我已经举过例子了，混淆的人应该好好重新回过去看书。

2.x86从ISA上来看不是一个好东西，读过《量化》和《软硬件接口》，对比一下x86和MIPS都会有这个感受，一个一团乱麻，另一个设计优美，这也没有什么好说的。

3. 没有人说x86会因为寄存器数量就变得不堪，衡量ISA的好坏又不是只看通用寄存器数量。寄存器数量少只是一个缺点，这不是什么致命的东西。IBM 360双精度浮点寄存器只有4个，照样是个厉害的架构。

4. x86性能很强，是因为微架构的技术进步弥补了ISA上的不足。我很同意在现在的技术条件下谈论ISA上的区别已经意义不大，但是要搞清楚这一点：被遮盖不代表问题不存在。

5. 关于这篇论文，上百楼下来我都没有发表什么看法，因为我还没仔细看过，待会儿开始看。这篇论文的结论是ISA无关，被很多人拿来说事，但是这往往是外行的做法。

内行的做法是，首先，好好看完这篇论文，重点看实验方法和数据部分。魔鬼隐藏在细节中。

接着，看其他同行公开发表的评价。要知道一篇论文不能代表学术界和工业界的主流认识，就连这篇论文的开篇也自己表明了，以前有的论文得出过ISA会影响性能的相反结论。

所以具体如何，起码得仔细看完全文才能得出初步结论。

huangpobu

花了一个小时看完了论文。今天重感冒，头有些晕，不能花很长时间码字了，我还有课程项目要做。

这个文章的实验方法有很多的限制因素，而且作者自己也承认了。从好的方面说，这也不是作者的错，跨ISA比较本来就是很艰难的工作。这个作者还是个女硕士，已经采用了最好的办法，算是不错了。从不好的方面说，作者的推论分析与结论之间就有一道沟，说大不大，说小也不小。

我就说一下我的看法，具体的以后再来谈。

ISA跟性能仍然有关（有的情况下ARM的指令数多达X86的十几倍）

ISA也会冲击到编译器层面（有的测试数据集里x86的load/store微操作数量超过ARM一倍，编译器要填充这些slots的时候就会更辛苦）

各个测试数据集间的各个指标差异有大有小，比如有的情况下ARM和X86指令数相同，load/store也相差无几，有时候就会差距很大，正负差距都有，而作者采用了平均化的办法，我个人不是很同意。

虽然ISA跟性能仍然相关，但是微架构层面的影响更大，而微架构层面的激进也是有比较大的代价的，功耗，成本。

总的来说，这篇论文披露了很多有价值的数据和对比，但是对最终结论的支持不够。从平均上来说，微架构对性能的影响的确超过ISA，但不代表ISA无关。这篇论文的一个个平均数字背后是很多的正负差距甚至是过大的异常值，我觉得这篇论文没有很好地解释清楚（这不一定是作者水平不够，论文篇幅可能受限），如果能够针对这些测试做更多说明，结论才更有说服力。

FENG950

huangpobu 发表于 2013-3-16 15:57
abcdefgh 八个live-in value, 四个通用寄存器。

load r1,a;

你的原话不是寄存器数量影响调度，而是让编译器难于优化。

ISA可见寄存器不足，编译器可不可以优化计算步骤，不是一次加载数个变量，而是先运算出中间结果来避免？

FENG950

huangpobu 发表于 2013-3-16 19:34
花了一个小时看完了论文。今天重感冒，头有些晕，不能花很长时间码字了，我还有课程项目要做。

这个文章 ...

说ISA的时候，包括这篇论文，都是在讨论ISA所代表的某种风格的体系结构，而不是具体的包含了XX条指令的ISA，如果说ISA对性能没影响的话intel年年加那么多指令提升性能干什么？之所以说ISA（风格）对性能影响不大，就是因为它们本身也是在随着时代进步不断进化的。

huangpobu

FENG950 发表于 2013-3-16 20:09
你的原话不是寄存器数量影响调度，而是让编译器难于优化。

ISA可见寄存器不足，编译器可不可以优化计算 ...

就是一个意思。编译器的优化很大程度上就是code scheduling，什么software-pipeling, code elimination都是。

的确，ISA可见寄存器不足，编译器是可以优化的，一个最简单也直观的例子就是寻找公共子表达式，传播这个计算结果。至于运算出中间结果，它也是要寄存器存放的，具体能不能通过重命名来bypass，要看代码的上下文。

补充说明，我上面写的那种代码，只是一种特例，并不是在所有情况下都成立，这篇论文里展示的代码编译结果就是，有时候x86的load-store反而比ARM少，具体情况需要具体分析。但是总的来说，编译器是喜好更多数量的通用寄存器的。