嵌入式开发者社区

标题: 自己的算法连续两次运行消耗时间差20倍 [打印本页]
作者: bobhi009    时间: 2018-8-14 09:19
标题: 自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑
7 m* _2 C% H+ V( M& c7 Q( V& i/ P. n3 P( s- I- S5 g. r+ B
环境： 创龙提供的mcsdk (linux3.3 + bios6 + syslink)
) }2 }* R# t0 Y8 @; O) l自己的算法连续两次运行消耗时间差20倍， 而且跟算法本身应该没有关系， 因为算法在dsplink 的开发环境下是运行的没有问题的
! `/ Q8 k' S9 i4 e5 s应该是mcsdk这套开发环境的影响。 有谁知道是什么原因？
! n" w2 V+ l4 G& q& q! c5 l3 n, f7 V# Y9 w7 H5 w

2 K& v* d7 G! W9 i8 r下面是统计结果
3 }( v) F4 R) v0 F# Q$ @统计方法： 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间    
. s8 c5 F& B! e: y" memucycle0_0 = EMUCNT0;
/ ]5 O( Z' U# _* m$ B  ]emucycle1_0 = EMUCNT1;* ~( X3 `1 O6 [* k- q5 |
emucycle0_1 = EMUCNT0;
9 J% G# _" F% I- h; Z& i, k' ~+ Memucycle1_1 = EMUCNT1; ! [# n6 x# D/ y6 a/ U% }& O5 y
emuoverhead = (emucycle0_1 - emucycle0_0);; Q1 w4 j4 n) C# A- P' D  c  _2 ]
/ }+ b8 t& P) N7 O; d6 \
算法();6 P0 Y! \0 {1 F! v0 O# [

) y: O  w( ~8 O8 demucycle0_1 = EMUCNT0;. X# u( r& y; ?: ^
emucycle1_1 = EMUCNT1;: Y0 B0 i) \% G! y5 T# Q
0 p% ?" e" x0 @# t+ L; [5 d0 O
Cycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;0 t$ J* G* I! k7 d* h9 Z

. X, ~% o9 E. ~5 y6 Y% v/ ]1 k* U- Q, d  D3 q: w4 I
统计结果： 每隔一次， 数据处理的时间会是前一次的将近20倍0 h2 E- `1 U2 t
DSP> cycles: 196468  :  11814000
4 c5 L! S& ~) M' P% i DSP> times: 430.85 us with CPU 456.1 e0 p, @$ ?. M: @! G
DSP> cycles: 3238292  :  11814000
, [: B2 {1 T) `1 D3 R6 y DSP> times: 7101.52 us with CPU 456.
* X1 Q3 b/ k% b; e DSP> cycles: 157860  :  11814000" v6 x3 X! f' G. U7 S
DSP> times: 346.18 us with CPU 456.4 [0 g; n6 ]# H3 Y
DSP> cycles: 3265684  :  11814000
: _& i4 }- T' ?7 A, x DSP> times: 7161.59 us with CPU 456.
* M- Y" w* W6 n% v# m0 i DSP> cycles: 156344  :  11814000
( Y2 M1 \* W( k% {$ }- U; j9 G DSP> times: 342.86 us with CPU 456.
$ T2 f% I  B; o1 i3 h6 L% L" J DSP> cycles: 3304428  :  11814000( I: N  w; O, m- ]( ^- ?
DSP> times: 7246.55 us with CPU 456.5 i/ {) U7 ?0 G" E9 K

9 Y- r! J) Y! i2 T3 B, T% l设置：相应的表放到IRAM中了1 D, m' @' S7 U  i
SECTIONS
4 K" \; b4 X! P$ `# s1 A. N{* V! V) I! q" I# K
    .edma_data>IRAM  align = 0x80) Z% Q9 @& H; s, \" W; s
    .audio_glb> IRAM align = 0x80! y# @' C: p7 k% r1 L) K5 \+ Q
        .f_table>  IRAM,  align = 0x80 ( _( Q8 x7 g( V+ w$ ?1 G" f$ h1 z
        .f_text>  DSP_PROG,   align = 0x80
$ O+ X# Z9 @7 n: z; K3 E+ P$ E        .f_glb> IRAM align = 0x80
3 H5 G7 I$ S" x% s* K        .ref_glb > IRAM align = 0x80/ ^$ e6 {% r, q3 w
}
) L8 k9 ]3 c) h
! x+ T/ Z$ L/ _- x
3 K+ _. E6 g9 l$ [' r3 i8 R编译加了-O3 优化参数
& @* U  U) p4 B0 }0 y' Q7 ^* m
' C2 M4 [9 Y5 \& k, A( A" [, {" d1 v8 l* s3 C; m( n
# E) s1 M6 j. Y% T% h) u8 L1 \
5 d. e; b& H" _0 H
6 F+ `/ Z$ p8 A) I7 H

* }2 v  b9 e& u2 l" i
作者: 广州创龙莫工    时间: 2018-8-14 15:48
您好，根据您的描述，暂时不能排查到具体的原因。建议您：可以先不跑双核，单跑dsp的情况下，测试算法的性能，再判断是否是syslink或双核的影响。
作者: 15901123858    时间: 2018-8-14 19:16
想请问下您是在LINUX环境下使用MAKEFILE编译双核工程的嘛？另外SECTIONS中的内容是在.CMD文件中编辑的嘛？
作者: bobhi009    时间: 2018-8-16 12:03
1. 简单的说下原因， 由于创建任务时 ， 由于栈空间地址较大， 所以更换了栈空间的地址， 这导致栈空间新的申请地址是没有开启cache的 ， 所以开启栈空间地址的缓存就可以解决问题
4 ^: U5 Y! U$ I) S4 T) i6 a/ a+ _+ j1 O
2. 相差20倍是算法本身的特性， 偶数帧的计算量比较大



欢迎光临 嵌入式开发者社区 (https://www.51ele.net/) Powered by Discuz! X3.4