嵌入式开发者社区

标题: 自己的算法连续两次运行消耗时间差20倍 [打印本页]
作者: bobhi009    时间: 2018-8-14 09:19
标题: 自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑 1 v9 v9 ]1 ^, K
( }5 e, n+ _- F( R6 R
环境： 创龙提供的mcsdk (linux3.3 + bios6 + syslink)
' M1 O7 N5 T* d" C! A自己的算法连续两次运行消耗时间差20倍， 而且跟算法本身应该没有关系， 因为算法在dsplink 的开发环境下是运行的没有问题的
* E0 `/ B; ^) k" w9 v2 J) y应该是mcsdk这套开发环境的影响。 有谁知道是什么原因？0 F. ]# M: c/ Z7 M% d: O3 d5 A' x' \

8 B: ^( u2 K' r, n+ `6 z9 p* s8 Y$ ^4 L1 t4 k
下面是统计结果
/ H! Y& n0 W2 g# U3 \统计方法： 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间    
# b1 I, l- q' [/ Vemucycle0_0 = EMUCNT0;% }5 x; ?0 g$ F% k8 e% _
emucycle1_0 = EMUCNT1;
& T0 e; [( M; I, b: }) R2 Z6 m( f, Semucycle0_1 = EMUCNT0;* ~! o6 h" j* ^; ~0 o" R' c
emucycle1_1 = EMUCNT1;
! }6 n) O1 L- [/ B1 _emuoverhead = (emucycle0_1 - emucycle0_0);' f' p& \9 ~" ]

9 b& Q! [+ X3 c# i% r1 C" ?  M算法();2 f5 b, O9 ]3 o. T1 c" v

9 u& v0 v" ]% p" X; }! m" I' cemucycle0_1 = EMUCNT0;
) \3 P8 W, K# h7 n- j, Yemucycle1_1 = EMUCNT1;" J! C  v5 C, ?, _" h' a. R' L

- C3 g* M* g) r. x$ s* w% ~( }Cycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;& f5 t" R4 Q: k4 q8 q4 w# p( f7 i
7 V/ l( A7 j/ y& g

. u: i2 b6 P' D! B# F- X, {* b统计结果： 每隔一次， 数据处理的时间会是前一次的将近20倍$ J3 D7 ~+ C$ L4 l7 j
DSP> cycles: 196468  :  11814000
9 |% F8 V9 x' Y/ c9 }5 r1 u6 o DSP> times: 430.85 us with CPU 456.
2 i; s5 H* [5 E DSP> cycles: 3238292  :  118140009 A1 M$ u- o, _) t% x# F
DSP> times: 7101.52 us with CPU 456.0 c! I. z, @' W, x
DSP> cycles: 157860  :  118140001 [2 D  d- w- W9 t- ~  p! {; s
DSP> times: 346.18 us with CPU 456.
9 T2 a' M: o/ }4 y DSP> cycles: 3265684  :  11814000/ E% h4 Q5 n4 K$ U) M3 I
DSP> times: 7161.59 us with CPU 456.
/ @, P6 H( d- c2 P DSP> cycles: 156344  :  11814000
9 W! _! M  }, O/ B' l DSP> times: 342.86 us with CPU 456.
6 q9 w( y$ a& w  b DSP> cycles: 3304428  :  11814000
; E/ F. r5 _: Q$ L DSP> times: 7246.55 us with CPU 456.
& u- T) @% c$ f5 {7 o
9 A$ m) r. \$ H- k  @* }- O3 ^设置：相应的表放到IRAM中了- w( m. Z, n6 w
SECTIONS
9 q0 v; P3 \' z8 A6 T9 w* k3 o{8 ?8 i9 j5 C% `/ Y% ^
    .edma_data>IRAM  align = 0x808 Z: t2 Q* s( E
    .audio_glb> IRAM align = 0x80& \- c* _' S7 v: l5 O& M; x
        .f_table>  IRAM,  align = 0x80 4 I0 @7 M' a2 d: H) k# b
        .f_text>  DSP_PROG,   align = 0x80
6 z" A; E, N6 f8 K9 ^0 z) D        .f_glb> IRAM align = 0x800 P4 |  J& e  _* f, A2 x
        .ref_glb > IRAM align = 0x80
1 s2 v$ p, w9 J& E( L}
: Q/ @! T8 E9 h: J; G: X, T% v/ T3 L- z' X7 B+ r
4 t4 l& i3 v" C# G1 Z, d
编译加了-O3 优化参数
) b. I" G# [& I, a. G! |
: w+ H! U& K5 D, h
) W9 F' j- z8 I0 m/ K: o  Q1 J  a6 g2 ?3 f- L7 N# l3 A% m3 w- g, s, @

+ C: y6 ?; N$ w9 q9 i# z  {$ y6 S$ a! M: v2 H' s3 e5 G  x

) u/ L( H+ }  f+ e& n
作者: 广州创龙莫工    时间: 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的 ， 所以开启栈空间地址的缓存就可以解决问题2 q9 K/ R' ]. ~+ X9 y
# x4 m% m8 e& r8 K' \
2. 相差20倍是算法本身的特性， 偶数帧的计算量比较大



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