POPPUR爱换

标题: RWT: Nehalem详解 [打印本页]

作者: Prescott 时间: 2008-4-4 17:12
标题: RWT: Nehalem详解
http://www.realworldtech.com/inc ... 2719&mode=print
原文请访问RWT

一些原先没有披露的细节：
1. L2 latency 低于12Cycle，L3在30-40 cycle之间
2. L3的设计："The advantage of an inclusive cache is that it can handle almost all coherency traffic without disturbing the private caches for each individual-core. If a cache access misses in the L3, it cannot be present in any of the L2 or L1 caches of the cores. On the other hand, Nehalem’s L3 also acts like a snoop filter for cache hits. Each cache line in the L3 contains four “core valid” bits denoting which cores may have a copy of that line in their private caches. If a “core valid” bit is set to 0, then that core cannot possibly have a copy of the cache line – while a “core valid” bit set to 1 indicates it is possible (but not guaranteed) that the core in question could have a private copy of the line. Since Nehalem uses the MESIF cache coherency protocol, as discussed previously, if two cores have valid bits, then the cache line is guaranteed to be clean (i.e. not modified). The combination of these two techniques lets the L3 cache insulate each of the cores from as much coherency traffic as possible, leaving more bandwidth available for actual data in the caches. "

性能的预期：
整数性能增长一般，HPC和浮点密集型程序将增长惊人，2倍或者更多都是有可能的（嘿嘿）。而企业级商业应用性能介于两者之间，不过，8核心的Beckton一年之后就会到来

In workloads that are not particularly bandwidth dependent, such as general integer applications, Nehalem will provide a moderate boost over the previous generation. The performance gains will largely come from the integrated memory controller, microarchitectural innovation and circuit techniques (the latter was not discussed by Intel at IDF and will probably be saved for later disclosure). For floating point and HPC workloads that are typically bandwidth bound, Nehalem will be nothing short of a miracle – with performance gains of 2X or better. Commercial server workloads such as OLTP databases, decision support and virtualization will certainly benefit from more bandwidth and lower latency as well, but not to the same extent as HPC or floating point applications. Of course, when thinking about performance it is essential to also keep time in mind – Beckton will be about a year behind Gainestown and Bloomfield.

作者: itany 时间: 2008-4-4 17:39
呵呵，P大没有说L1延迟增加了1周期…… 并不是都是好事啊
还有Nehalem把循环检测缓冲从译码器前边移到了后边，Tracing Cache又复活了……
本来预期Nehalem能拓宽取指宽度的，现在也没有变化，看来是白YY了

现在就是希望Nehalem能把频率如期拱上去了…… 当然很多人不关心官方能到多少，而是关心能超到多少 :lol:

作者: elisha 时间: 2008-4-4 17:48
看过了，很失望

作者: the_god_of_pig 时间: 2008-4-4 17:53
这个可得看:charles:

作者: GZboy 时间: 2008-4-4 18:22
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-4 19:40

原帖由 GZboy 于 2008-4-4 18:22 发表
很怀疑Nehalem单线程效率拼不拼得过现在的CORE2
难道Nehalem是拱频率的？:unsure:

Nehalem应该不会不如Core2的，废材的地方就是缓存容量变小了么，不过延迟也变小了啊，L3的延迟其实也不大了，Prescott的L2延迟也就是这个水平啊

作者: NONO 时间: 2008-4-4 19:48
INTEL應該不會再犯以前的錯，Nehalem跟同頻現在Core2相比性能只會更強，但就是不曉得強多少:unsure:

作者: ITANIUM2 时间: 2008-4-4 20:08
P大，减少二级缓存增加三级缓存会不会导致性能降低？
:a)

原帖由 itany 于 2008-4-4 19:40 发表

Nehalem应该不会不如Core2的，废材的地方就是缓存容量变小了么，不过延迟也变小了啊，L3的延迟其实也不大了，Prescott的L2延迟也就是这个水平啊

Pr***n 的二级缓存延迟大概多少？

[ 本帖最后由 ITANIUM2 于 2008-4-4 20:12 编辑 ]

作者: GZboy 时间: 2008-4-4 20:19
提示: 作者被禁止或删除内容自动屏蔽

作者: ITANIUM2 时间: 2008-4-4 20:33
还是等评测吧
怀疑是不是该买个E8x00，以后不会有这么大二级缓存的cpu YY了

作者: itany 时间: 2008-4-4 20:38

原帖由 GZboy 于 2008-4-4 20:19 发表

这个要看缓存的命中和延迟

如果拼命追求低延迟而把 L2 做的太小就会导至大量数据都要从L3里获取，这样效率不一定拼得过大L2+较高的延迟的组合

现在的CORE2是 14C

Merom是14周期，Penryn是15周期，Prescott是28周期
虽然Nehalem L2缓存减小了，但是带宽也是独享的
我想，控制L2缓存的容量一方面是减少延迟，另一方面要控制管芯面积，毕竟增加L2同时也要增加L3，还能保证核心能够上高频

现在L2缓存的延迟可能还没有最终定下来吧，我原来YY的是<=10周期的

作者: Prescott 时间: 2008-4-4 20:46

原帖由 GZboy 于 2008-4-4 18:22 发表
很怀疑Nehalem单线程效率拼不拼得过现在的CORE2
难道Nehalem是拱频率的？:unsure:

单线程性能绝大多数要高过现在的Penry，当然也会有例外。
很多HPC程序的性能真的是很吓人。

作者: itany 时间: 2008-4-4 20:49

原帖由 Prescott 于 2008-4-4 20:46 发表

单线程性能绝大多数要高过现在的Penry，当然也会有例外。
很多HPC程序的性能真的是很吓人。

嘿嘿，老大出来说话，群众就放心了

作者: 2PMM 时间: 2008-4-4 21:34
性能功耗比呢相对于PENRY:loveliness:

作者: GZboy 时间: 2008-4-4 22:57
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-4-4 23:03
提示: 作者被禁止或删除内容自动屏蔽

作者: 1empress 时间: 2008-4-4 23:06
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-4 23:06

原帖由 GZboy 于 2008-4-4 23:03 发表

在桌面方面应该提升不大，服务器方面是值得期待的~:lol:

不大也是提升啊…… :lol:

本来Intel自己也说，早年整数性能提升的很快，差不多两年多就能增加一倍，现在整数差不多要五年才能增长一倍
与此同时，浮点性能由原来的低速增长变为每两年提升一倍

桌面应用提升不大也认了，现在就是这个形势
只要在目前比较瓶颈的地方突破就行了，一个是多媒体编码和解码，一个是游戏，再一个就是科学计算
至于说PI的成绩能不能提高，无所谓了

[ 本帖最后由 itany 于 2008-4-4 23:09 编辑 ]

作者: larrabee 时间: 2008-4-4 23:15
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-4 23:19

原帖由 larrabee 于 2008-4-4 23:15 发表
我的专业就是数值算法，intel应该给我一台样机。。。

对阁下来说，Larrabee才是王道，您就自己玩自己，其乐融融吧 :lol:

作者: GZboy 时间: 2008-4-4 23:24
提示: 作者被禁止或删除内容自动屏蔽

作者: larrabee 时间: 2008-4-4 23:36
提示: 作者被禁止或删除内容自动屏蔽

作者: Katmai 时间: 2008-4-4 23:36
看来桌面平台提升不会很大，有点失望:ermm:

作者: GZboy 时间: 2008-4-4 23:50
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-5 00:13

原帖由 larrabee 于 2008-4-4 23:36 发表
很多并行程序是fork-join型spmd，也就是说各个处理器上的线程并非毫无关系，而是有父子、兄弟关系，指令有很大重复。结果是所有核心的L2中都充满了相同的内容，L2越大浪费越大，而核心有可能仍然饥渴。所以还不如象n ...

的确可能是相同的指令创建几个线程到不同的核心上执行，但是别忘了这些线程的数据集并不相同。L2跟L1不一样，除了缓存指令还要缓存数据的

作者: itany 时间: 2008-4-5 00:15

原帖由 GZboy 于 2008-4-4 23:50 发表

如果是这样直接取消L3，SHARE L2不是会更好吗？

四个物理核心，八个逻辑核心，如狼似虎，如果就共享256bit的L2总线位宽，那是憋的相当难受啊

作者: lacri 时间: 2008-4-5 13:28
L2真的好小。另外，不知是否已经出样了？

作者: itany 时间: 2008-4-5 13:56

原帖由 lacri 于 2008-4-5 13:28 发表
L2真的好小。另外，不知是否已经出样了？

http://we.pcinlife.com/thread-911350-1-3.html

作者: bessel 时间: 2008-4-5 14:06

原帖由 lacri 于 2008-4-5 13:28 发表
L2真的好小。另外，不知是否已经出样了？

作者: bessel 时间: 2008-4-5 14:07
啧啧。
:lol:

原帖由 larrabee 于 2008-4-4 23:36 发表
很多并行程序是fork-join型spmd，也就是说各个处理器上的线程并非毫无关系，而是有父子、兄弟关系，指令有很大重复。结果是所有核心的L2中都充满了相同的内容，L2越大浪费越大，而核心有可能仍然饥渴。所以还不如象nehalem这样4*256k+8M的方式，这是比较适合高性能计算的设计。相反如果8个线程毫无关系，那么大L2设计的penryn及其胶水4核更有利些。也许intel认为桌面计算双核心就足够了，而且，很有可能，nehalem对penryn的桌面性能提高也就仅仅是来自集成内存控制器的贡献，类似于从k7到k8。

作者: bessel 时间: 2008-4-5 14:09
L1延迟增加了可以飙频率嘛，呵呵。

原帖由 itany 于 2008-4-4 17:39 发表
呵呵，P大没有说L1延迟增加了1周期…… 并不是都是好事啊
还有Nehalem把循环检测缓冲从译码器前边移到了后边，Tracing Cache又复活了……
本来预期Nehalem能拓宽取指宽度的，现在也没有变化，看来是白YY了

现 ...

作者: bessel 时间: 2008-4-5 14:12
smt对于fp rate能有多少贡献啊，老P给泄点嘛。

原帖由 Prescott 于 2008-4-4 20:46 发表
单线程性能绝大多数要高过现在的Penry，当然也会有例外。
很多HPC程序的性能真的是很吓人。

作者: ITANIUM2 时间: 2008-4-5 22:16
期待版上出现测试成绩 :lol:

作者: larrabee 时间: 2008-4-5 22:36
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-5 22:57

原帖由 larrabee 于 2008-4-5 22:36 发表
安照RWT的分析，引入三通道是因为SMT带来的对带宽的需求，那么三通道就应付不了原生8核心16线程：双通道都满足不了4核心，三通道怎么能满足8核心呢。intel何不引入xdr2呢？那才是完美的处理器。

上边说Nehalem-EX八核心是Xeon MP，搭配四通道FB-DIMM DDR3的
另外，个人觉得说为了SMT才配备的三通道完全是胡说
Dunnington 6核心，四插座加起来才四通道FB-DIMM 667，带宽才21GB/s，每个插座才5GB/s；Nehalem单个插座就已经32GB/s；Nehalem-EX每个插座43GB/s。Nehalem-EX平均每个核心是Dunnington带宽的6倍！
显然并不仅仅是给超线程准备的
个人觉得是给Sandy Bridge这样下一代怪兽预留的带宽，这一代未必能充分利用，毕竟一个插座要用好几年的，向DDR4过渡还为时尚早

作者: bessel 时间: 2008-4-5 23:57
矢量机达到这个带宽是1996年,nec sx-4。
sigh.

原帖由 itany 于 2008-4-5 22:57 发表
上边说Nehalem-EX八核心是Xeon MP，搭配四通道FB-DIMM DDR3的
另外，个人觉得说为了SMT才配备的三通道完全是胡说
Dunnington 6核心，四插座加起来才四通道FB-DIMM 667，带宽才21GB/s，每个插座才5GB/s；Nehale ...

作者: 贵族蓝翼 时间: 2008-4-6 00:02
提示: 作者被禁止或删除内容自动屏蔽

作者: agooday 时间: 2008-4-6 01:00
和AMD的结构有点像，不约而同？

作者: larrabee 时间: 2008-4-6 01:13
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-6 01:21

原帖由 larrabee 于 2008-4-6 01:13 发表
呵呵，虽然说永远总是下一个更好，但有些东西很经典，nehalem天生就注定了是经典。

优化课程中，注意simd操作数的内存对齐是标准内容，但现在也不必了。刚刚看到，nehalem对非对齐的sse擦作数的延迟与对齐的一样， ...

想想Sandy Bridge的256位AVX指令集，就心潮澎湃啊
而且万一Intel心血来潮，把Larrabee也插到Xeon的洞洞里呢？ :lol:

Nehalem的最大历史贡献，应该就是为了未来若干年奠定了系统结构上的坚实基础ba

[ 本帖最后由 itany 于 2008-4-6 01:22 编辑 ]

作者: larrabee 时间: 2008-4-6 10:21
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-4-7 01:50
说实话，A社的GPGPU还是给Intel很多灵感的 :lol:

作者: elisha 时间: 2008-4-8 22:40

原帖由 itany 于 2008-4-7 01:50 发表
说实话，A社的GPGPU还是给Intel很多灵感的 :lol:

没有Cell来得多吧

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