那位编程举个例子, 把sse的"威力"释放一下?

acqwer

原帖由 紫色 于 2007-9-30 12:05 发表


我没有看到那个程序的源码，不敢说更多。
质数判定可能是整数编程吧？判定质数需要解析数论的知识从而引入浮点计算么？who knows?
我说了，最好有源码，大家动手编一遍跑一遍，否则你只能去猜。

你当Spec的人是请注意文明用词啊，整数测试放在SpecFP里。
如果你要反驳，请拿出合理的解释，两倍以上的性能提升已经摆在这了，你认为是怎么来的？

_MyST_Spring

AMD可以瞑目了，每次Intel推出SSE指令集的时候，AMD都pdpd的第一时间跟上。

如此看来，AMD真是浪费了无数的晶体管来做这种根本对性能提升无意义的事情啊

Prescott

晕死，随便来个简单的吧

1. #include <stdio.h>
   
2. #include <stdlib.h>
   
3. 
   
4. float a[512][512], b[512][512], c;
   
5. 
   
6. int main () {
   
7. 
   
8.     srand(0);
   
9.     for (int i=0; i < 512; i++){
   
10.         for (int j = 0; j < 512; j++){
    
11.             a[i][j] = (double)rand() / RAND_MAX;
    
12.             b[i][j] = (double)rand() / RAND_MAX;
    
13.         }
    
14.     }
    
15. 
    
16.     for (int N = 1; N < 10000; N++)
    
17.     for (int i=0; i < 512; i++){
    
18.         for (int j = 0; j < 512; j++){
    
19.             c = a[i][j] + a[i][j] * b[i][j];
    
20.         }
    
21.     }
    
22.     printf ("result of c is %fn", c);
    
23.     return 0;
    
24. }
    
25. 
    
26. 
    
27. [test]$ g++ -O3 -mfpmath=387 main.cc -o a.gcc.387
    
28. [test]$ g++ -O3 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=5 main.cc -o a.gcc.sse
    
29. main.cc:10: note: not vectorized: unhandled data-ref
    
30. main.cc:18: note: not vectorized: live stmt not supported: D.3579_28 = a[i_78][j_79]
    
31. main.cc:18: note: vectorized 0 loops in function.
    
32. （笨笨的gcc，这么简单的循环居然都不会向量化）
    
33. 
    
34. [test]$ icc -fast main.cc -o a.icc
    
35. ipo: remark #11001: performing single-file optimizations
    
36. ipo: remark #11005: generating object file /tmp/ipo_iccRoENV3.o
    
37. main.cc(17): (col. 5) remark: LOOP WAS VECTORIZED.
    
38. （还是icc聪明）
    
39. 
    
40. [test]$ time ./a.gcc.387
    
41. result of c is 1.596053
    
42. 
    
43. real    0m3.545s
    
44. user    0m3.540s
    
45. sys     0m0.004s
    
46. 
    
47. [test]$ time ./a.gcc.sse
    
48. result of c is 1.596053
    
49. 
    
50. real    0m3.454s
    
51. user    0m3.451s
    
52. sys     0m0.003s
    
53. 
    
54. [test]$ time ./a.icc
    
55. result of c is 1.596053
    
56. 
    
57. real    0m0.766s
    
58. user    0m0.765s
    
59. sys     0m0.001s

复制代码

[ 本帖最后由 Prescott 于 2007-9-30 14:57 编辑 ]

_MyST_Spring

原帖由 Prescott 于 2007-9-30 14:32 发表
晕死，随便来个简单的吧
#include
#include

float a[512][512], b[512][512], c;

int main () {

    srand(0);
    for (int i=0; i < 512; i++){
        for (int j = 0; j < 512; j++){
    ...

老P又不厚道了一回

Prescott

原帖由 _MyST_Spring 于 2007-9-30 15:01 发表


老P又不厚道了一回

:unsure:

又怎么不厚道了？

_MyST_Spring

原帖由 Prescott 于 2007-9-30 15:09 发表

:unsure:

又怎么不厚道了？

也不给人楼主留点face啊。。

紫色

原帖由 Prescott 于 2007-9-30 14:32 发表
晕死，随便来个简单的吧
#include
#include

float a[512][512], b[512][512], c;

int main () {

    srand(0);
    for (int i=0; i < 512; i++){
        for (int j = 0; j < 512; j++){
    ...

8错的例子。不过只不过是比较了gcc和icc。
你的程序看似循环了512*512次，但每次循环都是独立的对c赋值。其实c最终就等于a(512，512)+a(512，512)*b(512，512)？聪明点的编译器把它优化到运行时间0.0001秒都有可能。
对icc，有其他优化选项完全相同，仅有浮点单元是sse/x87的一点区别的数据提供吗？

PS：能否说一下cpu是啥。类似的程序我跑过不少，p4上加了sse优化,(以下缩水）。

c = a[j] + a[j] * b[j]这种表达式利用不了sse。也许icc能利用sse每次计算两个循环，如果不能保证这一点就改善一下你的代码，让它好利用sse。

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

Prescott

原帖由 紫色 于 2007-9-30 15:30 发表


8错的例子。不过只不过是比较了gcc和icc。
对icc，有其他优化选项完全相同，仅有浮点单元是sse/x87的一点区别的数据提供吗？


PS：能否说一下cpu是啥。类似的程序我跑过不少，p4上加了sse优化，速度还 ...

1. 
   
2. 
   
3. [~]$ uname -a
   
4. Linux xxxxxxxx 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
   
5. 
   
6. [~]$ cat /proc/cpuinfo
   
7. ...
   
8. model name      : Intel(R) Core(TM)2 CPU          6700  @ 2.66GHz
   
9. ...
   

复制代码

不好意思，gcc很笨只能生成标量的SSE，icc不支持在64bit环境下生成x87代码。

Prescott

原帖由 紫色 于 2007-9-30 15:30 发表



8错的例子。不过只不过是比较了gcc和icc。
你的程序看似循环了512*512次，但每次循环都是独立的对c赋值。其实c最终就等于a(512，512)+a(512，512)*b(512，512)？聪明点的编译器把它优化到运行时间0.0001 ...

稍微修改一下程序，满足你一下：

1. #include <stdio.h>
   
2. #include <stdlib.h>
   
3. 
   
4. float a[512][512], b[512][512], c[512][512], d = 0;
   
5. 
   
6. int main () {
   
7. 
   
8.     int i,j,N;
   
9. 
   
10.     srand(0);
    
11.     for (i = 0; i < 512; i++){
    
12.         for (j = 0; j < 512; j++){
    
13.             a[i][j] = ((float)rand() / RAND_MAX) - 0.5;
    
14.             b[i][j] = ((float)rand() / RAND_MAX) - 0.5;
    
15.             c[i][j] = 0;
    
16.         }
    
17.     }
    
18. 
    
19.     for (N = 1; N < 100000; N++)
    
20.     for (i = 0; i < 512; i++){
    
21.         for (j = 0; j < 512; j++ ){
    
22.             c[i][j] = c[i][j] + a[i][j] * b[i][j];
    
23.         }
    
24.     }
    
25. 
    
26.     i = rand() % 512;
    
27.     j = rand() % 512;
    
28.     printf ("result of c[%d][%d] is %fn", i, j, c[i][j]);
    
29.     return 0;
    
30. }
    
31. 
    
32. 
    
33. [test]$ g++ -O3 -mfpmath=387 main.cc -o a.gcc.387
    
34. 
    
35. [test]$ g++ -O3 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=5 main.cc -o a.gcc.sse
    
36. main.cc:12: note: not vectorized: unhandled data-ref
    
37. main.cc:21: note: dependence distance  = 0.
    
38. main.cc:21: note: accesses have the same alignment.
    
39. main.cc:21: note: dependence distance modulo vf == 0 between c[i_89][j_91] and c[i_89][j_91]
    
40. main.cc:21: note: dependence distance  = 0.
    
41. main.cc:21: note: accesses have the same alignment.
    
42. main.cc:21: note: dependence distance modulo vf == 0 between c[i_89][j_91] and c[i_89][j_91]
    
43. main.cc:21: note: LOOP VECTORIZED.
    
44. main.cc:21: note: vectorized 1 loops in function.
    
45. 
    
46. [test]$ icc -fast main.cc -o a.icc.sse
    
47. ipo: remark #11001: performing single-file optimizations
    
48. ipo: remark #11005: generating object file /tmp/ipo_iccjm6Zar.o
    
49. main.cc(20): (col. 5) remark: LOOP WAS VECTORIZED.
    
50. 
    
51. [test]$ time ./a.gcc.387
    
52. result of c[25][391] is -297.068634
    
53. real    0m35.912s
    
54. user    0m35.903s
    
55. sys     0m0.004s
    
56. 
    
57. [test]$ time ./a.gcc.sse
    
58. result of c[25][391] is -297.068634
    
59. real    0m17.791s
    
60. user    0m17.783s
    
61. sys     0m0.005s
    
62. 
    
63. [test]$ time ./a.icc.sse
    
64. result of c[25][391] is -297.068634
    
65. real    0m17.041s
    
66. user    0m17.035s
    
67. sys     0m0.003s

复制代码

slice

:loveliness:
扯那么多干嘛，AMD的U主板bios有个功能可以关掉SSE支持。intel就不知道如何屏蔽了。
如果你是用的X2之类的，大可以关掉SSE回到远古时代，看看会不会是世界末日。
结果是不会，还好Windows不是OSX，没SSE照样工作。倒是KMPlayer直接罢工了，不怕，用WMP11，放个720P的WMV不过也就CPU占用高了10%多而已。
TS的倒是高了%好几十，不过可能是用WMP没SSE视频加速给弄没了吧，倒不是SSE的作用。
在没有SSE的日子里。你才能体会到SSE的好处。
所以我决定再体验三天没有SSE的日子，大家说我能坚持3天不:loveliness: 。有句话不是说失去了才懂得珍惜么。

acqwer

原帖由 slice 于 2007-9-30 19:23 发表
:loveliness:
扯那么多干嘛，AMD的U主板bios有个功能可以关掉SSE支持。intel就不知道如何屏蔽了。
如果你是用的X2之类的，大可以关掉SSE回到远古时代，看看会不会是世界末日。
结果是不会，还好Windows不是 ...

跑个3dmarks看看。

Intelife

原帖由 slice 于 2007-9-30 19:23 发表
:loveliness:
扯那么多干嘛，AMD的U主板bios有个功能可以关掉SSE支持。intel就不知道如何屏蔽了。
如果你是用的X2之类的，大可以关掉SSE回到远古时代，看看会不会是世界末日。
结果是不会，还好Windows不是 ...

只关掉一个核心上的SSE，还是关掉了两个？

NehalemSunK11

:lol: 什么显卡，跑个OPENGL游戏看看

slice

原帖由 acqwer 于 2007-9-30 19:45 发表

跑个3dmarks看看。

试了下Mark03。
My God！跑还是能跑，结果有点匪夷所思！放720P的WMVCPU也就30%多变成40%多而已。没想到Mark03会这样子。谁能tell me why？
关SSE简直就是超级幻灯片啊，92分。不关是720分。w00t) 问题出在哪里，Mark03发现没SSE脑袋秀逗了？

viewlg

以前用sse一直是处理视频图象 没搞过数值计算 随便试了下单精度的计算

var                 s,sbasic:single;
        param1,param2,param3:single;
                   tb,te,tf:int64;
begin
   sbasic:=1.0;
   param1:=19.12;
   param2:=19.13;
   param3:=0.1;

   queryperformancefrequency(tf);
   queryperformanceCounter(tb);

   //包括加/乘/除各一次 循环1000万次并对前次结果依赖 不会产生优化

   //x87指令
   Asm
    mov ecx, 10000000
    fld s
  @loop:
    fmul param1
    fdiv param2
    fadd param3
    dec ecx
    jnz @loop
    fstp s
   end;
   queryperformanceCounter(te);

   //输出时间消耗
   memo1.Lines.Append(format('x87 %f ms %f  ', [(te-tb)/tf*1000,s]) );

   queryperformanceCounter(tb);

   //SSE指令
   Asm
     mov ecx, 10000000
     movss xmm0, sbasic
   @loop:
     movss xmm1, param1
     movss xmm2, param2
     movss xmm3, param3
     mulss xmm0, xmm1
     divss xmm0, xmm2
     addss xmm0, xmm3
     dec  ecx
     jnz  @loop
     movss s, xmm0
   end;
   queryperformanceCounter(te);

      //输出时间消耗
   memo1.Lines.Append(format('SSE %f ms %f  ', [(te-tb)/tf*1000,s]) );

测试结果
x87 170.98 ms 191.33  
SSE 93.73 ms 191.32  

证明即使是不使用SIMD优化,只是替代x87浮点指令为sse指令就能获得接近一倍的速度提高.

但是可以发现, 2者的计算结果有一定的差异. 而双精度的计算结果是191.30,计算结果上反而是SSE更加精确. 所以在浮点计算时采用sse那是很有效果的,如果考虑到SIMD的并行计算,那提高不是一点半点啊.

注: 手头的 delphi 7只支持 sse,不支持sse2 ,没法试双精度了.我想应该区别不大.因为 sse里不管是使用
ps后缀并行计算4个还是采用ss后缀单独计算一个速度是没区别的.

[ 本帖最后由 viewlg 于 2007-9-30 20:46 编辑 ]

the_god_of_pig

SIMD无用论，竟然这么长时间了还有人在YY(_(

好吧，LZ永远是对的，IBM,Intel,AMD都是250，就LZ有远见，发现了客观事实的真理，佩服，在下一定铭记在心:huh:

viewlg

原帖由 slice 于 2007-9-30 20:33 发表


试了下Mark03。
My God！跑还是能跑，结果有点匪夷所思！放720P的WMVCPU也就30%多变成40%多而已。没想到Mark03会这样子。谁能tell me why？
关SSE简直就是超级幻灯片啊，92分。不关是720分。w00t) 问题出 ...

SSE的Sqrt计算比FP的Sqrt计算快10倍以上(单运算而不考虑simd,考虑simd则是接近50倍).而开方计算是3d驱动里最常见的计算.

acqwer

原帖由 slice 于 2007-9-30 20:33 发表


试了下Mark03。
My God！跑还是能跑，结果有点匪夷所思！放720P的WMVCPU也就30%多变成40%多而已。没想到Mark03会这样子。谁能tell me why？
关SSE简直就是超级幻灯片啊，92分。不关是720分。w00t) 问题出 ...

03也就罢了，05、06没SSE根本不让你跑。