多路系统K10优势的启示

Ricepig

原帖由 紫色 于 2007-9-15 00:40 发表
对。不过我这里不谈那个问题。
我的程序说白了就是把(sin(real(i,10))*sin(real(i,10)*2)/cos(real(i,10)))/cos(real(i,10)*2)  从1算到8亿，
这公式显然只会涉及到浮点乘除，不会涉及到sse指令集里面的图形图 ...

其实你可以试着看看反汇编后这行语句对应的汇编命令，很有可能它根本没有用SSE指令。
有些编译器没有这么智能，不会自动把一些无关联的循环内的运算展开，然后使用SSE优化。何况你这里好像还用了OpenMP，它会做预处理，处理后的代码可能更不好对SSE优化。
其实SSE的应用也远没有非SSE多，主要是因为SIMD有其自身对算法或数据结构的限制。它要求有大量重复不关联数据需要进行同样运算，这时SSE效率很高。在重复数据不多的情况下，有的时候还是放弃SSE指令，因为SSE指令和一些普通指令同时执行的话，CPU会有一个比较长时间的延迟作为惩罚。
现在的趋势看，SSE能做的，显卡很多也能做了，而且效率比CPU高好多，估计以后的一段时间，计算将向片外转移了。Herb Sutter也就此写了一篇文章。大家可以搜来看看。

紫色

[quote]原帖由 Prescott 于 2007-9-15 01:35 发表


GNUfortran比其他任何编译器都不只慢一点点，你喜欢我也没办法。写写代码也可以，实际上线跑也用gfortran那是和自己的机时过不去。

如果你觉得写一个根本不可能用SSE优化的源代码来证明SSE没有用，这种做法很有趣，那你就继续自己玩吧。或者你就是喜欢X87，还有人就是喜欢唱片呢，起码也显得品味啊。
A7BhhvRfwe.pcinlife.comZ2l;~ m'{]
J

紫色

原帖由 Ricepig 于 2007-9-15 01:53 发表

其实你可以试着看看反汇编后这行语句对应的汇编命令，很有可能它根本没有用SSE指令。
有些编译器没有这么智能，不会自动把一些无关联的循环内的运算展开，然后使用SSE优化。何况你这里好像还用了OpenMP，它会 ...

你说的也许是对的吧。
我只是给编译器加上选项，要求它的浮点运算是使用sse单元或者387。
结果到底是怎么样，我不知道。

boris_lee

原帖由 紫色 于 2007-9-15 00:40 发表
对。不过我这里不谈那个问题。
这公式只涉及到浮点乘除，不涉及sse指令集里面的图形图像那些指令（ 不涉及sse指令集里面的图形图像那些指令（那些指令我永远都用不上，别人当然会有用)...

你的科学计算不包括矢量运算的？ 另外HLO还是比较重要的（以下为ZT)

SSE Vectorizer：就是将许多操作SSE 矢量化，例如

1. <!--ec1-->for(int i=0;i<100;i++)
   
2. {
   
3.     c[i]=a[i]+b[i];
   
4. }<!--c2--><!--ec2-->

复制代码

转换成

1. for(int i=0;i<100;i+=4)
   
2. {
   
3.     c[i]=a[i]+b[i];
   
4.     c[i+1]=a[i+1]+b[i+1];
   
5.     c[i+2]=a[i+2]+b[i+2];
   
6.     c[i+3]=a[i+3]+b[i+3];
   
7. }
   
8. 其中
   
9.     c[i]=a[i]+b[i];
   
10.     c[i+1]=a[i+1]+b[i+1];
    
11.     c[i+2]=a[i+2]+b[i+2];
    
12.     c[i+3]=a[i+3]+b[i+3];

复制代码

使用一个SSE指令，这样整个循环减少为原来的1/4，实际编译成二进制代码后所花费的时间应该减少为原来的1/4~1/3。上面只是一个例子，实际上可以对很多操作都可以这样优化，而不仅仅使用SSE做浮点运算

acqwer

原帖由 紫色 于 2007-9-14 23:43 发表
还有,巴塞罗那的sse性能有网站出测试结果没有？

zVisuel基本上是靠SSE在跑，巴塞罗那提升了50%。

巴塞罗那的linpack成绩也差不多提升了50%。当然，你不会认为K10浮点上比K8翻倍的4fp/cycle是靠X87跑出来的吧。

Edison

K10的Linpack成绩理论上应该是快100%的，50%的那个成绩是因为anandtech用的是Intel的linpack 1000修改版。

Prescott

原帖由 1empress 于 2007-9-15 12:46 发表
支持紫色

鄙视一下Prescott的顾左右而言其他


没有一点实事求是的态度

不懂就不要瞎掺乎，那个紫色要么就是不懂什么叫SSE2，要么纯粹就是无理取闹。
看看下面这段代码，也就是那个测试程序核心的计算部分。
do i=1_8,N
   if(mod(i,N/100)==0)  print *,i/(N/100),omp_get_thread_num()
   tmp=tan(real(i,10))*tan(real(i,10)*2)  
   fu=fu*tmp
enddo

1. 强制使用80bit的long double类型，SSE2根本就不支持这种类型，我不知道GNU Fortran编译器如何处理这种情况，很可能会强制使用X87而不是违抗程序员的意图去降低精度

2. 核心的计算每个循环中，就是tan(x) * tan(x*2)，tan(x)是直接调用gibm，编译器无法作任何改变，众所周知glibm不使用SSE2，何况参数是long double类型。

3. 每个循环中，tan(x)本身的计算量可能需要数百个周期，而只有总共三次乘法运算可能被向量化，也就是说即便编译器成功的unrolling这个循环，将乘法向量化，也只能获得不到1%的性能提高。

综上所述，我的结论是他要么就是不懂什么叫SSE2，要么目的就是要写一个不可能使用SSE，而且即便是用了SSE，性能提高也只有不到1%的程序。

当然那个紫色前者的可能性更大些，居然搞不清楚指令latency和throughput的关系，P4虽然一条SSE2指令要两个周期才能得到结果，但是却可以每个周期都issue一条SSE2指令。SSE2浮点吞吐量是X87的两倍都没搞清楚。

[ 本帖最后由 Prescott 于 2007-9-15 15:36 编辑 ]

紫色

ok，嘿嘿，你说的有点道理，让我发现原来我高估sse了。

这儿先挖坑。

凭什么说libm不支持sse2，
象你说的那样，tan(x)对sse优化的性能提升可以忽略不计，那么sse２对数值计算贡献更小
你的意思是p4　sse浮点性能是x87两倍？依我看p4的sse浮点性能跟x86一样。因为sse执行单元就那么多，其使用还受编译器优化限制，结果是sse对数值计算的贡献是负。同样，k10的双浮点单元的性能，也将是core2　sse浮点单元的理论上限。所以对数值计算程序而言，真不如barcelona那样老老实实增加一个浮点单元（同时提高提高sse性能）。

[ 本帖最后由 紫色 于 2007-9-15 16:02 编辑 ]

acqwer

原帖由 紫色 于 2007-9-15 15:24 发表
ok，嘿嘿，你说的有点道理，让我发现原来我高估sse了。

这儿先挖坑。

凭什么说libm不支持sse2，
象你说的那样，tan(x)对sse优化的性能提升可以忽略不计，那么sse２对数值计算贡献更小
p4 xeon的sse浮点 ...

Bercelona没增加浮点单元。

Prescott

原帖由 紫色 于 2007-9-15 15:24 发表
凭什么说libm不支持sse2，
象你说的那样，tan(x)对sse优化的性能提升可以忽略不计，那么sse２对数值计算贡献更小
p4 xeon的sse浮点性能跟x86一样。上面那位说sse使用还受编译器优化限制，那么p4里的sse对科学计算的贡献是负数。
所以对数值计算程序而言，真不如barcelona那样老老实实增加一个浮点单元（同时提高提高sse性能）。

第一，我是说libm的tan(x)没有使用SSE2，并不是说SSE2对tan(x)没有效果，你要看清楚。
第二，强烈支持您购买Barcelona，并且坚持使用x87，然后找AMD打官司：“明明Barcelona浮点性能和K7一样，一个周期一个浮点运算，却误导用户是一个周期4个”。千万不要买Intel的处理器，Intel可没工夫陪你打官司。

紫色

什么官司不官司的。
把程序改成kind=8，两个速度还是一样（这次连１秒的差距都没有）。我使用kind=10习惯了
只能说明，sse对数值计算几乎帮不上忙。

[ 本帖最后由 紫色 于 2007-9-15 16:41 编辑 ]

acqwer

原帖由 紫色 于 2007-9-15 15:59 发表
什么官司不官司的，废话真多。
把程序改成kind=8，两个速度还是一样（这次连１秒的差距都没有）。
我使用kind=10习惯了，kind=10是x86独有，相对kind=8提高了精度且并没有增加多少计算时间。
只能说明，sse对 ...

Spec该是数值运算吧，1.4G的P4跑FP成绩是5XX，X87性能比同频P4强的P3 1.4只有4XX。

当然，你可以说SSE对你无用，但是你无法否认99%的普通用户都从SSE中获益。

Prescott

原帖由 紫色 于 2007-9-15 15:59 发表
什么官司不官司的，废话真多。
把程序改成kind=8，两个速度还是一样（这次连１秒的差距都没有）。
我使用kind=10习惯了，kind=10是x86独有，相对kind=8提高了精度且并没有增加多少计算时间。
只能说明，sse对 ...

行行行，帮不上忙，您老最正确。

大家不要再回这个帖子了，也许有一天，随着紫色的成长，他慢慢会明白的。但是现在在这里教育他是浪费他和大家的时间。

[ 本帖最后由 Prescott 于 2007-9-15 16:09 编辑 ]

itany

某人真是万佛朝宗
  只要是回复基本上都拐到SSE无用上边来……

紫色

sse有数百条指令，我当然没那个时间去了解全面sse和各个cpu的sse实现程度运行效率（和这里99.9%的人一样，我把精力花在这里能帮赚钱吗？嘿嘿），说句９０％的sse指令对我没用大概没错。剩下的１０％可能对我有用，但是我还要比较使用它跟使用x87的优劣。　

我想请教
１）barcelona所谓增加的128位浮点单元是不是就是把sse扩到128位而已，
２）barcelona执行一条128位sse指令所耗的周期是１吗？即是否与cor2相同。

那位说众所周知glibm不使用SSE2，我不相信。libm一个库而已，怎能限制别人编译时不使用sse优化？我把他编译到PPC64，ultrasparc或者是３８６又如何，编译toolchain以提高性能是常干的事情啊，libm为什么不能sse呢

[ 本帖最后由 紫色 于 2007-9-15 16:44 编辑 ]

acqwer

原帖由 紫色 于 2007-9-15 16:35 发表
１）barcelona所谓增加的128位浮点单元是不是就是把sse扩到128位而已，
２）barcelona执行一条128位sse指令所耗的周期是１吗？即是否与cor2相同。

1、是
2、否，只有加法和乘法是一个周期（运算指令中）

[ 本帖最后由 acqwer 于 2007-9-15 16:59 编辑 ]

Ricepig

原帖由 acqwer 于 2007-9-15 16:07 发表

Spec该是数值运算吧，1.4G的P4跑FP成绩是5XX，X87性能比同频P4强的P3 1.4只有4XX。

当然，你可以说SSE对你无用，但是你无法否认99%的普通用户都从SSE中获益。

99%这个数字是过分乐观了，SSE能解决的是毫无依赖一批数据的进行一致计算的能力，大部分问题目前都没有这么完美的分解方法。
也不能说SSE在科学计算里没用，只是限制比较大而已，SSE的主要领域还是在图形图像多媒体应用里。

Ricepig

原帖由 紫色 于 2007-9-15 16:35 发表
那位说众所周知glibm不使用SSE2，我不相信。libm一个库而已，怎能限制别人编译时不使用sse优化？我把他编译到PPC64，ultrasparc或者是３８６又如何，编译toolchain以提高性能是常干的事情啊，libm为什么不能sse呢

glibm是通过函数调用的，并且如果某函数块比较大，编译器是没有这个智能将其优化为SSE代码的。目前的编译器SSE优化也只限于不太复杂的循环里识别一些同类操作，然后转换为SSE指令而已。