POPPUR爱换

标题: ［ZT］K10与酷睿2的总体技术差距 [打印本页]

作者: 三毛妮 时间: 2007-12-1 22:48
标题: ［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

作者: Songhaipeng 时间: 2007-12-1 22:54
你的话可信度有点就不错了

飘过

作者: 紫色 时间: 2007-12-1 22:59
其它东西都是虚的，多半只能YY下的。intel的杀手锏其实也就是4指令发射。

作者: kof2003 时间: 2007-12-1 22:59
唔......
虽不知道技术上的东东，
不过LZ还是辛苦了。:loveliness:

作者: YsMilan 时间: 2007-12-1 23:16
这不是AMD11写的吗

作者: 晶晶守护神 时间: 2007-12-1 23:48
提示: 作者被禁止或删除内容自动屏蔽

作者: Bohr 时间: 2007-12-2 00:10
提示: 作者被禁止或删除内容自动屏蔽

作者: colddawn 时间: 2007-12-2 00:33
问一下第6点，对于L2/L3的共享缓存，到底是怎么实现多硬件线程并发访问时的同步控制的？有单独的锁缓存指令吗？能细到什么粒度？如果有的话那肯定可以确认是需要操作系统支持了，会有补丁？

作者: Rednaxela 时间: 2007-12-2 00:33
提示: 作者被禁止或删除内容自动屏蔽

作者: 1empress 时间: 2007-12-2 00:36
提示: 作者被禁止或删除内容自动屏蔽

作者: 晶晶守护神 时间: 2007-12-2 00:39
提示: 作者被禁止或删除内容自动屏蔽

作者: colddawn 时间: 2007-12-2 00:43

原帖由 1empress 于 2007-12-2 00:36 发表
8楼

cache一致性现在不是必需的

这篇文章作者连p4的L1是怎么构成的都不明白，其他也是抄来的东西我断定他不懂自己说什么

谢谢，回头看了一下发现是转贴，而原作者故弄血虚得说了几点却又说不清楚，真的没什么意思。
如果现在不是必须的话，我是否可以理解暂时可以在操作系统现在暂时不用有所作为？那共享缓存结构要么是硬件电路实现了缓存锁，要么是没有锁会导致数据不一致，结果就是可能会出现性能衰退或有理论上的互相共享的数据有暴露敏感信息的隐患，一如当时的HT？不知道这个L3的性能问题是不是也卡在类似的地方了，说不定AMD在给MS塞钱做补丁呢
:loveliness:

作者: colddawn 时间: 2007-12-2 00:45

原帖由 晶晶守护神 于 2007-12-2 00:39 发表

炒作系统本来就支持支持同步哒共享同步一定是是硬件实现的～～～其实共享L2／L3比单独的好灵活性高还可以通信

你NB,什么事情让你一说怎么都这么简单，照你这么说现在XP都能跑K二十几了，还可以拖到L十几的缓存都没有性能问题。

作者: itany 时间: 2007-12-2 01:29

原帖由 colddawn 于 2007-12-2 00:33 发表
问一下第6点，对于L2/L3的共享缓存，到底是怎么实现多硬件线程并发访问时的同步控制的？有单独的锁缓存指令吗？能细到什么粒度？如果有的话那肯定可以确认是需要操作系统支持了，会有补丁？

AMD的缓存一致性当然不是通过加锁来实现的，而是通过MEOSI协议在缓存行的标志位上打上特定的标记来实现的
加锁的话，貌似只是OS用来同步不同线程对于内存访问的时候采用的吧

作者: itany 时间: 2007-12-2 01:32

原帖由紫色于 2007-12-1 22:59 发表
其它东西都是虚的，多半只能YY下的。intel的杀手锏其实也就是4指令发射。

文章的作者只能分清楚3和4，因为这个最清楚了

Conroe的4发射结构的潜力还远没有开发出来，等着超线程的回归吧，到时候让AMD知道什么才是真正的4发射

作者: tedsun 时间: 2007-12-2 02:19
X86体系，只有8个通用寄存器（注意，是8个，不能多，否则以前的软件统统不兼容，当然，当年的X86在科学家的努力下，实现了寄存器重名名技术。这是一个了不起的大发明），:funk:

作者: Prescott 时间: 2007-12-2 02:21

原帖由 colddawn 于 2007-12-2 00:33 发表
问一下第6点，对于L2/L3的共享缓存，到底是怎么实现多硬件线程并发访问时的同步控制的？有单独的锁缓存指令吗？能细到什么粒度？如果有的话那肯定可以确认是需要操作系统支持了，会有补丁？

缓存对用户代码透明，缓存一致性由硬件保证，无需软件插手

作者: 晶晶守护神 时间: 2007-12-2 02:40
提示: 作者被禁止或删除内容自动屏蔽

作者: 蒋PJ 时间: 2007-12-3 16:09
"不过HT的速度(说带宽更合适)再高，也就是3.Gbps左右，比起L2的访问速度10GB/s以上，不足一提。"这个明显是概念错误~!:lol: 把带宽和速度混为一坛,HT3.0总线是内存的总线,不是不能写,如果不能写,CPU怎么处理内存的信息?它在服务器配置里作用是直接U与U的沟通通道,不必像INTEL由芯片组管理,速度和效率更高,INTEL的至强在未来的1年中估计会实现这个技术,由PCI-E 3.0通道沟通,不必再往芯片组上绕了.至于能不能写这个没什么大的意义,如果需要内存的总线上本来就有写的功能啊,以上都是基于内存控制器内置与U中的结果.L1比L2的速度会更快,这样比比有什么意义吗?作为内存总线的话,速度只要不低于内存的速度就OK了,太高了也没意义了,试问现在桌面平台有用超过2G速度的内存吗?答案是否定的!带宽上HT3.0总线远远超过了PCI E2.0的带宽,这正是INTEL的软肋,PCI E3.0才是INTEL最具划时代意义的应用技术,不亚于推出扣肉框架的意义.不过大家还得等个1年吧.还有就是AMD和INTEL的L1和L2之间的运做方式不是一样的,AMD的是更直接的L1满到L2中,L2满了到L3中,加快在内存中的隐射和在系统速度上的缓冲,INTEL的模式是更像是分工方式,INTEL的L1和L2之间分到的工作是不大相同的.关于3和4的问题,这个对现在的U的性能还没有更大的影响,INTEL现在最需要解决的是通过提高败于AMD前端总线的带宽上,这也是对系统性能提升上的现阶段最有意义的事情了.内存性能上INTEL要在X38 X48上给AMD重重的一击,这个翻身仗的结果是可以料想.:p :p

作者: 蒙大拿 时间: 2007-12-3 16:13
:whistling: K10好、K10好、K10主义社会人民生活高、、、
全国人民大团结，掀起了K10主义建设高潮、建设高潮、、、

作者: 蒋PJ 时间: 2007-12-3 16:15
还有就是加一句,HT3.0总线的实际带宽是20G以上,INTEL现在实际是10G以上,都不是理论值,理论值高.

作者: 哈哈小刀 时间: 2007-12-3 17:39
提示: 作者被禁止或删除内容自动屏蔽

作者: the_god_of_pig 时间: 2007-12-3 18:17
还是EPIC好啊:rolleyes:

作者: the_god_of_pig 时间: 2007-12-3 18:18

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

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

您真幽默:sweatingbullets:

作者: ITANIUM2 时间: 2007-12-3 18:35
在Nehalem没出来前, A记的IMC和HTT还是领先的:rolleyes:

作者: chairmanai 时间: 2007-12-3 18:35

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

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

本帖亮点出现:thumbsup:

作者: colddawn 时间: 2007-12-3 19:06

原帖由 Prescott 于 2007-12-2 02:21 发表

缓存对用户代码透明，缓存一致性由硬件保证，无需软件插手

这个知道,我意思是硬件保证同步的同时必然带来时延,有时必要向操作系统暴露一些同步细节可以使系统在线程调度行为时尽量避免出现需要硬件进行同步的情况,否则就有可能出现在某种情况下两个核心的缓存行为出现较强烈的竞态导致性能回退,有点类似于NT5到NT6升级时加入对HT相对SMP不同级的调度策略,从而使HT性能更好这样的考虑.我也知道这个例子不太恰当,缓存的硬件同步代价比这个例子小得多,但如果是加入了L3的话,相信开销也是一个不得不考虑的问题,K10的L3性能提升,估计从系统层面可作的优化会更多.比如应该要有CPU提供并操作系统使用LOAD数据并锁定在L3的指令吧。

作者: itany 时间: 2007-12-3 19:12

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

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

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

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

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

作者: colddawn 时间: 2007-12-3 19:17

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

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

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

作者: xiaolongzi 时间: 2007-12-3 19:20
看了几家评测。感觉确实K10没有对酷睿2有什么技术上的优势。且AMD始终对K10的频率提升没什么办法。

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

作者: itany 时间: 2007-12-3 19:32

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

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

作者: colddawn 时间: 2007-12-3 19:34

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

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

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

作者: itany 时间: 2007-12-3 19:43

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

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

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

作者: colddawn 时间: 2007-12-3 19:50

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

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

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

作者: itany 时间: 2007-12-3 20:00

原帖由 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 时间: 2007-12-3 20:22

原帖由 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出来再对比，我认为看热闹最有意思。

作者: 脸色 时间: 2007-12-3 20:39
看热闹吧:loveliness:

作者: potomac 时间: 2007-12-3 20:52
提示: 作者被禁止或删除内容自动屏蔽

作者: acqwer 时间: 2007-12-3 21:04

原帖由 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)。

作者: bessel 时间: 2007-12-3 21:16
这个俺不信。

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

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

作者: 鲁爾 时间: 2007-12-3 21:40
进来看看……:unsure:

作者: itany 时间: 2007-12-3 22:14

原帖由 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是因为功耗实在抗不住了

作者: feixiaoyu 时间: 2007-12-4 10:26
这个论坛好多人，，不懂装懂，懂一点光充老大。:funk:

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

作者: kisazhu 时间: 2007-12-4 13:07

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

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

这才是GZ的技术含量

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

欢迎光临 POPPUR爱换 (https://we.poppur.com/)