Clovertown的科学性能太渣了点吧

bessel

一般科学计算最多是受内存带宽限制，延时可以想办法隐藏掉。
上面那个4B/flops还不是最极端的。

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

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

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

Prescott

原帖由 bessel 于 2007-11-26 23:20 发表
有这么大内存带宽还要缓存干啥？

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

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

[ 本帖最后由 Prescott 于 2007-11-26 23:46 编辑 ]

bessel

有这么大内存带宽还要缓存干啥？

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

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


只不过是对于特殊类型的应用不敏感罢了。
换了Oracle的数据库，任你上TB/s的带宽，没有缓存照样歇菜。

古墓熊影

真正要求性能的科学计算都是直接利用批处理计算，哪会这样搞。:huh:

Prescott

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

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

只不过是对于特殊类型的应用不敏感罢了。
换了Oracle的数据库，任你上TB/s的带宽，没有缓存照样歇菜。

bessel

特殊结构无非是堆钱罢了，呵呵。

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

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

Ricepig

流处理器或者是向量机中，Cache的作用是没有那么大的

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

Google用的处理器都不是最快的，但是Google拥有的计算能力是惊人的。

Prescott

原帖由 RacingPHT 于 2007-11-26 18:21 发表
受教
不过如果根本没有办法把FSB降下来, 那怎么办?你应该不会否认稀疏矩阵对科学/模拟计算的意义吧。包括稠密矩阵, 也是一样的, 算法本身就有固定的flop/bw比值。

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

降FSB还是有很多办法的，如果根本降不下来那只好认输呗，顺便阿Q一下Nehalem了。

bessel

most of vector machine have NO cache.

:p

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



呵呵，你说的有道理，但也不要太极端了，不然还需要CPU缓存干什么？

bessel

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的情 ...

Prescott

原帖由 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 编辑 ]

HuaErZ

这些和我们没什么关系吧。
我只关心CPU的渲染能力。