爱吱声

标题: C++ 提速的新发现 [打印本页]

作者: 雷达    时间: 2022-9-24 22:54
标题: C++ 提速的新发现
C++ 比 Octave 慢好多,怎么破?
' s- s6 C. Y2 ^( ~! l* Q# a/ m& k5 g1 N! q! J1 |7 v
自相关两层循环,内层循环涉及浮点数计算,试验了一下把内层循环内部全都 comment out 只留个壳子,  但空的内层循环本身就把速度拉下来了,看来问题并不在浮点计算。+ r2 x( Q0 A* l  B8 |* E; K. O6 W

4 ]. a  A! T! j  s6 l6 H速度优化问题真的很有意思啊。7 j* I+ s8 }% I4 @3 M+ f- p
& y$ W3 c* c6 R- i# i
欢迎大家继续讨论
作者: 数值分析    时间: 2022-9-24 23:04
拉下来?拉多少?
# z- b- H/ @7 ]# m把代码贴上来看看?
" T4 g, R6 V1 ~, ^1 G% S; d% g4 U; a) O9 v0 l/ _3 n
难道分支预测不准破坏流水线执行?不该啊。
作者: 沉宝    时间: 2022-9-24 23:15
会不会代码本身的缺陷阻止了自动优化?另外,硬件配置和开发环境可能也有关系。
作者: 风雨无阻    时间: 2022-9-24 23:33
Maybe Debug mode?
作者: 雷达    时间: 2022-9-24 23:54
本帖最后由 雷达 于 2022-9-24 23:57 编辑   V" A6 j% q2 j0 \; W- E& q- N
数值分析 发表于 2022-9-24 23:04' J- u5 J. q1 }  e8 J
拉下来?拉多少?1 O9 |% l0 P1 e1 h/ R+ b+ v
把代码贴上来看看?
& `! K$ {: o3 ~" j
! l. x6 O4 `! B, C3 z7 i
void xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)
: \, ^# u1 o4 z) V0 h/ j{/ O- N# A, B( Q" H! y5 B5 o% ~
        comp temp, xtimesy;$ R( p' y& }2 }) K% O& ?) s+ W
        xtimesy.re = 0;
+ ~* N1 i4 ~) [: R1 T6 l. v        xtimesy.im = 0;
( n" U- d+ I1 C2 x$ `        int j0 = lenB - 1;
& H$ D4 P+ P  e6 m- S        int    i, j, i1, reali;
9 t2 R1 |- m0 \  l        if (lenA % 2 == 1): z8 o4 e: |' ?5 i
                reali = lenA + 1;* v3 {7 e, K$ y* T: K; u
        else
0 m* {6 K8 t0 J- W# R4 Q$ ?8 |* e/ T                reali = lenA;
& L* o: Q  \- V        reali /= 2;  l3 L9 ]: n: f8 @- r
$ z2 D' k4 \8 k# B
        int nconv = reali + lenB;
0 g- Q: G' E3 D) s4 J1 H- a        //#pragma omp parallel for9 G4 N9 l5 H; B. i$ |# i9 Z) B
        for (i = reali; i < nconv; i++)9 ~3 H/ G, U" r+ y6 }6 M, ]' x- k
        {4 k9 `3 d* g, Z# t) l
                temp.re = 0;
7 n; e2 q" ?( N) s                temp.im = 0;
, L( x& H& ]7 b* g                i1 = i;
* v2 L  ]; H7 T; s7 K                for (j = j0; j >= 0; j--)
4 z  ~5 U: s: o+ w* M. S                {
" z# _7 q0 {7 ]# z7 c1 f                        /* floating date operation */. L$ z, R9 n) Z% ?, L- s
                }

9 q+ `0 o, E" F. T        }9 i- f" ?4 j1 b  J) T
}9 E4 M1 U+ k0 {+ p/ ?
0 F. A5 k! v* O
xcorr函数代码如上,comp是复数struct, 做过长度为11、19两个矢量的测试,和octave结果完全一样
$ ~% e, m" }3 g* a; h
/ P6 ]; g, N: r' ^9 J1 y+ `红色部分是内循环,现在其内部操作都comment out 了, j0大概是 6000。
* `# k% ^% J- c. F现在call xcorr 100次,耗时78s.( \6 @6 i! h: Z, Q/ x! U
. M! I4 x9 n- J& z- m& V( A: ]
如果把红色部分内循环本身完全comment out, call xcorr 1000次,耗时 <1s. : w& [/ ]: @. s
( s( B" A+ _; [

作者: 雷达    时间: 2022-9-25 00:17
风雨无阻 发表于 2022-9-24 23:33) y6 I$ ^$ U1 [: i$ }0 }) }. ~
Maybe Debug mode?

/ G* C7 l( {$ Q3 C" }  |, v0 X. l. i; }5 g$ K8 S' M: O3 m( U0 {
不应该,看我上面的回复。
0 V- n0 P0 Z5 k& h: ?: G4 `8 }! i5 `; C1 q% z
我更怀疑是 VS 社区版的问题
作者: 数值分析    时间: 2022-9-25 00:20
本帖最后由 数值分析 于 2022-9-25 00:24 编辑
8 i; T7 Z  j$ Q- Y8 w, B
雷达 发表于 2022-9-24 23:54
6 ^; h  o' R1 t4 t* {$ `" u3 Dvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)/ x, r6 l# J$ K- l2 V6 u7 h0 Y/ a0 Z# B
{
$ d8 V1 t" U! D. s/ r2 x3 U, J        comp temp, xtimesy;

4 b' P* q& R% G$ a0 K
/ n8 L4 K- a# Y3 Z这个不是这么比的吧。。。
: g' [) t: E* v* ~( j. W. |  w  c) ]7 W5 S0 A6 M: p/ _
您这个函数,不带内循环的话,汇编完总共操作也没几个(不到100个)。- ~3 d5 e" W% C& I) w
4 w' a) ?4 e; o  o  ^; ]
而加上内循环,光jmp和dec指令就至少多执行了6000个,慢个几十倍不是正常的么?
作者: 雷达    时间: 2022-9-25 00:46
本帖最后由 雷达 于 2022-9-25 01:09 编辑
2 N( F9 w+ A0 R2 h
数值分析 发表于 2022-9-25 00:20
5 l' e3 O' c5 A: i5 Y! W) h: L这个不是这么比的吧。。。
7 y2 Z- t, R! }3 R" {2 Q5 T+ K. d8 w+ [( y
您这个函数,不带内循环的话,汇编完总共操作也没几个(不到100个)。

- Q2 r& e3 ~' W: H1 u
6 N5 k3 _9 q8 ~; ^5 w2 U  f% b有道理。6 y! k- Z2 B) K/ f
所以存在内循环速度就上不去,把内循环取消,改成两个向量直接点乘再求和应该就会好得多,记得 numeric 库里有算向量内积的,我回头试试。  h- \# b$ o0 _1 t- f- v

. m9 ]' Q1 H+ I5 j, i我先尝试尽量用标准库,一个小程序,不想搞得太复杂。多谢了
作者: 沉宝    时间: 2022-9-25 01:27
雷达 发表于 2022-9-25 00:466 p3 A9 E# `: S' R
有道理。' h; j9 [0 U- ]) d, K
所以存在内循环速度就上不去,把内循环取消,改成两个向量直接点乘再求和应该就会好得多,这大 ...

6 L3 n8 Q, J- O你两个试验之间就差了一个空循环, call 1000次按理不会有秒级差异,可能还是编译器优化的问题。举个例子,把循环本身翻译成机器指令loop或dec/jnz,两者速度上会差很多/ F( G3 y& Y+ R) U
Why is the loop instruction slow? Couldn't Intel have implemented it efficiently?
作者: 沉宝    时间: 2022-9-25 01:48
数值分析 发表于 2022-9-25 00:207 Q  i" ]  {6 j$ D  D) D3 W! b
这个不是这么比的吧。。。* s2 S  Z$ z$ M

6 k: w+ \' F* y1 Y9 K6 L$ P您这个函数,不带内循环的话,汇编完总共操作也没几个(不到100个)。
而加上内循环,光jmp和dec指令就至少多执行了6000个
* Y8 J/ z6 u1 p- W0 p! y

/ I8 @: ]# Z; ?现在的CPU,可以把判断、jmp和dec指令全部融合进一个µOp(微操作,CPU内部流水线上的执行单位)。如果循环这样跑,花不了多少时间。
作者: 数值分析    时间: 2022-9-25 02:06
本帖最后由 数值分析 于 2022-9-25 02:16 编辑
; X$ O9 E. k" \6 @' g/ W& z5 t
沉宝 发表于 2022-9-25 01:48+ y- q0 S3 i5 J( n$ X9 g
现在的CPU,可以把判断、jmp和dec指令全部融合进一个µOp(微操作,CPU内部流水线上的执行单位)。如果 ...
0 A7 ~) L3 I3 p% C

* A( v! u4 t$ ~& o& |" W/ j% k是的,兄台说的对。) F5 [; _4 [% H7 P, @* r9 ]
) \$ h& F8 O* \5 n, Y
其实我想说的是 真正数值计算部分和代码中其他不直接计算的overhead的比值这个事儿。% X3 V: r+ g; A6 w4 ?; x" \8 U/ t

) r! ^" t% s. G: ?5 |- i5 j/ i( ^雷达兄构造测试用例的时候,屏蔽掉了所有计算的部分,使得剩下的都是overhead,这样run time比较的结果就显得好像不合理了。如果把计算加回去,计算部分的run time会dominate,结果就不那么离谱了。因为不好说,所以用指令数对比的方式试图直观地说明这一点。
, V) ~. e8 A6 ~' O( L5 C' Y: T1 `5 P$ h+ i. m6 G1 B8 Z
比如说,如果有计算,那么跑六千个循环相对于计算应该用不了多少时间。但是如果一边是什么都不做,另一边是六千个循环,那六千个循环比什么都不做慢几十倍了,就不是那么不合理了。
9 z0 R* N: d5 r0 e1 @2 x2 P% B8 F
当然也有可能像兄台说的,是优化参数的问题,但我觉得更多地是测试用例设计的不合理。
作者: 雷达    时间: 2022-9-25 04:47
本帖最后由 雷达 于 2022-9-25 04:49 编辑 ; f4 a% a  c( F0 E  L- q
沉宝 发表于 2022-9-25 01:27
6 M7 W- g1 i! F5 A5 E你两个试验之间就差了一个空循环, call 1000次按理不会有秒级差异,可能还是编译器优化的问题。举个例子 ...

) I1 O) m2 i8 t" i; m+ y9 V, R0 w% U* {* m
又写了个小实验,没有调用子函数,双层循环,外层6千次,内循环30万次空转,有或没有空转内循环,时间差一倍,我上面这个差的太多了。3 j; e3 h7 y; [

% k+ ^. v: U, ~7 l1 F+ r# h) L, U我已经完全懵了。
作者: 沉宝    时间: 2022-9-25 05:51
雷达 发表于 2022-9-25 04:47
9 q. V; W9 A7 R: N又写了个小实验,没有调用子函数,双层循环,外层6千次,内循环30万次空转,有或没有空转内循环,时间差 ...

1 r3 n1 _, \5 y# i) F' a" ^( {时间差一倍的结果可以接受。
5 F# H  h* ]" Z, w. d) x6 m( x% d5 O( i1 {) A8 x# _
你还是用profile工具看看吧。现在大家都主观瞎猜。
作者: 数值分析    时间: 2022-9-25 14:58
本帖最后由 数值分析 于 2022-9-25 15:38 编辑
2 u% D# ?' L" {
雷达 发表于 2022-9-25 04:47) n& N0 g  A  ]5 B
又写了个小实验,没有调用子函数,双层循环,外层6千次,内循环30万次空转,有或没有空转内循环,时间差 ...
4 G+ I1 b& ~- A! o
$ e4 q8 A- @0 B% r

. v. w& M& j2 M' c2 J( u- _; d1 g% |( q( o; y
能不能把这个也贴上来,看看和上一个有什么不同?
作者: 雷达    时间: 2022-9-26 01:30
本帖最后由 雷达 于 2022-9-27 01:17 编辑
  ~4 j$ t- d4 V, T
数值分析 发表于 2022-9-25 14:58
  B8 o( F: e$ s+ p  n1 f/ H能不能把这个也贴上来,看看和上一个有什么不同?
$ T/ X6 S4 R" r* B
理了理思路,重新做了一个测试。# F8 Z/ y- Q7 W6 o! p6 }
做了两个 vector 和 两个 float *, 都长 100000
+ r0 b8 \3 A4 [8 D( c外循环 6000,里面先做随机数生成,模拟真实环境,避免数据的 cache.% v8 ?. y' k, h% F3 k* Q+ E
8 k4 W; g9 w) _9 U& v7 i4 M0 P
内循环试了4种方法,/ h' @4 L5 d6 `1 f+ J/ Y7 k" z
1. 直接调用 vector inner_product 247s
! k/ p% F, a8 V% Z3 i" B2. vector 循环点乘累加 237s, D  M7 U( {! P' J. d! e" T
3. float * 循环点乘累加 204s
/ @4 i" p  o9 ^  u7 K4. 空循环 100000 次 202s7 |: o6 r: F  N: ?; O8 {/ s
# i- L! ~4 F% |0 R
不做内循环 200s
9 Z# Z( ~0 M0 I% e; l, I4 V2 c# W3 I/ f! o
你昨天说的对,内循环本身占比是很小的,大头在其他处理。
, D1 e' q8 q8 @5 X2 n* @另外可以看到, float * 循环点乘累加 并不差,比用vector 还更快。
, O  N4 b  A1 Q
4 F, ^( |+ L0 w1 @至于我那个原始程序,还有一些疑问,见5楼,其他都不变仅仅是有无空的内循环就有很大不同,这是不对的,也许有一些其他缺陷我没有看到。(也许可以改成 while 试试)
/ w- _2 y, V. _9 p4 U7 V- q0 i# J( p# ~* E; Y
(为什么下面我贴的  b1 加 方括号里的 i , 显示出来却是 b1 ?方括号 i 消失了。 LOL . 改成  jj 好了,原来 方括号里的 i 是斜体标志  LOL)
+ n1 \& |  Y8 t1 [; T/ ~# e& t" @! U1 p- I1 ^' q# D
        std::vector < float > vec1(N);
0 {+ W% b2 y1 ^' i        std::vector < float > vec2(N);
2 G4 ~! t6 r/ F* G) H        float* b1 = new float[N];1 K# i$ o9 Y5 l# _; i, M
        float* b2 = new float[N];
' r2 K5 v, ^# U3 E
& D8 o. K8 X, i% @! T% ~        for (int j = 0; j < 6000; j++)
# J3 W' a- n8 E& Z+ Z4 ?        {
2 v, c' |; ?! @( ~6 c                std::generate(vec1.begin(), vec1.end(), []() {
% e  I% P& v+ ~9 D9 x2 E/ M                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 23.23));;' x( \* p( t, E! l% W* L
                        });
. m/ Y! ~! @/ {# O  E( s
" J) y/ a6 J- }- |. l                std::generate(vec2.begin(), vec2.end(), []() {
9 L6 X8 f4 R( J' b( c& C                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 24.31));;1 v) R" g5 f/ ~" ]4 `
                        });
% L. {3 N$ b  g. D! h
6 H) [) q; T! K3 Z                for (size_t jj = 0; jj < vec1.size(); jj++)  i) O! [) m8 _; [1 X
                {1 v: h/ v7 Z0 \7 |) ~+ t
                        b1[jj] = vec1[jj];: x- `( ?7 ^/ S/ {# d
                }
: t1 A! O0 x# A+ T/ y0 H0 s1 H3 B) e  n% ~5 f7 _3 I
                for (size_t jj = 0; jj < vec2.size(); jj++)
# B' w8 y6 X; c! S                {
  f9 d* i! e; L/ K, A* Y' {                        b2[jj] = vec2[jj];" ^; ]1 Y4 X8 T( G
                }( _! I+ l" Q% B
) s1 a* U1 v( U# x9 `2 l* P( l' h
                //Method - 1  N=100000 247s  
6 V. G4 T4 O& r! w5 ?8 |                //fresult = inner_product(vec1.begin(), vec1.end(), vec2.begin(), 0);
$ W6 |0 C3 a+ H& x6 A% G, p                                
+ @! o% c, T. Q5 a8 P) g2 t                //Method - 2  N=100000  237s+ _7 x" @" L8 }4 e9 Z9 o% m
                /*
1 U+ e& ]4 M+ T" Y                for (int jj = 0; jj < N ; jj++)% }3 e7 H+ _; n# @- Z& S9 p
                {& h+ ]  U! U% k- f4 `/ ^' [
                        fresult += vec1[jj] * vec2[jj];
0 l& M' T; y9 W" r; t                }
- |4 R; Q6 _3 p& j                */, z* ^. Y9 v4 `; \# a3 ^7 e
                                * D# \; a/ ~0 t/ }
                //Method - 3  N=100000 204s
3 t) u# ^) d# T( r2 _1 p                /*$ Q/ s  \/ W# q2 w! J6 ]( s/ H
                for (int jj = 0; jj < N; jj++)
3 W4 A: y  y7 @. M* V6 I                {
' A( `& G8 f% V6 p# Y% i                        fresult += b1[jj] * b2[jj];
5 l+ O) B% {8 o3 C+ H* ]% d. H                }
& a! c7 e2 n% r+ i8 E8 t( @                */
! z7 s' u4 j5 z2 E: i' s' ]7 n( T( f/ ]7 `/ a$ `. r
                //Method - 4   202s8 Q  |3 U5 h0 D
                /*
5 T3 J2 v/ u# {1 w                for (int jj = 0; jj < N; jj++)8 X; n  m& ~" \4 w/ L
                {
& ?. h( U2 N8 c- r) d                        8 M$ i# w# |& k2 a
                }
/ ~9 Z$ C1 z( L                */) [, B" N1 s+ O  Q6 U( @2 m4 n
                //comment out all methods, N=100000  202s                " x; K8 _& @+ ~4 B0 V
        }
: c. A2 k4 A# O' v/ z( k1 K4 W  M2 a
        delete []b1;( ~. {; Z& O" d) G
        delete []b2;

4 h2 a2 j: b( w% [  Q7 o
作者: 机器猫    时间: 2022-9-27 00:15
瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同?; f( r* j3 B9 _4 {
7 p( ~6 l& Y* r6 g; ?% C8 c/ w
你第二个试验里面的j在循环里面又重新定义了啊,你确定真的跑了6000次?
2 n% n4 [" Z5 W' ~' r
作者: 雷达    时间: 2022-9-27 01:16
机器猫 发表于 2022-9-27 00:15
5 q& t0 g6 Q: o: i; f瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同?
1 C  K3 u' v" ^3 k7 e5 G5 L2 {/ A0 Z6 V/ q
你第二个试验里面的j在循环里面又重新定义 ...

/ n) O6 w5 R5 e8 ?- _+ n- Q4 C- w内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL1 P+ N; T5 r: W6 a4 l' Z
# ?7 E" o. V2 `; u* W" `/ b0 D$ Z, K
不和它较劲了,瞎耽误工夫,我已经转到 ubuntu, 也准备顺便试试 avx2 向量化。
作者: 机器猫    时间: 2022-9-27 02:06
雷达 发表于 2022-9-27 01:16' v, @9 u0 t& J: o9 r
内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL
- z7 ]. D: S6 S
' G: p/ v: @* g3 o& {不和它 ...
8 y$ t; c# y9 }# ]

) u' M. H, l7 C. j' Q. Z不过可以试试我说的register变量。前一个试验j是混在一堆其它变量里一起定义的,很有可能是在stack上,这样内存读写会更多,要是再碰上每次都需要加载cache就更慢了。1 C# u. E. K+ j9 f2 d0 O( m9 K
后面一个是在循环那里定义的,说不定编译器就把它优化成register变量了
作者: opensrc    时间: 2022-9-27 07:25
一个无关问题,为什么爱坛的帖子里在我这里有好些奇怪的东东在里面,是防拷贝措施吗?
作者: 雷声    时间: 2022-9-27 20:29
雷达 发表于 2022-9-24 23:54
+ }' M6 t  D, N6 q% pvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)9 k' e3 w( _! J8 o) q; q9 Y
{& l* ^5 ~3 r8 Y% E
        comp temp, xtimesy;

7 e$ T4 C' `+ P- u& W; r) B这个code里面如果Openmp没有被注释掉的话,那么temp那个变量应该是定义在循环里面,否则线程之间会存在争夺写入那个temp的风险。
' ^# `1 ^6 s  A. y; a0 l" R* Y内层for循环如果没有内部操作的话,编译时应该被优化掉了,和你完全注册掉整个循环是一回事。可能你的编译设置没有打开优化?
" U9 M+ T6 z6 V7 d+ aVS社区版没有问题,我工作用的就是社区版,设置正常的话不会比商业版差。以前游说头头用Intel Compiler,他说不想花钱,而且差不了多少,就一直用到现在。
作者: 雷声    时间: 2022-9-27 20:39
雷达 发表于 2022-9-26 01:30
4 _4 N8 Y5 _8 i# e1 d* W, Z理了理思路,重新做了一个测试。
* f' L* y* x/ m3 R  g% ]4 I做了两个 vector 和 两个 float *, 都长 1000009 I; u, e  K1 [+ S; S
外循环 6000,里面先做随 ...

; z, [; Z; N' R这个时间是从哪里开始算的?
9 @  h( t- W8 n我怀疑这个200多秒里面有200秒花在产生随机数上了,真正计算大概只用了2秒, 用了vector那个因为有vector的额外开销,多了几十秒。
( X9 I0 q/ B7 s1 E1 r- d按照两个10万个数字的相关计算的规模来估计的话,两秒都算很长很长了。这个结果真的很奇怪。
作者: 雷达    时间: 2022-9-27 22:41
雷声 发表于 2022-9-27 20:39
2 {8 `4 w" B' @) e; P1 s这个时间是从哪里开始算的?
+ {# p. n! u6 b7 s. l我怀疑这个200多秒里面有200秒花在产生随机数上了,真正计算大概只用了2秒, ...
, h2 g- F3 {) \3 T9 f
我不管它了,回头 linux 下换g++重新编译,顺便加上你们建议的向量化。
作者: 四处张望    时间: 2022-9-28 00:12
你这个循环主要的计算时间是那个rand,这个循环本身占用时间微乎其微。5 @* B7 g3 _' p. a+ y, J& {
你的空循环,如果是现在的代码,编译器很可能完全不生成对应代码,因为没有任何输出或者修改变量,所以可以看到时间都是202S。你可以认为啥都不干的时间就是那么多。
7 P: Y  x( f( E与此对应用数组(指针)花了2S  L& E: ~: o! F7 y% X& O
你用vec1[jj]*vec2[jj]理论上不应该差30多秒,这里很可能是你对vector的操作带来了内存操作,你可以试试把初始化挪出循环然后再比较,理论上vector的随机访问和数组应该几乎没什么区别。
作者: opensrc    时间: 2022-9-28 00:29
雷达 发表于 2022-9-24 23:54
( N' f8 y6 v% ?void xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)  L; [0 i* o! [
{# c' X0 C: ^/ X/ H  b# v2 z
        comp temp, xtimesy;
+ m+ G2 k+ b) D" l# y
我有些迷糊,这样的code,难道不就应该时间差很多吗?也做了个简单的实验,你看看我做的有错吗0 z. s/ o+ i5 r% b4 Y8 R
: A7 P; I: i% n- Q/ n

作者: 雷达    时间: 2022-9-28 00:49
opensrc 发表于 2022-9-28 00:29$ ~, j+ I; H# [5 K+ u% b" J
我有些迷糊,这样的code,难道不就应该时间差很多吗?也做了个简单的实验,你看看我做的有错吗
7 O0 a/ s2 L; N7 Y  S, I
+ R5 d8 q; c: \/ D. d/ x; Z1 ^ ...
" Q8 X' ~+ p! \8 D
你是对的,是我搞错了。确实没有优化的情况下,空循环如果次数够长本来就应该耗时较大。我搞错的原因是在不自觉得与 octave 比较,而实际上 octave 是优化过的,和是不是空循环没关系,这种不同条件的比较是没意义的。
: V5 c" [* f" ?5 l/ I' a9 m4 I4 r3 F) ^9 ]* t( S+ X
雷声网友说的也对,空循环应该被编译器优化掉,我的编译器设置有问题。
作者: 雷达    时间: 2022-9-28 00:56
本帖最后由 雷达 于 2022-9-28 01:09 编辑 ! A: @7 l& H+ V
: G: r' ^7 }1 Z1 V# b
是我自己的理解有误,没有优化的情况下,空循环如果次数够长本来就应该耗时较大。
& ]  l7 o( ]/ T$ e' p+ V  h% Y有空时我会试试 SIMD和并行,看看能提高多少。6 l- @7 b9 U: I( b
过去7、8 年没有正经用C++ 写过东西,没有 sense 了 , @8 y  I/ U+ ~& l
谢谢大家的讨论,I learded a lot.  红包已发  ; l+ m. n/ y1 p1 y  M

( H  K4 h, o) f+ |7 I$ c# K) G8 u$ L& Z/ p9 `
( h3 E5 N% L' g/ y& J9 _# r

  r2 B, V* ^, c* O0 `& F7 o




欢迎光临 爱吱声 (http://aswetalk.net/bbs/) Powered by Discuz! X3.2