爱吱声

标题: C++ 提速的新发现 [打印本页]
作者: 雷达    时间: 2022-9-24 22:54
标题: C++ 提速的新发现
C++ 比 Octave 慢好多，怎么破？
9 ^) i# Q4 ]2 g. f
. Y! ]( h% D/ i. {, ?自相关两层循环，内层循环涉及浮点数计算，试验了一下把内层循环内部全都 comment out 只留个壳子,  但空的内层循环本身就把速度拉下来了，看来问题并不在浮点计算。. G6 A/ g) x, P7 Z; Y$ J$ |) h3 F

3 @) h5 c5 z4 b2 D速度优化问题真的很有意思啊。
0 R% [. O( {+ a9 }1 W* \4 Z  [
! k* ?: N$ G& `& F: G/ e& S欢迎大家继续讨论
作者: 数值分析    时间: 2022-9-24 23:04
拉下来？拉多少？
7 e7 w( A( t2 O2 r# h% }+ t, P把代码贴上来看看？
' ]- Q" t# J' g4 @% @& }0 A; H
5 J: R+ w# Q4 R- k2 {% z难道分支预测不准破坏流水线执行？不该啊。
作者: 沉宝    时间: 2022-9-24 23:15
会不会代码本身的缺陷阻止了自动优化？另外，硬件配置和开发环境可能也有关系。
作者: 风雨无阻    时间: 2022-9-24 23:33
Maybe Debug mode?
作者: 雷达    时间: 2022-9-24 23:54
本帖最后由 雷达 于 2022-9-24 23:57 编辑 ( o/ p# G* G& _' u
数值分析 发表于 2022-9-24 23:04
* ~6 F3 |- e3 }拉下来？拉多少？3 Z) D0 o" D0 N: @7 I
把代码贴上来看看？

: D$ L( z7 J/ B' F+ K
) S4 H) ?: N$ d7 U; Lvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)& P: ?5 n$ f# p- |  D& \
{
) I! v( w0 H' b8 P& N        comp temp, xtimesy;
9 |9 t. N3 s. I* `        xtimesy.re = 0;2 ~( L7 x+ c4 l1 f
        xtimesy.im = 0;. n& Y- L1 r  P8 ]3 c+ F3 n# a
        int j0 = lenB - 1;
/ I% k! K4 p% W5 C: q        int    i, j, i1, reali;
# d3 B/ ^. [8 m/ ?        if (lenA % 2 == 1)6 `6 U- a- X, a& e0 i& g
                reali = lenA + 1;# P, I$ b1 a( H# w  V
        else1 T8 s5 U; M) T  T& H/ u
                reali = lenA;+ X  }; w% t9 O1 b7 \
        reali /= 2;
/ v/ W1 V9 |% u  \1 D/ Z3 |" a% O5 N  i5 [
        int nconv = reali + lenB;
" C$ a0 i7 o) ?( b7 T! v. j        //#pragma omp parallel for" {7 f1 O) Q1 V( w) z
        for (i = reali; i < nconv; i++)2 w/ {8 m  ^7 T7 q$ d9 @
        {- Z2 o+ |% b' \# [- ~
                temp.re = 0;* w* `2 I$ f- _8 c+ U, N
                temp.im = 0;- v) s8 a* P" s+ Z: _9 A- k9 \
                i1 = i;
# D2 Y# m* I/ n8 o" s1 D2 r% O2 Q                for (j = j0; j >= 0; j--)& {% g* m4 o% {
                {6 X/ a5 m, ^: \$ u8 _# n
                        /* floating date operation */
: S5 y" F/ L3 Q- L/ ^0 D$ v; ^                }$ q7 {. |" Y4 j6 O, o
        }+ {% L- o1 n7 {  l
}: u$ Q& H( o. s+ d( n4 j7 e. M
2 e: P* a) ^. u- [
xcorr函数代码如上，comp是复数struct, 做过长度为11、19两个矢量的测试，和octave结果完全一样* m) g1 [- u* p! a/ a! q/ b0 L

& _. d; u0 O* U' ?; @红色部分是内循环，现在其内部操作都comment out 了, j0大概是 6000。( s" b: E2 Q3 n/ v/ g# M6 V
现在call xcorr 100次，耗时78s.
5 _4 n7 G( Y  U3 C# @1 F. c, B
/ R6 m0 S( ^' E7 G+ A* O0 J7 I如果把红色部分内循环本身完全comment out， call xcorr 1000次，耗时 <1s. ) Q4 K9 z0 m% Z( y' N3 r

: p3 }, [" |# N( T6 I
作者: 雷达    时间: 2022-9-25 00:17
风雨无阻 发表于 2022-9-24 23:33
/ U% j0 E4 v; U$ t3 s+ bMaybe Debug mode?

1 X4 t# y! s9 V5 Y2 x
  V  x2 ]0 P; k) w5 |" ^, o不应该，看我上面的回复。$ v5 o/ [% U2 r% j

( T5 n% R2 F. c- }& E; x, q0 ]8 v我更怀疑是 VS 社区版的问题
作者: 数值分析    时间: 2022-9-25 00:20
本帖最后由 数值分析 于 2022-9-25 00:24 编辑
0 d8 b. w* Y6 H! L/ e/ r8 Q
雷达 发表于 2022-9-24 23:54
, L% I/ E, m' t5 {' Zvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)
3 B( S- m* |7 O1 t/ K+ ~. W9 ~{7 g0 h8 w+ m0 N) o( }* @
        comp temp, xtimesy;
& U% e0 \! z- D7 F5 s

( Z/ U2 L6 [) [8 I# K这个不是这么比的吧。。。
9 y1 u; q5 @2 Y* O2 c6 c
' r5 h& ?) i! ^5 y' [' ~0 E, b您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。
+ v* l8 o( Y; Z0 J( B' M" K0 K  r1 F: s4 a5 x' ~3 B3 f
而加上内循环，光jmp和dec指令就至少多执行了6000个，慢个几十倍不是正常的么？
作者: 雷达    时间: 2022-9-25 00:46
本帖最后由 雷达 于 2022-9-25 01:09 编辑 " d$ ^/ m9 K7 |; F+ R6 I% ~9 d
数值分析 发表于 2022-9-25 00:20
" T/ d1 A; y% m: O( C" h这个不是这么比的吧。。。( }+ u/ B4 E9 O# p+ f) k7 [& l0 y

+ @1 i# d+ ?, ^3 N, @: C% ?% O5 ~您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。
( X1 C; H' H- g7 e4 p7 L( E$ R9 k2 C

# z5 v- L% f0 V7 K, J) X0 q有道理。
5 y7 J3 q$ Z7 x5 K  n% b# i% A所以存在内循环速度就上不去，把内循环取消，改成两个向量直接点乘再求和应该就会好得多，记得 numeric 库里有算向量内积的，我回头试试。
' _, {2 E- G9 k8 t9 o) S! h( I. c. E) P( g
我先尝试尽量用标准库，一个小程序，不想搞得太复杂。多谢了
作者: 沉宝    时间: 2022-9-25 01:27
雷达 发表于 2022-9-25 00:46! X3 o) |: J: t
有道理。* Q1 f, ~9 B( n+ p
所以存在内循环速度就上不去，把内循环取消，改成两个向量直接点乘再求和应该就会好得多，这大 ...
# U2 w) [6 l8 u
你两个试验之间就差了一个空循环， call 1000次按理不会有秒级差异，可能还是编译器优化的问题。举个例子，把循环本身翻译成机器指令loop或dec/jnz，两者速度上会差很多
- ]3 `' y, m, }4 `" j9 @Why is the loop instruction slow? Couldn't Intel have implemented it efficiently?
作者: 沉宝    时间: 2022-9-25 01:48
数值分析 发表于 2022-9-25 00:20
: {  C% r0 a% N; q% t这个不是这么比的吧。。。
! W) c4 J5 Q: x/ R+ X5 N/ L1 _  Q. F% _9 U+ x2 J4 E
您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。
而加上内循环，光jmp和dec指令就至少多执行了6000个
: R, f0 M1 g' e# h% }# z
* N# i" z, G" i4 A6 h
现在的CPU，可以把判断、jmp和dec指令全部融合进一个µOp（微操作，CPU内部流水线上的执行单位）。如果循环这样跑，花不了多少时间。
作者: 数值分析    时间: 2022-9-25 02:06
本帖最后由 数值分析 于 2022-9-25 02:16 编辑
0 P" B! g7 ~' n# t- q+ q5 W
沉宝 发表于 2022-9-25 01:480 z9 O# N4 |& g; l; ~0 U$ z
现在的CPU，可以把判断、jmp和dec指令全部融合进一个µOp（微操作，CPU内部流水线上的执行单位）。如果 ...

# Z0 x0 F6 R3 u* w1 I! d" {$ x2 B" M" G
是的，兄台说的对。
9 ^! K7 |( ~) r- k+ l1 N! }, }
# M6 c* b; i/ Q' ^- {' R0 s! h其实我想说的是 真正数值计算部分和代码中其他不直接计算的overhead的比值这个事儿。
3 ~! t, i2 `3 h0 ?5 k7 @* y0 ]6 s* Z: Z! R* U
雷达兄构造测试用例的时候，屏蔽掉了所有计算的部分，使得剩下的都是overhead，这样run time比较的结果就显得好像不合理了。如果把计算加回去，计算部分的run time会dominate，结果就不那么离谱了。因为不好说，所以用指令数对比的方式试图直观地说明这一点。& b2 S# I# g; B

9 [1 }) F$ R; G  z, i0 l; X! @比如说，如果有计算，那么跑六千个循环相对于计算应该用不了多少时间。但是如果一边是什么都不做，另一边是六千个循环，那六千个循环比什么都不做慢几十倍了，就不是那么不合理了。
2 p- Q5 M0 l/ {) c% B
7 ^2 Z) K4 s6 K% Z* R6 V当然也有可能像兄台说的，是优化参数的问题，但我觉得更多地是测试用例设计的不合理。
作者: 雷达    时间: 2022-9-25 04:47
本帖最后由 雷达 于 2022-9-25 04:49 编辑
2 w; z5 X0 a4 i1 e& ^
沉宝 发表于 2022-9-25 01:274 \2 h. d" ]$ _
你两个试验之间就差了一个空循环， call 1000次按理不会有秒级差异，可能还是编译器优化的问题。举个例子 ...
0 U% J- q# d6 u+ H* X% u8 p# A
5 G" ]  {7 S2 [
又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差一倍，我上面这个差的太多了。! {/ Z  X, b- t# D# T2 I4 x
4 T" B% h; A- a- o
我已经完全懵了。
作者: 沉宝    时间: 2022-9-25 05:51
雷达 发表于 2022-9-25 04:47
9 l6 |0 u; E8 Q! @  v$ m# P+ t) e1 @又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差 ...

8 q! K& t+ C: r, n时间差一倍的结果可以接受。1 U- Q" f7 s' }0 W! s) v
+ A! @) r, D8 ]# E/ }' p
你还是用profile工具看看吧。现在大家都主观瞎猜。
作者: 数值分析    时间: 2022-9-25 14:58
本帖最后由 数值分析 于 2022-9-25 15:38 编辑
5 c5 s( e8 p6 u0 {% {! [( ~
雷达 发表于 2022-9-25 04:47
" @" p! i( k# J0 h+ T0 A9 f又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差 ...
1 I% g5 C, p: u0 k4 P+ M1 P2 F& _

# a9 x9 X- i: ?7 w" Q. J2 [9 V8 z6 t/ [5 [7 T- n  [
% n' ?- P! ?: g( [$ ?
能不能把这个也贴上来，看看和上一个有什么不同？
作者: 雷达    时间: 2022-9-26 01:30
本帖最后由 雷达 于 2022-9-27 01:17 编辑 ) O! ?! ~' E6 N$ X
数值分析 发表于 2022-9-25 14:58) K; U8 K( i& i# M! n0 {5 y, v2 B
能不能把这个也贴上来，看看和上一个有什么不同？

& V1 ]' f. d$ s* |; [; ~1 [理了理思路，重新做了一个测试。
0 E. a# U) @7 M+ l- E# q7 {0 G做了两个 vector 和 两个 float *, 都长 100000
) l' e" ^- Z3 R( m! S. ]' Q, k外循环 6000，里面先做随机数生成，模拟真实环境，避免数据的 cache.  H& n# s0 G- M  e1 ]
/ u) n  _# z9 D/ U. z2 ^0 m9 k
内循环试了4种方法，8 ~: Q2 }  T/ h: g# X& O) \& J
1. 直接调用 vector inner_product 247s " _8 U4 I6 d; D& {- Q$ v: X- u
2. vector 循环点乘累加 237s
* e( P1 C8 D9 Y0 X3. float * 循环点乘累加 204s  X; \7 H) ^- o& K  i% b3 n& X
4. 空循环 100000 次 202s
) f# H- \+ L  K. [" O
: W) J+ h2 y' M2 v, q不做内循环 200s
# Z/ J8 L$ K, O3 i1 y9 M' m4 L' a2 N+ x/ O
你昨天说的对，内循环本身占比是很小的，大头在其他处理。
4 Z; U  ~  q! n) k另外可以看到， float * 循环点乘累加 并不差，比用vector 还更快。
- ?, h6 J' c  M4 e6 u* l, J9 |! V
: u  P" X2 J, F至于我那个原始程序，还有一些疑问，见5楼，其他都不变仅仅是有无空的内循环就有很大不同，这是不对的，也许有一些其他缺陷我没有看到。（也许可以改成 while 试试）$ \1 x( y, ^" P8 V

' h% T- z8 F) r- d- T（为什么下面我贴的  b1 加 方括号里的 i , 显示出来却是 b1 ？方括号 i 消失了。 LOL . 改成  jj 好了，原来 方括号里的 i 是斜体标志  LOL）
$ ?% b3 a% b# p: \+ B: P! T2 w  {. r1 W; m" w( t
        std::vector < float > vec1(N);: c  @7 s- X4 N; ]0 c& r* S
        std::vector < float > vec2(N);
* P# h+ F& n, T; o7 L        float* b1 = new float[N];
6 Z  U. e, J3 ]8 d. Y* a+ \        float* b2 = new float[N];
5 v+ _, L& Q6 G  L
! p. p; c% x$ L/ V1 d        for (int j = 0; j < 6000; j++)
6 K0 ^% p# B& @0 y        {
& `; n2 Y9 T( n                std::generate(vec1.begin(), vec1.end(), []() {0 ]8 z5 @* h# J) y
                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 23.23));;: P6 x9 P& i: g4 f! o
                        });
) @7 S) s0 `9 d4 A0 j
8 ^7 w: }9 l0 ^' v" N                std::generate(vec2.begin(), vec2.end(), []() {
+ f: J8 Q5 c/ `3 p5 |: @0 f: u: p0 k                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 24.31));;2 m9 b8 H+ f; R( k4 N2 M
                        });, ?, H* V8 H( f* k& u
: m( ~2 [- `! u7 [
                for (size_t jj = 0; jj < vec1.size(); jj++)! V& f+ d0 M$ D1 f
                {
; v7 L# M9 m) L) V                        b1[jj] = vec1[jj];/ I- {9 J6 x; B
                }
- M$ A( E( a8 {6 Z( j1 O1 j+ T9 z9 C2 n* Q% a: O5 |/ ^) w5 c/ ]5 e
                for (size_t jj = 0; jj < vec2.size(); jj++)
# c' T$ e9 V* C- B) X2 S" I3 M; y                {/ ?: b( o& e% L
                        b2[jj] = vec2[jj];, m  c& q4 s0 f( W! }6 y5 i- Z$ D  L% p
                }0 x* [( W7 u" a: t" P
/ N- m# S5 o! v6 z
                //Method - 1  N=100000 247s  
2 a6 X8 x/ i) t! B                //fresult = inner_product(vec1.begin(), vec1.end(), vec2.begin(), 0);( [# [* N- W8 x: p+ p  x; d
                                
& |1 S, _7 b1 x1 Q                //Method - 2  N=100000  237s6 a! h6 |% E! o: i
                /*
8 z9 M$ W0 a5 P& F: g                for (int jj = 0; jj < N ; jj++)
2 @3 z8 t/ n$ D9 F                {
4 A( S# T, Y2 L                        fresult += vec1[jj] * vec2[jj];* s6 V2 o- T8 n3 f
                }
$ ]2 M$ e" Z: L9 ^8 f, V7 ~                */4 I4 l) J( t; X2 v+ Z
                                
" s( v2 Z0 F) K* m6 J. h                //Method - 3  N=100000 204s: x/ a0 y4 X  q. a' c. k" s- R
                /*$ J1 B/ ~& M7 J2 e2 R) n' }( O
                for (int jj = 0; jj < N; jj++)4 z+ x# D1 V, o& k- p( }
                {
3 o" u5 g4 J$ i, g7 h1 u4 r: C                        fresult += b1[jj] * b2[jj];  M, ^8 i) D) T; [
                }
2 G, Q4 g7 x) f+ h( W$ N                */
- \; I  Z& K4 d% ~# Z" {' M" Y
' K. z7 ^: c! q, Q' a# u9 M; I                //Method - 4   202s
# ]. t+ P1 H( R+ ]( G                /*
8 R6 {9 J3 ?' v2 [                for (int jj = 0; jj < N; jj++)/ a$ T! g3 ^* p
                {
$ _; s% B8 i9 X7 q* j4 D                        
1 n7 E# _* R' v5 w6 I! Q3 P                }+ Y( P& G( L2 K& ]
                */
$ j+ z* W3 R9 ]6 U# ~                //comment out all methods, N=100000  202s               
9 Z" h# C! r5 o4 G        }
6 `; H( N1 N1 S) P$ k8 t
8 o, E- s, `" J) X        delete []b1;
# k4 f& M) ]* v9 a        delete []b2;

, Y% p8 D9 S% l
作者: 机器猫    时间: 2022-9-27 00:15
瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同？6 K/ \2 A' B% o1 K
# E6 K$ Q8 m- \6 O5 W. R( T( \. }
你第二个试验里面的j在循环里面又重新定义了啊，你确定真的跑了6000次？
9 L$ s0 G/ q5 ]8 e% n) r
作者: 雷达    时间: 2022-9-27 01:16
机器猫 发表于 2022-9-27 00:15
2 i+ z& a+ n" Z& C6 S# h+ f. D瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同？
9 Z. X) h  R) A& A- N
& g9 }! i7 P8 n# D% v: D* i6 \你第二个试验里面的j在循环里面又重新定义 ...

7 S3 _, X! s' d内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL
3 K; d2 i9 y, q# ]
# K8 i2 g+ ?# K$ j5 s不和它较劲了，瞎耽误工夫，我已经转到 ubuntu, 也准备顺便试试 avx2 向量化。
作者: 机器猫    时间: 2022-9-27 02:06
雷达 发表于 2022-9-27 01:16
. l  F  O, Z7 ?+ s- @内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL% ^* u) K1 G' J. ], L+ X( p

5 Z; ]3 t: _8 T1 P5 d7 S9 |% O% e不和它 ...

) z# N  a' x+ O  z- @) ^4 X; M" R7 n/ w1 L3 M
不过可以试试我说的register变量。前一个试验j是混在一堆其它变量里一起定义的，很有可能是在stack上，这样内存读写会更多，要是再碰上每次都需要加载cache就更慢了。
, l( M: |0 i/ L, g* C& G后面一个是在循环那里定义的，说不定编译器就把它优化成register变量了
作者: opensrc    时间: 2022-9-27 07:25
一个无关问题，为什么爱坛的帖子里在我这里有好些奇怪的东东在里面，是防拷贝措施吗？
作者: 雷声    时间: 2022-9-27 20:29
雷达 发表于 2022-9-24 23:54
$ d9 a- G  [  C' ^* e* |void xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)
: R; d4 G6 S; F# }7 I, I{& t$ T3 G+ L" Y( |; Z5 J/ _
        comp temp, xtimesy;
. G' W# v& n# a4 H: ]6 E! I
这个code里面如果Openmp没有被注释掉的话，那么temp那个变量应该是定义在循环里面，否则线程之间会存在争夺写入那个temp的风险。
& h4 a( A' i8 G内层for循环如果没有内部操作的话，编译时应该被优化掉了，和你完全注册掉整个循环是一回事。可能你的编译设置没有打开优化？* n  N+ z  @7 n/ U7 o* }, o% B
VS社区版没有问题，我工作用的就是社区版，设置正常的话不会比商业版差。以前游说头头用Intel Compiler，他说不想花钱，而且差不了多少，就一直用到现在。
作者: 雷声    时间: 2022-9-27 20:39
雷达 发表于 2022-9-26 01:309 F- q4 e& C: [5 a/ `1 o! b  C; b# ^
理了理思路，重新做了一个测试。
- N) H; {5 K( u. {" q6 Z: w8 Y做了两个 vector 和 两个 float *, 都长 100000
: @4 O5 X1 {& h# R$ i9 ]. o外循环 6000，里面先做随 ...
& w9 I; i2 ], p* M. c) p
这个时间是从哪里开始算的？" R9 r) V6 T% [. d7 ~6 M1 E0 G
我怀疑这个200多秒里面有200秒花在产生随机数上了，真正计算大概只用了2秒， 用了vector那个因为有vector的额外开销，多了几十秒。
/ u+ @+ o$ ?# r# B8 j' |. m按照两个10万个数字的相关计算的规模来估计的话，两秒都算很长很长了。这个结果真的很奇怪。
作者: 雷达    时间: 2022-9-27 22:41
雷声 发表于 2022-9-27 20:39* v, \+ s3 R$ z1 x; j$ m  g
这个时间是从哪里开始算的？* X( }( H/ G8 V4 M  c3 u- N
我怀疑这个200多秒里面有200秒花在产生随机数上了，真正计算大概只用了2秒， ...

# M; Q8 [5 G) k  Y% j6 x我不管它了，回头 linux 下换g++重新编译，顺便加上你们建议的向量化。
作者: 四处张望    时间: 2022-9-28 00:12
你这个循环主要的计算时间是那个rand，这个循环本身占用时间微乎其微。2 r$ |  ~) |; q6 }0 {" t
你的空循环，如果是现在的代码，编译器很可能完全不生成对应代码，因为没有任何输出或者修改变量，所以可以看到时间都是202S。你可以认为啥都不干的时间就是那么多。+ D; @' @4 n; C$ P
与此对应用数组（指针）花了2S
2 j' C* J' w0 T2 U2 M7 r你用vec1[jj]*vec2[jj]理论上不应该差30多秒，这里很可能是你对vector的操作带来了内存操作，你可以试试把初始化挪出循环然后再比较，理论上vector的随机访问和数组应该几乎没什么区别。
作者: opensrc    时间: 2022-9-28 00:29
雷达 发表于 2022-9-24 23:543 Y1 x! d6 T$ r$ e6 Y
void xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)) b0 i/ J  F7 L
{- m1 N8 a) r5 N0 E5 s
        comp temp, xtimesy;

% V, @5 x, u; ?+ Y+ r) Y我有些迷糊，这样的code，难道不就应该时间差很多吗？也做了个简单的实验，你看看我做的有错吗
) k* t" h; ]" W* J! A- w, V8 v2 g- f- w
作者: 雷达    时间: 2022-9-28 00:49
opensrc 发表于 2022-9-28 00:29
. M& X1 V' Z8 |% a# U& W我有些迷糊，这样的code，难道不就应该时间差很多吗？也做了个简单的实验，你看看我做的有错吗
+ }' u/ D* Y  Z0 _. Y3 a2 Z7 Y8 N3 ]6 u. n2 u" E
...

8 r1 k$ t9 \# O/ E你是对的，是我搞错了。确实没有优化的情况下，空循环如果次数够长本来就应该耗时较大。我搞错的原因是在不自觉得与 octave 比较，而实际上 octave 是优化过的，和是不是空循环没关系，这种不同条件的比较是没意义的。
4 I/ p0 a! A' H3 ^% A& v* D6 B2 A6 c4 @3 u
雷声网友说的也对，空循环应该被编译器优化掉，我的编译器设置有问题。
作者: 雷达    时间: 2022-9-28 00:56
本帖最后由 雷达 于 2022-9-28 01:09 编辑
* F5 y) L. F1 e0 [
% Z, I5 z& _: Q2 r/ R2 b3 t是我自己的理解有误，没有优化的情况下，空循环如果次数够长本来就应该耗时较大。
' w- `" B5 }5 e, f: M. A有空时我会试试 SIMD和并行，看看能提高多少。8 c+ e* Z/ z% d9 T9 H! o9 K
过去7、8 年没有正经用C++ 写过东西，没有 sense 了 。
$ F+ v% w/ s& q3 e+ D( W5 L6 V谢谢大家的讨论，I learded a lot.  红包已发  
- M1 J5 ^4 V4 a0 ?8 {1 J
& Y% I1 F% s& K+ A$ G# w
8 x0 N$ W, O9 _( y
# x3 O% _  J' j) @2 f% A- f/ a) b
5 ^, H1 Y1 D9 e9 b/ }0 X$ c



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