POPPUR爱换

标题: Clovertown的科学性能太渣了点吧 [打印本页]
作者: RacingPHT    时间: 2007-11-25 15:02
提示: 作者被禁止或删除 内容自动屏蔽
作者: acqwer    时间: 2007-11-25 16:06
Clovertown的内存带宽跑到了11G……莫非测试时用的是2400FSB的U？
作者: RacingPHT    时间: 2007-11-25 16:15
提示: 作者被禁止或删除 内容自动屏蔽
作者: itany    时间: 2007-11-25 16:44
科学计算！=拼内存带宽

  :sleeping:
作者: acqwer    时间: 2007-11-25 17:01
原帖由 RacingPHT 于 2007-11-25 16:15 发表
1333 FSB * 64bit = 10.6G/s
加上是2x Socket, 所以peak是21.3G/s
跑11G/s, 只到peak的一半

双路的Xeon测评我也看过不少，带宽跑到7G的都没看到过。
作者: bessel    时间: 2007-11-25 17:19
Their code is better than the benchmark.

It is said AMD has a code which can run 13GB/s with k10.

原帖由 acqwer 于 2007-11-25 17:01 发表

双路的Xeon测评我也看过不少，带宽跑到7G的都没看到过。
作者: bessel    时间: 2007-11-25 17:25
In certain cases scientific computing is limited by memory bandwidth only,
and those users have no choice.
That is why NEC are still building their very expensive vector machines.
their sx9 has 4TB/s in one node.


原帖由 itany 于 2007-11-25 16:44 发表
科学计算！=拼内存带宽

  :sleeping:
作者: acqwer    时间: 2007-11-25 17:30
原帖由 bessel 于 2007-11-25 17:19 发表
Their code is better than the benchmark.

It is said AMD has a code which can run 13GB/s with k10.


K10跑到13G很稀奇吗？把这里的内存从667换成800就差不多了吧。


[ 本帖最后由 acqwer 于 2007-11-25 17:33 编辑 ]
作者: RacingPHT    时间: 2007-11-25 17:32
提示: 作者被禁止或删除 内容自动屏蔽
作者: RacingPHT    时间: 2007-11-25 17:33
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-25 17:37
This  result is  very good for FSB,:sweatingbullets:

% of configuration peak bandwidth:
amd: 62.6%
intel: 52.7%



原帖由 RacingPHT 于 2007-11-25 16
:15 发表
1333 FSB * 64bit = 10.6G/s
加上是2x Socket, 所以peak是21.3G/s
跑11G/s, 只到peak的一半
作者: bessel    时间: 2007-11-25 17:38
4 core ,single socket.
but only AMD has this bench.

:shifty:
原帖由 RacingPHT 于 2007-11-25 17:32 发表

single core? single socket?
作者: RacingPHT    时间: 2007-11-25 17:46
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-25 17:55
FPU is limited by memory bandwidth,
FPU is kept on waiting for the data.

Flops is proportional to memory bandwidth
for amd:  13.35GB/s ,3.31 GF/s        4.03B/flop
for intel:   11.24GB/s,  2.79 GF/s       4.03B/flop

原帖由 RacingPHT 于 2007-11-25 17:46 发表

but not for the FPUs.
2.79 GF/s (3.7%)
作者: acqwer    时间: 2007-11-25 17:56
原帖由 RacingPHT 于 2007-11-25 17:33 发表


那你也要看benchmark是怎么写的。benckmark侧不出来是他的事。

基本上，内存带宽的测试方式都是一样的吧。
作者: RacingPHT    时间: 2007-11-25 18:23
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-25 19:01
你贴的文章中有写啊。

btw:这文章和作者都不错。

原帖由 RacingPHT 于 2007-11-25 18:23 发表


这是没错, 问题在: 为什么FSB只能用到50%? 而CELL可以用到90%+?

[ 本帖最后由 bessel 于 2007-11-26 03:10 编辑 ]
作者: Prescott    时间: 2007-11-25 20:19
原帖由 RacingPHT 于 2007-11-25 15:02 发表
http://www.cs.berkeley.edu/~samw/research/papers/sc07.pdf
8个核心的Clovertown系统被4核心的X2玩死了, 人间罕见啊。

Clovertown只要数据不在cache中, FSB的性能就奇烂
page 8


搞个测试，两个单核心的Opteron玩死两个Clovertown也不奇怪。
换另外一个测试，一个E6550玩死4个Barcelona也不是不可能。

上面的例子都是实际工作中碰到的，不是臆断。

至于Clovertown科学性能到底怎么样，最近的Top500排名早就给出了答案。如果Clovertown的内存带宽不是问题，这个世界上还有什么处理器是Clovertown的对手？

[ 本帖最后由 Prescott 于 2007-11-25 21:35 编辑 ]
作者: potomac    时间: 2007-11-25 21:19
提示: 作者被禁止或删除 内容自动屏蔽
作者: HardCoded    时间: 2007-11-25 22:33
原帖由 itany 于 2007-11-25 16:44 发表
科学计算！=拼内存带宽

  :sleeping:



科学计算很多种的,有的却是湿拼内存带宽,有的拼内存延迟.
作者: 鲁爾    时间: 2007-11-25 22:35
原帖由 itany 于 2007-11-25 16:44 发表
科学计算！=拼内存带宽

  :sleeping:


:lol: :lol:
作者: HardCoded    时间: 2007-11-25 22:35
Intel CSI一来,我看AMD还怎么跳!!!
作者: 紫色    时间: 2007-11-25 23:09
intel的智能内存+大缓存能应付office,IE，但是在一个数组就有2G的那些数值计算程序面前显然力不从心，酷睿就象个跛子，一条腿长一条腿短。
作者: itany    时间: 2007-11-25 23:25
原帖由 紫色 于 2007-11-25 23:09 发表
intel的智能内存+大缓存能应付office,IE，但是在一个数组就有2G的那些数值计算程序面前显然力不从心，酷睿就象个跛子，一条腿长一条腿短。


酷睿像跛子？那Opteron就可以去参加某刚闭幕不久的运动会了……
一个数组2GB？先看看一个Node的内存能不能放得下再说吧……
另外，谁说酷睿的缓存技术对于一个数组2GB的应用就无能为力了？缓存的最浅显机理就是空间重复性和时间重复性，这一点没搞清楚就来说事，还不如陪同Op一起去参赛呢
作者: HardCoded    时间: 2007-11-25 23:40
原帖由 紫色 于 2007-11-25 23:09 发表
intel的智能内存+大缓存能应付office,IE，但是在一个数组就有2G的那些数值计算程序面前显然力不从心，酷睿就象个跛子，一条腿长一条腿短。




这样的算法确实不能体现L2的作用, 不是肉不行,而是这个算法确实体现不出L2的预测作用, 不信拿同频不同L2的肉比比,不会有任何区别.

for (i = 0; i < m; ++i) {
double y0 = y;
for (k = ptr; k < ptr[i+1]; ++k)
y0 += val[k] * x[ind[k]];
y = y0;
}



:w00t):

改成这样,肉立马翻盘:
for (i = 0; i < m; ++i) {
double y0 = y;
for (k = ptr; k < ptr[i+1]; ++k)
y0 += val[k] * x[ind[k]] * val[k-1] * x[ind[k-1]];
y = y0;
}
作者: 紫色    时间: 2007-11-26 00:09
一个数组2G不奇怪。
谁告诉你那些是重复性操作了？象matlab,fortran这样的语言都提供“mask矩阵”之类的东西，想预测下一个该操作的是哪个数组元素？难着呢。
作者: itany    时间: 2007-11-26 01:08
原帖由 紫色 于 2007-11-26 00:09 发表
一个数组2G不奇怪。
谁告诉你那些是重复性操作了？象matlab,fortran这样的语言都提供“mask矩阵”之类的东西，想预测下一个该操作的是哪个数组元素？难着呢。


2GB的矩阵mask要多少内存? 阁下
作者: bessel    时间: 2007-11-26 03:09
你们说的这个mask矩阵什么意思？

原帖由 itany 于 2007-11-26 01:08 发表


2GB的矩阵mask要多少内存? 阁下
作者: HardCoded    时间: 2007-11-26 09:10
原帖由 紫色 于 2007-11-26 00:09 发表
一个数组2G不奇怪。
谁告诉你那些是重复性操作了？象matlab,fortran这样的语言都提供“mask矩阵”之类的东西，想预测下一个该操作的是哪个数组元素？难着呢。



呵呵，你说的有道理，但也不要太极端了，不然还需要CPU缓存干什么？
作者: HuaErZ    时间: 2007-11-26 11:16
这些和我们没什么关系吧。
我只关心CPU的渲染能力。
作者: RacingPHT    时间: 2007-11-26 13:50
提示: 作者被禁止或删除 内容自动屏蔽
作者: Prescott    时间: 2007-11-26 14:26
原帖由 RacingPHT 于 2007-11-26 13:50 发表




拼单核心的当然不是没有可能, 比如superpi ?

但是如果是多线程的话, 大概是什么情况呢?

我当然不是指单线程，单线程E6550赢过今年能买到的任何Barcelona都没问题。
其实任何系统都是有短板的，Clovertown系统的短板就是FSB，如果一个程序在Clovertown上面大幅度落后于Barcelona或者Opteron，99%的情况是FSB满了。所以，如果针对Clovertown系统作优化，基本上就是两板斧：1. 向量化。2.把FSB使用降下来。
Opteron一样也有问题，比较大的问题就是1.NUMA，HT带宽不够。2.缓存太小。3.核心太弱。幸运的是，这些问题都不太容易造成大幅度的下降。总的来说，Opteron的短板要少一些。
所以，Opteron要击败Clovertown很简单，找一个对内存带宽需求超过11GB/s的程序，Clovertown就输定了，如果超过15GB/s，两个Opteron就可以打平4个Tigerton。反过来，只要内存带宽需求不超过11GB/s，Barcelona几乎就输定了，如果对缓存的需求在4MB到8MB/12MB之间，Barcelona就输得裤子都没有了。
很不幸，你的那篇文章中，每FLOPS需要4个Byte/s的内存带宽。这超出了任何一个系统的内存带宽和FLOPS的比值，最终所有的系统都被内存带宽限制，变成了内存带宽测试。所以你的题目改成：“Clovertown的内存性能相对它的浮点处理能力太渣了点吧”，我就没法有任何意见了。

[ 本帖最后由 Prescott 于 2007-11-26 14:30 编辑 ]
作者: RacingPHT    时间: 2007-11-26 18:21
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-26 18:52
for dense matrix, cache works very well.
blas3/lapack routines can get more than 80% of cpu's peak performance.


for sparse matrix, try to buy a machine with more bandwidth is the only way.
However, flop/bw=4 is the extreme case.
原帖由 RacingPHT 于 2007-11-26 18:21 发表
受教
不过如果根本没有办法把FSB降下来, 那怎么办?你应该不会否认稀疏矩阵对科学/模拟计算的意义吧。包括稠密矩阵, 也是一样的, 算法本身就有固定的flop/bw比值。

幸好一般常用的程序, working set是大于4MB的情 ...
作者: bessel    时间: 2007-11-26 18:54
most of vector machine have NO cache.

:p

原帖由 HardCoded 于 2007-11-26 09:10 发表



呵呵，你说的有道理，但也不要太极端了，不然还需要CPU缓存干什么？
作者: Prescott    时间: 2007-11-26 19:08
原帖由 RacingPHT 于 2007-11-26 18:21 发表
受教
不过如果根本没有办法把FSB降下来, 那怎么办?你应该不会否认稀疏矩阵对科学/模拟计算的意义吧。包括稠密矩阵, 也是一样的, 算法本身就有固定的flop/bw比值。

幸好一般常用的程序, working set是大于4MB的情 ...


降FSB还是有很多办法的，如果根本降不下来那只好认输呗，顺便阿Q一下Nehalem了。
作者: potomac    时间: 2007-11-26 19:09
提示: 作者被禁止或删除 内容自动屏蔽
作者: RacingPHT    时间: 2007-11-26 19:30
提示: 作者被禁止或删除 内容自动屏蔽
作者: Ricepig    时间: 2007-11-26 19:31
流处理器或者是向量机中，Cache的作用是没有那么大的

楼上的，用菜羊不值得啊。不过确实也可以组成强力处理器阵列。

Google用的处理器都不是最快的，但是Google拥有的计算能力是惊人的。
作者: RacingPHT    时间: 2007-11-26 19:33
提示: 作者被禁止或删除 内容自动屏蔽
作者: potomac    时间: 2007-11-26 20:43
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-26 22:04
特殊结构无非是堆钱罢了，呵呵。


原帖由 potomac 于 2007-11-26 20:43 发表
缓存只是由于矢量机往往有特殊结构处理带宽问题，所以不再敏感。

对于一般结构搭建的平台，还是非常重要的。
作者: Prescott    时间: 2007-11-26 22:18
原帖由 potomac 于 2007-11-26 20:43 发表
缓存只是由于矢量机往往有特殊结构处理带宽问题，所以不再敏感。

对于一般结构搭建的平台，还是非常重要的。


只不过是对于特殊类型的应用不敏感罢了。
换了Oracle的数据库，任你上TB/s的带宽，没有缓存照样歇菜。
作者: 古墓熊影    时间: 2007-11-26 22:42
真正要求性能的科学计算都是直接利用批处理计算，哪会这样搞。:huh:
作者: bessel    时间: 2007-11-26 23:20
有这么大内存带宽还要缓存干啥？

缓存就是要解决内存带宽不够的问题，满足90%的应用罢了。

原帖由 Prescott 于 2007-11-26 22:18 发表


只不过是对于特殊类型的应用不敏感罢了。
换了Oracle的数据库，任你上TB/s的带宽，没有缓存照样歇菜。
作者: Prescott    时间: 2007-11-26 23:45
原帖由 bessel 于 2007-11-26 23:20 发表
有这么大内存带宽还要缓存干啥？

缓存就是要解决内存带宽不够的问题，满足90%的应用罢了。


内存带宽和延时可不一样，缓存主要还是解决延时的问题。内存可以做到带宽和缓存差不多，但是却永远没办法做到延时差不多。

[ 本帖最后由 Prescott 于 2007-11-26 23:46 编辑 ]
作者: RacingPHT    时间: 2007-11-27 10:04
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-11-28 00:35
一般科学计算最多是受内存带宽限制，延时可以想办法隐藏掉。
上面那个4B/flops还不是最极端的。

缓存解决了延时和带宽两个问题，主流处理器内存带宽从没有做到和缓存差不多的时候。
日本的矢量机通常有较多的register，缓存=0。
cray新设计的矢量机从x1开始倒是焊上了cache，估计是懒得解决延时的问题，而且还会便宜不少。

原帖由 Prescott 于 2007-11-26 23:45 发表

内存带宽和延时可不一样，缓存主要还是解决延时的问题。内存可以做到带宽和缓存差不多，但是却永远没办法做到延时差不多。




欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4