平方数数字和

gxqcn

可惜当时我运行的还不是最终的优化版， 否则速度会快1倍（参见 122#），将可得到更多的数据。 不过，我没有那好的条件，可以数天不关机运行程序。

无心人

呵呵 你能连续３８小时不关，我已经很佩服你了啊 呵呵 我服务器没VC2008 因为最近三个月重新装过一次 另外看icc编译的asm文件 发现他没对关键语句用SSE2 呵呵 以前没注意 看他优化了，结果优化的是初始化部分，呵呵 现在想来，那个sum + delta加 完全可以用一个１２８位的８字组合的加代替 应该能节约点时间 但后面的规整似乎还是无法加速 你的代码是８０个时钟多点进行一次循环的 我想能压缩到４０个时钟内 就是很大的胜利 （按你优化代码算的）

无心人

出现问题了 把代码搞丢了 icc -fast -msse2 square.c -o square.c 给覆盖了 测试修改后C代码结果暂时作废 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 另外，在下载到本机的上午编辑的pas代码 在我机器上用free pascal调试的时候 证明了可以读状态以中断后继续

mathe

你们现在达到最大的数字是多少?如果假设可以运行一个月,估计能够达到多大的数据?

mathe

原帖由 无心人 于 2008-7-28 17:00 发表 出现问题了 把代码搞丢了 icc -fast -msse2 square.c -o square.c ...

呵呵,Linux上面这个错误很容易犯我犯过多次 我有一次还使用了命令 rm -f .

无心人

呵呵 不过linux下还是相对比较方便的呢 最大的数字GxQ运行38个小时得到的 我打算突破他的结果 昨天有了新的想法 准备抛弃所有的异常处理 反正几年内不会出现数据溢出的 呵呵 等超越了GxQ的结果后，把程序改进下，继续挂 一个月能计算到5X10^26

无心人

如果是GxQ的机器和优化的C代码 则可达到10^28 Square.Log 在逼近GxQ结果

2. 程序启动: 2008-7-28 11:24:29
4. 完成初始化: 2008-7-28 11:24:29
6. 2008-7-28 11:24:29: 1 1
8. 2008-7-28 11:24:29: 4 4
10. 2008-7-28 11:24:29: 9 9
12. 2008-7-28 11:24:29: 7 16
14. 2008-7-28 11:24:29: 13 49
16. 2008-7-28 11:24:29: 10 64
18. 2008-7-28 11:24:29: 16 169
20. 2008-7-28 11:24:29: 19 289
22. 2008-7-28 11:24:29: 18 576
24. 2008-7-28 11:24:29: 22 1849
26. 2008-7-28 11:24:29: 27 3969
28. 2008-7-28 11:24:29: 25 4489
30. 2008-7-28 11:24:29: 31 6889
32. 2008-7-28 11:24:29: 28 17956
34. 2008-7-28 11:24:29: 34 27889
36. 2008-7-28 11:24:29: 36 69696
38. 2008-7-28 11:24:29: 40 97969
40. 2008-7-28 11:24:29: 37 98596
42. 2008-7-28 11:24:29: 43 499849
44. 2008-7-28 11:24:29: 46 698896
46. 2008-7-28 11:24:29: 45 1887876
48. 2008-7-28 11:24:29: 49 2778889
50. 2008-7-28 11:24:29: 52 4999696
52. 2008-7-28 11:24:29: 54 9696996
54. 2008-7-28 11:24:29: 55 19998784
56. 2008-7-28 11:24:29: 58 46689889
58. 2008-7-28 11:24:29: 61 66699889
60. 2008-7-28 11:24:29: 63 79869969
62. 2008-7-28 11:24:29: 64 277788889
64. 2008-7-28 11:24:29: 67 478996996
66. 2008-7-28 11:24:29: 70 876988996
68. 2008-7-28 11:24:29: 73 1749999889
70. 2008-7-28 11:24:29: 72 3679999569
72. 2008-7-28 11:24:29: 76 5599977889
74. 2008-7-28 11:24:29: 79 7998976969
76. 2008-7-28 11:24:30: 81 8998988769
78. 2008-7-28 11:24:30: 82 17999978896
80. 2008-7-28 11:24:30: 85 36799899889
82. 2008-7-28 11:24:30: 88 88998998929
84. 2008-7-28 11:24:30: 90 297889998849
86. 2008-7-28 11:24:30: 91 299879997769
88. 2008-7-28 11:24:30: 94 897977978689
90. 2008-7-28 11:24:30: 97 975979998889
92. 2008-7-28 11:24:30: 100 2699997789889
94. 2008-7-28 11:24:30: 99 3957779999889
96. 2008-7-28 11:24:30: 103 9879498789889
98. 2008-7-28 11:24:30: 106 9998768898889
100. 2008-7-28 11:24:30: 108 29998985899689
102. 2008-7-28 11:24:30: 109 85986989688889
104. 2008-7-28 11:24:30: 112 97888999968769
106. 2008-7-28 11:24:31: 115 386999898769969
108. 2008-7-28 11:24:31: 117 429998989997889
110. 2008-7-28 11:24:31: 118 578889999977689
112. 2008-7-28 11:24:32: 121 898999897988929
114. 2008-7-28 11:24:32: 124 1959999889996996
116. 2008-7-28 11:24:33: 127 3699998989898689
118. 2008-7-28 11:24:35: 126 6788999798879769
120. 2008-7-28 11:24:36: 130 9895699989899689
122. 2008-7-28 11:24:43: 133 38896878989988889
124. 2008-7-28 11:24:43: 136 38999699989995889
126. 2008-7-28 11:24:47: 135 67699789959899889
128. 2008-7-28 11:25:00: 139 188997899869998769
130. 2008-7-28 11:25:07: 142 279869897899999969
132. 2008-7-28 11:25:19: 144 498999778899898896
134. 2008-7-28 11:25:40: 148 989879999979599689
136. 2008-7-28 11:26:06: 145 1877896979979898969
138. 2008-7-28 11:27:27: 153 5899989587897999889
140. 2008-7-28 11:27:44: 151 6979497898999879969
142. 2008-7-28 11:28:08: 154 8899988895999696889
144. 2008-7-28 11:30:56: 157 28979978999958969889
146. 2008-7-28 11:35:38: 160 78897999969769888996
148. 2008-7-28 11:36:25: 162 87989899898866889889
150. 2008-7-28 11:42:54: 163 199989299899788979969
152. 2008-7-28 11:52:44: 166 449998999899988698769
154. 2008-7-28 12:02:57: 171 789899899796987988996
156. 2008-7-28 12:07:14: 169 969988797999759789889
158. 2008-7-28 12:47:35: 172 3599979999987777888889
160. 2008-7-28 13:01:41: 175 4899976999986989889796
162. 2008-7-28 13:36:48: 178 8889998799995887887889
164. 2008-7-28 13:44:25: 180 9899698989999989958489
166. 2008-7-28 14:33:48: 181 17989999975899879969889
168. 2008-7-28 17:11:58: 184 57997787999988988979689
170. 2008-7-28 17:17:05: 187 59668999996988999989969
172. 2008-7-29 0:13:50: 189 289959998978968689899889
174. 2008-7-29 6:21:06: 190 649969889997895999999489
176. 2008-7-29 9:02:09: 193 857799969779899989969889
178. 2008-7-29 18:32:59: 196 1679898987989978888999689
180. 2008-7-30 12:23:02: 198 3899689979989899957996996
182. 2008-7-30 18:46:57: 199 4899999899498984599899889

复制代码

[ 本帖最后由 无心人 于 2008-7-30 20:03 编辑 ]

无心人

对96#的一点想法 目前来说计算到10^32是比较难的事情 考虑这个极限 则加Delta实际上仅需要最多加四个就可以了 考虑计算到10^24时间不很长 则运行时间最长的部分就是加四个Delta的了 是否可以SIMD加一次完成？ 在考虑汇编加速的可能 因为GxQ的代码也只是一秒处理4000万 处理完全部的10^32需要8年啊 还能提速吧

gxqcn

原帖由 无心人 于 2008-7-29 20:09 发表 对96#的一点想法 目前来说计算到10^32是比较难的事情 考虑这个极限 则加Delta实际上仅需要最多加四个就可以了 考虑计算到10^24时间不很长 则运行时间最长的部分就是加四个Delta的了 是否可以SIMD加一次完成？ ...

在 96# 中已考虑到这点了， 我在“UINT32 pool”之前还特意用了关键字“__declspec(align(16))”（VC6.0不支持该关键字）， 就是方便启用SIMD优化（包括手工直接嵌入汇编）， 但提速的程度不会太大，最多不过是将8年缩短为两年。

无心人

确实不大 目前看，不可能压缩到2年 哎 不知道有更好的算法么 我分析intel产生的汇编 看不明白 郁闷