爱吱声

标题: C++ 提速的新发现 [打印本页]
作者: 雷达    时间: 2022-9-24 22:54
标题: C++ 提速的新发现
C++ 比 Octave 慢好多，怎么破？4 T* p. G) B( ~8 _

' d: ~  }2 h/ {2 j& C自相关两层循环，内层循环涉及浮点数计算，试验了一下把内层循环内部全都 comment out 只留个壳子,  但空的内层循环本身就把速度拉下来了，看来问题并不在浮点计算。
$ {5 F2 |' Q8 B4 d7 }6 W8 p8 s
* p$ v: A+ p0 p  g- O1 r速度优化问题真的很有意思啊。
9 q4 J2 q. Y! b* z$ a: ^5 B. R) n# ^) Q" G, v3 w+ v0 W6 R% Y; t
欢迎大家继续讨论
作者: 数值分析    时间: 2022-9-24 23:04
拉下来？拉多少？, z& S& T7 u  m9 U8 x
把代码贴上来看看？; _, L' n6 z$ _' X

  z2 G. A1 a2 E难道分支预测不准破坏流水线执行？不该啊。
作者: 沉宝    时间: 2022-9-24 23:15
会不会代码本身的缺陷阻止了自动优化？另外，硬件配置和开发环境可能也有关系。
作者: 风雨无阻    时间: 2022-9-24 23:33
Maybe Debug mode?
作者: 雷达    时间: 2022-9-24 23:54
本帖最后由 雷达 于 2022-9-24 23:57 编辑 - w/ p( {+ L& w' S4 h  o
数值分析 发表于 2022-9-24 23:042 {% _% J  |( W" [4 ]
拉下来？拉多少？
" |  V9 n5 C! {' C! v把代码贴上来看看？
6 b0 H0 l1 V. X6 Q- Z

* l% N! u. C( I3 s! O% M( qvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)9 m+ ~% F& j( ?3 s) t, p
{
# z& L; w* o( _/ R3 P        comp temp, xtimesy;) N4 q  z$ O. G& c0 C  p
        xtimesy.re = 0;5 s% E% b' \* u$ ?" z- y; l0 P
        xtimesy.im = 0;+ G0 g7 F4 @4 I+ G$ s( {8 f
        int j0 = lenB - 1;* T6 d0 D, x# c9 H
        int    i, j, i1, reali;6 i  ]9 R5 @% P8 r0 |
        if (lenA % 2 == 1)
  K. U2 [, T2 u+ K1 n                reali = lenA + 1;1 v3 S9 d0 }9 v8 V
        else
5 P3 F+ z1 C" H+ {4 O$ l  ^3 H3 d, S                reali = lenA;
3 I, Y% z! M) a        reali /= 2;
+ Q+ u+ z( o3 u5 \5 J6 [
% |( D! n& J7 J9 c        int nconv = reali + lenB;
1 c3 F0 t" k$ c( t0 P% d        //#pragma omp parallel for
4 C( }) }& Z, T; W  `) V4 {* J" V        for (i = reali; i < nconv; i++)
4 S& a+ Q0 k* d+ o        {
( ~- B& ^' ?' V7 R3 P                temp.re = 0;
. l! \3 N% X. |% f" ]. w                temp.im = 0;
% K+ X# s& w/ V9 r+ t; X, K) b/ R                i1 = i;( G/ b0 Y! g) s% y% p2 _2 ]& e
                for (j = j0; j >= 0; j--)
6 A/ d5 x" z. ~) x                {  b* Q6 ^, L9 K! T9 r' K# h- w( {
                        /* floating date operation */; ]. m# g/ M! F  h
                }
9 e% V7 l% `: P& B& B        }# n& G. N, M7 Q6 g! L/ s7 G+ a& E
}& H; d/ [+ n$ f+ k7 [

3 X+ Q( w* I% @4 ixcorr函数代码如上，comp是复数struct, 做过长度为11、19两个矢量的测试，和octave结果完全一样' h0 v2 R; ?6 D- z0 l6 k) O7 C% o
4 C3 ^! q. I7 @+ O& m
红色部分是内循环，现在其内部操作都comment out 了, j0大概是 6000。2 Z& T. \1 j0 F; l' c' E1 t/ I
现在call xcorr 100次，耗时78s.
2 k! @  s, }$ V$ N& o  b. g7 E/ p1 [7 {! ?4 T6 x2 M
如果把红色部分内循环本身完全comment out， call xcorr 1000次，耗时 <1s.
8 b" H6 c: ]0 l+ C$ o* e6 m1 ?
9 `: U+ ~( I) I" a
作者: 雷达    时间: 2022-9-25 00:17
风雨无阻 发表于 2022-9-24 23:33! x8 D! I( k2 T/ ]
Maybe Debug mode?

' C+ C+ g+ A! X+ S
, H& y; f5 j. H1 a7 {; O不应该，看我上面的回复。+ a% m- H  Q' o# ?* \' \2 g3 g

5 n2 C$ J/ O* W9 R- U# Y我更怀疑是 VS 社区版的问题
作者: 数值分析    时间: 2022-9-25 00:20
本帖最后由 数值分析 于 2022-9-25 00:24 编辑 / m8 Q: S7 f5 Y1 Y
雷达 发表于 2022-9-24 23:54
& X- r7 s3 G7 J3 r3 Pvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)4 c+ E! l: R6 x: A" s0 _( j7 S
{
0 H/ K0 S5 h! q; g        comp temp, xtimesy;
/ @( P: |2 ?/ J/ |% v

: O1 e( n! D- [& c" d这个不是这么比的吧。。。" [+ s) m- Y) V- h# Z4 ?

) B' ]4 p% g9 z您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。( ^. d" S+ Z6 p( T; \9 l
8 H" ~8 h" M% R0 y
而加上内循环，光jmp和dec指令就至少多执行了6000个，慢个几十倍不是正常的么？
作者: 雷达    时间: 2022-9-25 00:46
本帖最后由 雷达 于 2022-9-25 01:09 编辑 - {3 B  Y- R4 {6 ?! d
数值分析 发表于 2022-9-25 00:20
( x4 l  ~6 L- J这个不是这么比的吧。。。
7 k1 a" @* \5 p1 K0 r! V; x& N, q) @4 p* B* ^; M
您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。

. i' _6 m. X# u2 M( U# m
" r2 s) r, |+ ]8 c9 a有道理。
: M6 m+ C  U5 ?5 }1 h所以存在内循环速度就上不去，把内循环取消，改成两个向量直接点乘再求和应该就会好得多，记得 numeric 库里有算向量内积的，我回头试试。( Z' d$ k2 B. v1 F, j

1 D! A  {) @' E$ ]  z我先尝试尽量用标准库，一个小程序，不想搞得太复杂。多谢了
作者: 沉宝    时间: 2022-9-25 01:27
雷达 发表于 2022-9-25 00:46
/ n2 Q. Y* p( k; q0 N* d( Q有道理。2 a% u. C0 v5 L4 a8 j
所以存在内循环速度就上不去，把内循环取消，改成两个向量直接点乘再求和应该就会好得多，这大 ...
) a; w' |6 J' M! J
你两个试验之间就差了一个空循环， call 1000次按理不会有秒级差异，可能还是编译器优化的问题。举个例子，把循环本身翻译成机器指令loop或dec/jnz，两者速度上会差很多
+ v- P( _* J4 ]8 r* K; n- iWhy is the loop instruction slow? Couldn't Intel have implemented it efficiently?
作者: 沉宝    时间: 2022-9-25 01:48
数值分析 发表于 2022-9-25 00:203 ~8 y6 ^7 u' |& i
这个不是这么比的吧。。。
  m' A  y' ^) S% S8 N
0 {4 b8 G4 ^/ @6 R9 M您这个函数，不带内循环的话，汇编完总共操作也没几个（不到100个）。
而加上内循环，光jmp和dec指令就至少多执行了6000个
1 V( s1 g/ ]  e( k
& z5 v2 a# ]& v2 k. m! d$ G* [+ a# B
现在的CPU，可以把判断、jmp和dec指令全部融合进一个µOp（微操作，CPU内部流水线上的执行单位）。如果循环这样跑，花不了多少时间。
作者: 数值分析    时间: 2022-9-25 02:06
本帖最后由 数值分析 于 2022-9-25 02:16 编辑
1 G" S( i0 k8 I* s( w: Q
沉宝 发表于 2022-9-25 01:48, ^: L: c* Q5 [$ Z
现在的CPU，可以把判断、jmp和dec指令全部融合进一个µOp（微操作，CPU内部流水线上的执行单位）。如果 ...

4 L8 X5 G& z: {. E/ _  h* S. Y/ \# `* M6 Z" m* |1 [9 B! r: d
是的，兄台说的对。7 G! S4 c; W* k2 c2 ~
2 }' b8 I7 W5 _; @, b+ G! E
其实我想说的是 真正数值计算部分和代码中其他不直接计算的overhead的比值这个事儿。5 `( p# U& X: Y6 s* \9 ~

' E# L- K3 f# ]/ ?雷达兄构造测试用例的时候，屏蔽掉了所有计算的部分，使得剩下的都是overhead，这样run time比较的结果就显得好像不合理了。如果把计算加回去，计算部分的run time会dominate，结果就不那么离谱了。因为不好说，所以用指令数对比的方式试图直观地说明这一点。9 D: s& k1 G. z

3 \/ e! g- Z: P' U; u' f2 z比如说，如果有计算，那么跑六千个循环相对于计算应该用不了多少时间。但是如果一边是什么都不做，另一边是六千个循环，那六千个循环比什么都不做慢几十倍了，就不是那么不合理了。* n, l+ q% U5 g. b7 e
' v: F. u: \- x) K8 q7 o) ^; R$ c
当然也有可能像兄台说的，是优化参数的问题，但我觉得更多地是测试用例设计的不合理。
作者: 雷达    时间: 2022-9-25 04:47
本帖最后由 雷达 于 2022-9-25 04:49 编辑
( J9 M9 E, j" M) Q  q, v
沉宝 发表于 2022-9-25 01:27
( ^, Z0 D2 X) O& o# c2 J; `+ \你两个试验之间就差了一个空循环， call 1000次按理不会有秒级差异，可能还是编译器优化的问题。举个例子 ...

; v* O2 w2 T2 I# r2 Q( }7 ?$ c0 N; q: \5 g
又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差一倍，我上面这个差的太多了。! q, o( Z- {! q- p
- [" L2 e% b" P+ u; _- ], P: @" K) u
我已经完全懵了。
作者: 沉宝    时间: 2022-9-25 05:51
雷达 发表于 2022-9-25 04:47! z3 \- q) C# x0 t6 S( Z& s
又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差 ...
( @; r' C9 ~) Z8 m  p7 ~
时间差一倍的结果可以接受。
$ A5 r" v+ h. p  q! w, X1 s4 @$ w# }6 `9 T1 }# e: `6 _5 q
你还是用profile工具看看吧。现在大家都主观瞎猜。
作者: 数值分析    时间: 2022-9-25 14:58
本帖最后由 数值分析 于 2022-9-25 15:38 编辑 ' Z5 R! G) b  \' J1 k( ?
雷达 发表于 2022-9-25 04:470 y" X/ K0 ~0 M! E( C& G
又写了个小实验，没有调用子函数，双层循环，外层6千次，内循环30万次空转，有或没有空转内循环，时间差 ...

( a: i- u" v4 `' {/ a" Y
% ^) V0 z& _5 N0 c5 \- C# U0 C; L
, Z& N0 ?. R' A0 W! \
  t( y- R6 n. W3 y& p9 L) q3 X能不能把这个也贴上来，看看和上一个有什么不同？
作者: 雷达    时间: 2022-9-26 01:30
本帖最后由 雷达 于 2022-9-27 01:17 编辑 $ i6 C1 `. N/ V5 \2 N+ t+ w, P
数值分析 发表于 2022-9-25 14:58
# S0 T' k5 D! G- k, Q0 Q能不能把这个也贴上来，看看和上一个有什么不同？
' ?$ E( G0 X- t0 C! O4 e) X- ~+ X
理了理思路，重新做了一个测试。
$ `& c7 ?6 ~3 ~0 B$ t4 ]  `0 n做了两个 vector 和 两个 float *, 都长 100000
  U7 Z. J1 q" F0 P( B  t6 K外循环 6000，里面先做随机数生成，模拟真实环境，避免数据的 cache.
: {3 a$ I7 z- ~% A* o; w9 H2 h# P
) `+ _" v. ^* Y9 Z, U6 n' \内循环试了4种方法，- n0 v0 ]1 P5 [% M
1. 直接调用 vector inner_product 247s ( o( P( U& D  v  _
2. vector 循环点乘累加 237s" P& r, x0 q3 v: A. i# P
3. float * 循环点乘累加 204s
9 F5 J0 s7 ]2 Z4 `0 N9 E4. 空循环 100000 次 202s
: \3 C6 c. q$ X/ e
2 G+ I( r4 Z1 ?不做内循环 200s
2 L) d6 j  V. j) i2 O' _$ u# u- ]3 z; ^& F: C/ X
你昨天说的对，内循环本身占比是很小的，大头在其他处理。
# T: P/ M" l/ @7 z另外可以看到， float * 循环点乘累加 并不差，比用vector 还更快。% M- R+ Q! P! j: a
: f2 @. `3 l+ ]/ n
至于我那个原始程序，还有一些疑问，见5楼，其他都不变仅仅是有无空的内循环就有很大不同，这是不对的，也许有一些其他缺陷我没有看到。（也许可以改成 while 试试）
. b5 z, d0 \4 g: a+ m" A) N* g6 a
（为什么下面我贴的  b1 加 方括号里的 i , 显示出来却是 b1 ？方括号 i 消失了。 LOL . 改成  jj 好了，原来 方括号里的 i 是斜体标志  LOL）
+ A( G: G) d6 u2 b: C4 F+ }% |7 q- l% w$ j
        std::vector < float > vec1(N);
( \. G/ l# y" N; G        std::vector < float > vec2(N);2 L# s9 W8 [6 Z8 W: {
        float* b1 = new float[N];
( a0 ]; I2 o; W6 J  C: R' m        float* b2 = new float[N];, S) Q' f8 X7 V* [9 e
4 l  v. C- \$ ^2 L' `; f
        for (int j = 0; j < 6000; j++)
6 u! c) a6 o+ C* K        {
) |4 O9 _/ _$ W8 b2 G/ D) @                std::generate(vec1.begin(), vec1.end(), []() {
4 E7 @. \7 A5 Q                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 23.23));;7 R! C8 x0 L0 x
                        });
# R/ Q/ K  x9 d$ j" M3 j- z6 V; P* P1 N. ~
                std::generate(vec2.begin(), vec2.end(), []() {
' }! g* b. D+ |6 F                        return static_cast <float> (rand()) / (static_cast <float> (RAND_MAX / 24.31));;! M4 ^8 Q0 B6 g3 n  D
                        });/ Z: U; j# o; ~% [- N* w8 F

" Y# j3 W8 n9 [. S5 M                for (size_t jj = 0; jj < vec1.size(); jj++)* O# e2 c2 W3 l1 q; J5 }
                {
! Y8 b: W* _9 ^! p                        b1[jj] = vec1[jj];* \. e7 R' c8 I% h1 H/ J
                }
& ]; u! i+ o" s
; _  h# @3 D; z7 z: s                for (size_t jj = 0; jj < vec2.size(); jj++)
  S/ M" G% p7 A0 I                {
4 _9 Z9 ~) N$ c  L7 [/ |                        b2[jj] = vec2[jj];* O" a2 X4 F8 A9 j4 B+ ?/ M* |
                }
: M9 E; o& m3 i" |  E! s  \
+ r, M0 K$ W, Z% e( e                //Method - 1  N=100000 247s  * |% [4 [* a1 y) w3 J1 J
                //fresult = inner_product(vec1.begin(), vec1.end(), vec2.begin(), 0);
4 ^# |9 d* U! X) B$ s                                ) L. F6 q+ f) U- ^% T! a$ W# a
                //Method - 2  N=100000  237s+ [1 G; ]! M2 N; y0 I  g& Q7 i
                /*
5 r9 b0 ~& v4 `$ s9 t: X9 P/ {7 X0 h                for (int jj = 0; jj < N ; jj++)
. o, o9 {3 f$ Q4 m/ h" a. M1 z2 d                {
% _' l- {" w& P8 i- y8 n2 K/ s                        fresult += vec1[jj] * vec2[jj];
! U. \- w, g* f7 ?1 j                }  x0 `! T7 b' M
                */
6 |5 i+ R4 o6 \4 l! _                                
) K+ i" R9 k& [# q' u+ e! x                //Method - 3  N=100000 204s  h& J9 H9 n. M+ @) T: J6 x0 H
                /*0 [# m4 F7 [; p3 l1 h# l+ z4 v
                for (int jj = 0; jj < N; jj++)5 P' \1 \0 z. C6 w* }$ t! E
                {
/ H# \9 P% W8 I% J                        fresult += b1[jj] * b2[jj];
# Z% ?2 a/ t/ F0 C& K                }+ `- D' @. i5 M0 [( B9 N
                */
- B# U: E2 M9 D5 I9 {0 m2 m) k# s$ Q2 u9 {
                //Method - 4   202s
$ V5 q4 U/ ^% B2 x                /*) W% s3 i8 ^& C. u+ G
                for (int jj = 0; jj < N; jj++)
9 h. @8 F3 Z0 D                {. h* t7 U1 H# W* y4 s
                        
$ F( B7 {, h7 q5 X- _$ `                }
* \0 T4 E8 S/ {8 J: k1 d: J4 E/ g                *// {( O$ a3 W& ?1 |. X2 R) a, n& v
                //comment out all methods, N=100000  202s               
3 p7 V4 ], `+ `  Y! i4 |        }  O: O" k2 w) w" s+ [9 B
0 E6 G% D6 M  g  l& @* m9 @' w# Q. G
        delete []b1;" a* G6 K) ]' Z( r+ V1 U3 Q0 V' q$ U
        delete []b2;

4 d/ q9 b* f* M% M
作者: 机器猫    时间: 2022-9-27 00:15
瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同？4 ~3 B1 t3 h2 z
. ~5 i3 y! z, u6 V3 X& i
你第二个试验里面的j在循环里面又重新定义了啊，你确定真的跑了6000次？( ~3 N9 g/ k$ W5 [' k
作者: 雷达    时间: 2022-9-27 01:16
机器猫 发表于 2022-9-27 00:152 I. v  [) e, x- g* k6 r" e$ ~: e, k
瞎猜一下啊。把第一个的那个j定义成register变量会不会有不同？# f( f3 y, n; l0 f' \% i3 z
8 ~1 V. L+ S& J! P7 U
你第二个试验里面的j在循环里面又重新定义 ...
" [2 V( d; ?1 V5 G3 R# b
内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL8 d3 e# v6 B" o

  R+ g! i% u" t/ k  k) h1 T5 V/ x不和它较劲了，瞎耽误工夫，我已经转到 ubuntu, 也准备顺便试试 avx2 向量化。
作者: 机器猫    时间: 2022-9-27 02:06
雷达 发表于 2022-9-27 01:16* M0 p+ Z8 M3 D* q
内循环里面的 j 实际是 i, 为了规避爱坛显示的冲突帖子里临时改成了j, 现在是 jj 了。好累 、LOL
/ c, d! Q- J2 l7 M) G1 Y$ G. i$ h, F1 ^' F  V7 R
不和它 ...
( t: u1 s0 Q  V
& J" A+ \0 l/ `
不过可以试试我说的register变量。前一个试验j是混在一堆其它变量里一起定义的，很有可能是在stack上，这样内存读写会更多，要是再碰上每次都需要加载cache就更慢了。$ a5 c6 m. o# L3 {% Q" h* W- d
后面一个是在循环那里定义的，说不定编译器就把它优化成register变量了
作者: opensrc    时间: 2022-9-27 07:25
一个无关问题，为什么爱坛的帖子里在我这里有好些奇怪的东东在里面，是防拷贝措施吗？
作者: 雷声    时间: 2022-9-27 20:29
雷达 发表于 2022-9-24 23:54
0 |6 W  }( k6 M1 tvoid xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)" ]: T" |1 s$ l6 ^
{6 l6 k, b- Z. D, X; X/ ?$ `  U: g
        comp temp, xtimesy;

1 C) L; P: m) |这个code里面如果Openmp没有被注释掉的话，那么temp那个变量应该是定义在循环里面，否则线程之间会存在争夺写入那个temp的风险。
  M- ]. S3 `4 M/ c! _内层for循环如果没有内部操作的话，编译时应该被优化掉了，和你完全注册掉整个循环是一回事。可能你的编译设置没有打开优化？
! u0 E/ X1 e9 L2 {, {3 Q8 GVS社区版没有问题，我工作用的就是社区版，设置正常的话不会比商业版差。以前游说头头用Intel Compiler，他说不想花钱，而且差不了多少，就一直用到现在。
作者: 雷声    时间: 2022-9-27 20:39
雷达 发表于 2022-9-26 01:30
: v' q1 g, o) M理了理思路，重新做了一个测试。
' O$ S' u6 Y3 J$ t9 Q3 J* v做了两个 vector 和 两个 float *, 都长 100000
, o3 r- a0 q) @5 q外循环 6000，里面先做随 ...

, Q5 O' E. q, E8 \这个时间是从哪里开始算的？
: n$ I+ m: D/ S3 t5 X我怀疑这个200多秒里面有200秒花在产生随机数上了，真正计算大概只用了2秒， 用了vector那个因为有vector的额外开销，多了几十秒。
/ J5 Y: z0 ]8 Z$ W按照两个10万个数字的相关计算的规模来估计的话，两秒都算很长很长了。这个结果真的很奇怪。
作者: 雷达    时间: 2022-9-27 22:41
雷声 发表于 2022-9-27 20:39
4 a- N; v2 c/ d4 s1 g3 L  W1 x这个时间是从哪里开始算的？
' s: P" w# i. K2 p我怀疑这个200多秒里面有200秒花在产生随机数上了，真正计算大概只用了2秒， ...

5 n' `& w% Q+ n我不管它了，回头 linux 下换g++重新编译，顺便加上你们建议的向量化。
作者: 四处张望    时间: 2022-9-28 00:12
你这个循环主要的计算时间是那个rand，这个循环本身占用时间微乎其微。
# i& f! O& _$ |. F你的空循环，如果是现在的代码，编译器很可能完全不生成对应代码，因为没有任何输出或者修改变量，所以可以看到时间都是202S。你可以认为啥都不干的时间就是那么多。
1 I& R3 \4 t6 E0 c9 m0 L与此对应用数组（指针）花了2S
' f- r4 Q- S1 G6 z. N. e你用vec1[jj]*vec2[jj]理论上不应该差30多秒，这里很可能是你对vector的操作带来了内存操作，你可以试试把初始化挪出循环然后再比较，理论上vector的随机访问和数组应该几乎没什么区别。
作者: opensrc    时间: 2022-9-28 00:29
雷达 发表于 2022-9-24 23:545 d- c/ L0 I7 Z$ z7 V" X( [# v  V
void xcorr(comp* outcomp, comp* A, int lenA, comp* B, int lenB)
8 t; V  I& }$ p  l: Z4 Y% l{+ h4 M3 E! Q# C
        comp temp, xtimesy;

, Z# Q9 w3 M* Z$ M我有些迷糊，这样的code，难道不就应该时间差很多吗？也做了个简单的实验，你看看我做的有错吗9 T. ~- |+ l& S& H- `' b
5 c  b% U$ a& }7 n+ F9 h/ R
作者: 雷达    时间: 2022-9-28 00:49
opensrc 发表于 2022-9-28 00:29
2 I. ~7 a7 a; F9 o9 T, u我有些迷糊，这样的code，难道不就应该时间差很多吗？也做了个简单的实验，你看看我做的有错吗" i8 j) b* m, K: S. ^( f( }9 X& y

5 m* ]6 u' w( r: D6 E7 m ...
+ A. d3 f+ l2 x
你是对的，是我搞错了。确实没有优化的情况下，空循环如果次数够长本来就应该耗时较大。我搞错的原因是在不自觉得与 octave 比较，而实际上 octave 是优化过的，和是不是空循环没关系，这种不同条件的比较是没意义的。
( `. U1 u$ H% c) }- H3 T, c) g
6 z2 _' G1 P* p% V雷声网友说的也对，空循环应该被编译器优化掉，我的编译器设置有问题。
作者: 雷达    时间: 2022-9-28 00:56
本帖最后由 雷达 于 2022-9-28 01:09 编辑
  c$ a8 ?5 E1 q6 b' M0 D/ d+ B6 s; o
' Y% Q* K' f' O* q是我自己的理解有误，没有优化的情况下，空循环如果次数够长本来就应该耗时较大。
1 ~, z) b; a! N0 v. A% _有空时我会试试 SIMD和并行，看看能提高多少。! e/ W3 M2 V& d  l$ |' g' G! {% _7 p
过去7、8 年没有正经用C++ 写过东西，没有 sense 了 。
9 D+ P5 J& l: b5 F' k" X; E谢谢大家的讨论，I learded a lot.  红包已发  3 Q7 ^1 x5 j4 L$ M8 Q- F
/ S6 Q% y9 z! B$ K1 |
+ ^, D2 G; R+ T# Z/ n/ ?# P

. J3 s7 _' ^2 ^! N+ S6 O$ h* ]+ b, {; F, g: x




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