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

蒋PJ

还 有就是加一句,HT3.0总线的实际带宽是20G以上,INTEL现在实际是10G以上,都不是理论值,理论值高.

the_god_of_pig

还是EPIC好啊:rolleyes:

the_god_of_pig

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

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

您真幽默:sweatingbullets:

ITANIUM2

在Nehalem没出来前, A记的IMC和HTT还是领先的:rolleyes:

chairmanai

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

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

本帖亮点出现:thumbsup:

colddawn

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

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

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

itany

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


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

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

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

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

colddawn

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


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

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

xiaolongzi

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

colddawn

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

itany

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

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

colddawn

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


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

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


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

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

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 20:00 发表


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

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

脸色

看热闹吧:loveliness:

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)。