［ZT］K10与酷睿2的总体技术差距

三毛妮

首先，做这样的设定：目前流出来的关于K10/K8L的框架相对K8改进的文章是正确的。否则没有讨论余地。

……………………………………………………………………………………………………………………………………


首先，我们看看K10/K8L相对K8改进了那些地方，于intel对比如何。
（1）把SSE执行单元的宽度改为128位，Conroe已经实现了，经过百万小时的严格测试，表现良好，AMD还在测试中。
（2）取指带宽，由16字节变为32字节。intel的Yonah就已经是32字节取指。
（3）间接分支预测，intel的P4的Prescott中已经加入，Yonah也加入了。不过因为P4的构架原因，使得它的L1缓存很小（8~12KB），另有跟踪缓存8KB，而间接分支预测需要大量的L1缓存，因此P4上表现很差。但是在Yonah上表现很好，因为32KB的指令缓存和32KB的数据缓存，足够存放间接分支预测的结果。当然Conroe的表现更加良好。不过目前intel没有公布Conroe的间接分支预测器的深度。AMD的K10是512级（推测的），没有证实。
（4）Sideband Stack Optimizer（边带/旁路堆栈优化器--暂译），与intel的dedicated stack manager（专门/专注堆栈管理器）相似，都是实现：处理器中的伐指令不再需要经过3路编码，也不再由整数执行单元处理，这加快了堆栈的处理速度，也同时加快了整数执行单元的处理速度。
（5）OOOE乱序执行，Conroe已经实现了，经过百万小时的严格测试，表现良好，AMD还在测试中。
（6）共享缓存，K10放在第三级，速度慢了很多，访问概率比较小。Conroe放在L2位置，实现读/写完全共享，更有条件实现单进程/单线程的并行执行（不过不要指望这个，除非OS支持）。
（7）集成内存控制器的改进和HT速度提高，集成内存控制器方面，Conroe没有做，但是Intel在几年前就已经做过，主要用在工控单片机上。故这个不好比较。HT使得多个核心之间可以读取（注意只能读取，不能写）对方的数据。不过HT的速度(说带宽更合适)再高，也就是3.Gbps左右，比起L2的访问速度10GB/s以上，不足一提。
上面基本上是K10的性能提高方面的改进，我们看到AMD所作的，基本上都是Conroe玩剩的，况且在工艺上，intel比AMD强得不是一丝半点（注意，仅仅在CPUg硅加工技术上，IBM也不如Intel，锗技术上，IBM强）。AMD无论如何也做不出性能比Conroe高40%的K10，除非真有天顶星人帮他们。

好，说到正题了，K10相对K8最弊端的没有改进指令发射宽度，也就是每次可以发射多少指令的问题。目前，K8和K10都是3指令发射，如果在分析师日看到的，AMD全新构架的下代CPU“推土机”没有改变，还是3发射。而Conroe是4发射，加上指令融合（宏指令和微指令都有融合），平均能达4.2到4.5之间，理想的情况就是5指令发射。虽然，Conroe是3简单指令+1复杂指令，K8/K10是3复杂指令。但是，目前处理的数据，简单指令占75%以上，因此处理速度还是简单指令快。
为什么AMD不做4指令发射？要实现4指令发射，在X86体系中非常艰难，它需要大量的资源，如寄存器，更需要高超的调度算法。X86体系，只有8个通用寄存器（注意，是8个，不能多，否则以前的软件统统不兼容，当然，当年的X86在科学家的努力下，实现了寄存器重名名技术。这是一个了不起的大发明），离4指令发射要求的寄存器的数量差几倍。AMD想做，还要下大量的功夫，专心研究才行，只是这2年内是没有希望看到的。（据说，当年K9规划就是四指令发射，因为困难重重，导致失败。因此现在没有K9型号，AMD自己说法是K9就是双核的K8）。
不难看到，当今X86体系中，也仅仅只有intel能够实现4指令发射。其他厂商还要付出艰苦的努力才行。

回到我们的话题，K10发指令发射，限制了提高性能的源头（注意，这是源头），因此它对K8性能的提高也是非常有限的，综合性能推测不会超过10%~15%，因此做得好，综合性能上K10能与Conroe不相伯仲，甚至还要弱一些。

其实这个结论在去年8月份，流出K8L/K10的框架时，我已经用AMD这个账号在太平洋的那篇文章的评论中说过。如今的几个测试更加证实了我的推测。

罗索那么多，有错误的地方，肯请各位指正。谢谢。
…………………………………………………………………………………………………………
为了保险，容许我高呼：AMD万岁，万岁，万万岁！

www.techreport.com的详细测试：
http://www.techreport.com/articles.x/13176/1

kisazhu

原帖由 哈哈小刀 于 2007-12-3 17:39 发表
对核心的东西我一点都不懂，只是看到百万小时的测试。那算100万小时吧

100万/24/365=114年，看来Intel的确花了不少心血。

这才是GZ的技术含量

[ 本帖最后由 kisazhu 于 2007-12-4 13:11 编辑 ]

fycmouse

管他谁快谁慢，两家使劲的掐，我们看戏，适当的时候声援一下弱者。保持竞争我们这些最终用户才能更多的得到实惠！什么GUN都是被逼急了或者是幸灾乐祸才跟狗一样出来乱咬的！这里就这点不好！

feixiaoyu

这个论坛好多人，，不懂装懂，懂一点光充老大。:funk:

itany

原帖由 acqwer 于 2007-12-3 21:04 发表

K10的BUG嘛，按anandtech的说法是L3和南桥都只能跑在2G。

以inq的RP，搞不好这个10~15%的提升指的是L3从2G提升到2.2G(9500)和2.3G(9600)。

现在任们一般认为L3和北桥跑2G是因为功耗实在抗不住了

鲁爾

进来看看……:unsure:

bessel

这个俺不信。

原帖由 colddawn 于 2007-12-3 20:22 发表

这里确切说Windows是作的非常好的，因为工作关系对这地方有些小研究，Linux等其他x86的OS还是要差些的，事实如此。 

acqwer

原帖由 colddawn 于 2007-12-3 19:34 发表

Right，就是这里，所以你认为K10这次属于前者还是后者呢？我认为K10的L3效能提升还是要先做好软件的准备工作，至于这两天那15%的提升，是什么样子的bug导致的有具体细节吗:loveliness:

K10的BUG嘛，按anandtech的说法是L3和南桥都只能跑在2G。

Currently, the L3 cache/NB on these chips runs ata fixed frequency that's actually lower than the rest of the CPUfrequency: 2.0GHz. We tested Phenoms running from 2.2GHz all the way upto 2.6GHz, and in all cases the L3 cache and North Bridge ran at 2.0GHz.

以inq的RP，搞不好这个10~15%的提升指的是L3从2G提升到2.2G(9500)和2.3G(9600)。

脸色

看热闹吧:loveliness:

colddawn

原帖由 itany 于 2007-12-3 20:00 发表


在Server上，共享L3早就有了，Tulsa就是共享L3的，Dunnington也会，至于Nehalem估计也会共享L3缓存，容量都比AMD要大
如果说要优化，还是Intel更占便宜
桌面上么，我不认为能优化出什么特别的来。反正能优化更 ...

这要看优化什么了，新指令集优化OS肯定不能为先，但是任务调度和cache以及CPU时间片轮转这些OS确实是跟进得很及时的，这里确切说Windows是作的非常好的，因为工作关系对这地方有些小研究，Linux等其他x86的OS还是要差些的，事实如此。
不论Intel和AMD谁强，等Intel有L3的民用U出来再对比，我认为看热闹最有意思。

itany

原帖由 colddawn 于 2007-12-3 19:50 发表

当然是指操作系统，谈系统优化已经有点超前了，应用软件要谈的话恐怕要等更久
不论谁延迟低，谁容量大，单是划分出L3这一点来看，从技术复杂度上已经先迈出一步了。共享缓存的策略在某些领域有测试能证明>8 threa ...

在Server上，共享L3早就有了，Tulsa就是共享L3的，Dunnington也会，至于Nehalem估计也会共享L3缓存，容量都比AMD要大
如果说要优化，还是Intel更占便宜
桌面上么，我不认为能优化出什么特别的来。反正能优化更好，Nehalem得利更大

另外，现在貌似应用软件优化在前，OS优化在后……
等到OS优化， :unsure:

[ 本帖最后由 itany 于 2007-12-3 20:04 编辑 ]

colddawn

原帖由 itany 于 2007-12-3 19:43 发表


具体细节不清楚……
但是，如果YY K10通过软件挖掘性能潜力，我看还是算了吧
如果说通过软件，比如说改进OS的线程调度和内存访问，可以优化共享缓存的性能，那有理由相信，容量更大、硬件延迟更低、更依赖于缓 ...

当然是指操作系统，谈系统优化已经有点超前了，应用软件要谈的话恐怕要等更久
不论谁延迟低，谁容量大，单是划分出L3这一点来看，从技术复杂度上已经先迈出一步了。共享缓存的策略在某些领域有测试能证明>8 thread后性能衰退有些严重不能忽略了。而有了L3那可以做手脚的地方就可以多一些了。2年之后，这必然必须考虑，AMD这玩招现在看来确实没用，然而以后说不准。想当年IMC和64bit也不过如此，只不过这两项第二点可以加大市场卖点，第一点除此之外确实能增强一些性能，所以成功，而K10这次嘛:loveliness: :loveliness:

itany

原帖由 colddawn 于 2007-12-3 19:34 发表

Right，就是这里，所以你认为K10这次属于前者还是后者呢？我认为K10的L3效能提升还是要先做好软件的准备工作，至于这两天那15%的提升，是什么样子的bug导致的有具体细节吗:loveliness:

具体细节不清楚……
但是，如果YY K10通过软件挖掘性能潜力，我看还是算了吧
如果说通过软件，比如说改进OS的线程调度和内存访问，可以优化共享缓存的性能，那有理由相信，容量更大、硬件延迟更低、更依赖于缓存性能的Core会获得更多的益处。别忘了Intel也是共享缓存的……

colddawn

原帖由 itany 于 2007-12-3 19:32 发表


我觉得一方面是编译器对现有架构的优化，另一方面是新架构对于已有代码执行效率的妥协，毕竟软硬件是互动的
我认为共享缓存、SMT、NUMA这样的“非传统”结构，在软件的优化下将发挥的更好，但是毕竟软件是渐进式 ...

Right，就是这里，所以你认为K10这次属于前者还是后者呢？我认为K10的L3效能提升还是要先做好软件的准备工作，至于这两天那15%的提升，是什么样子的bug导致的有具体细节吗:loveliness:

itany

原帖由 colddawn 于 2007-12-3 19:24 发表
呵呵，刚回复又多了内容，补一个
硬件同步自然比软件同步延迟小，但软件可以通过调度策略避免过多的同步行为，并不是说要在软件层面实现同步，这可以理解为一种优化策略吧，比如说系统可以优先将任务调度至分离缓存 ...

我觉得一方面是编译器对现有架构的优化，另一方面是新架构对于已有代码执行效率的妥协，毕竟软硬件是互动的
我认为共享缓存、SMT、NUMA这样的“非传统”结构，在软件的优化下将发挥的更好，但是毕竟软件是渐进式发展的，在硬件上必须，或者说不得不增加复杂性来使得既有程序能运行的更好，至少不是更差，否则很难得到市场的支持

colddawn

呵呵，刚回复又多了内容，补一个
硬件同步自然比软件同步延迟小，但软件可以通过调度策略避免过多的同步行为，并不是说要在软件层面实现同步，这可以理解为一种优化策略吧，比如说系统可以优先将任务调度至分离缓存的硬件线程执行（假如有这样的可用空闲硬件线程），这样相对于将任务调度至共享缓存的硬件线程内执行的话，自然需要同步的可能性就低，也就达到了所谓“优化”的目的。
好吧，其实我承认我扯得有点远了，离题了，不讨论也罢了。不过这帖子实在把我想了解的说了一点又不说明白，有感而发而已。

xiaolongzi

看了几家评测。感觉确实K10没有对酷睿2有什么技术上的优势。且AMD始终对K10的频率提升没什么办法。

colddawn

原帖由 itany 于 2007-12-3 19:12 发表


需要软件插手就不是密耦合，而是松耦合了
这时候就不是一台计算机，而是变成多个节点的集群了……

松密也都是相对的，像X86这么发展下去不是已经比当年要松了吗？就算是真假N核的区别，再加上L2/L3的分级，都已经需要上层系统做出一定的决策了，即使没有，我认为以后也应该会要有了。

itany

原帖由 colddawn 于 2007-12-3 19:06 发表


这个知道,我意思是硬件保证同步的同时必然带来时延,有时必要向操作系统暴露一些同步细节可以使系统在线程调度行为时尽量避免出现需要硬件进行同步的情况,否则就有可能出现在某种情况下两个核心的缓存行为出现较强 ...

需要软件插手就不是密耦合，而是松耦合了
这时候就不是一台计算机，而是变成多个节点的集群了……

硬件同步延迟大还是软件呢？这个市显然的吧
况且本身指令在执行前就要缓冲到L2或者L3当中去，锁缓存的指令要先被载入到缓存当中去，您不认为这个是无解的问题么

[ 本帖最后由 itany 于 2007-12-3 19:15 编辑 ]