嵌入式开发者社区

标题: 自己的算法连续两次运行消耗时间差20倍 [打印本页]
作者: bobhi009    时间: 2018-8-14 09:19
标题: 自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑
" n3 d, t' Z$ A) o& E. s3 d9 z  E5 I, s" P6 e8 ?' M& c
环境： 创龙提供的mcsdk (linux3.3 + bios6 + syslink)
! c& w& f  m2 r# H) ]1 `" n自己的算法连续两次运行消耗时间差20倍， 而且跟算法本身应该没有关系， 因为算法在dsplink 的开发环境下是运行的没有问题的( @. t# b" r% \* S. w
应该是mcsdk这套开发环境的影响。 有谁知道是什么原因？
; t; y- z! v0 j8 Z* F
+ k: D8 k$ ^% T: w  O/ b2 j) L  B4 x4 L! |$ f! b8 Y
下面是统计结果* E+ w7 {: }7 }; N  o
统计方法： 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间    
( \. f' `% D5 x$ m4 [+ X( k- X# ?" Xemucycle0_0 = EMUCNT0;9 f4 U) b/ z2 k
emucycle1_0 = EMUCNT1;
1 ]+ n2 |& I' ?9 z# ^; Oemucycle0_1 = EMUCNT0;" ?# k: F7 ^2 t% O$ l1 _5 t1 h% a
emucycle1_1 = EMUCNT1; ; U- D( O1 U5 `; t
emuoverhead = (emucycle0_1 - emucycle0_0);+ ~3 M, e/ J3 }! q8 I

0 x- S) ?/ h" @) s1 _6 ?算法();
7 j* ], P0 G( U! d! `! q2 s
) L8 T  G! n5 y7 n6 X8 D* demucycle0_1 = EMUCNT0;: N. W( ?- B: U/ M- N, {
emucycle1_1 = EMUCNT1;" ~0 b: Z2 N( V

% F9 w  M8 a& x! Q9 KCycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;% V3 P7 m& o5 d: |  s

/ f; K' L) ^/ c1 D+ @  [
3 V' Z% `) U* j& K  W统计结果： 每隔一次， 数据处理的时间会是前一次的将近20倍* l$ D1 N6 d9 d5 b) y( e6 U
DSP> cycles: 196468  :  11814000+ m9 S* s5 ~  \& {: i% S
DSP> times: 430.85 us with CPU 456.
) P6 l- H. u% Q DSP> cycles: 3238292  :  11814000
% H( K! @5 @0 Y0 [ DSP> times: 7101.52 us with CPU 456.
# x6 c" i; f/ y! z& w9 P! F, z DSP> cycles: 157860  :  11814000: A4 P3 C4 J: m, f7 c3 U
DSP> times: 346.18 us with CPU 456.
7 W* v* n# W$ X9 c5 r DSP> cycles: 3265684  :  11814000/ U2 u( l0 U& s9 Q, y; E
DSP> times: 7161.59 us with CPU 456.) M: ^2 N7 H# P1 ]5 N8 p7 ?6 a) q- \
DSP> cycles: 156344  :  118140000 R, q- e/ W: O/ {. S3 l; `
DSP> times: 342.86 us with CPU 456.
/ ~3 C6 w$ e6 r& H- E+ R DSP> cycles: 3304428  :  118140009 @/ a2 q7 w9 f' J4 a( E% v0 _
DSP> times: 7246.55 us with CPU 456.
5 c6 [+ l. ?+ _7 S( T6 p; Y- Y4 |; I7 F) Q) w. v: ]
设置：相应的表放到IRAM中了
/ S: E- I7 N8 m; x+ t7 n- SSECTIONS0 V, w3 ?, h" D7 e
{$ s  U7 c$ o  ^6 Y, G
    .edma_data>IRAM  align = 0x80' ^# ?- }$ W1 O2 N, {
    .audio_glb> IRAM align = 0x80
  h+ d( Q4 }% o        .f_table>  IRAM,  align = 0x80 4 y- o0 X' l! M9 ?6 Y" e7 k& ?  o
        .f_text>  DSP_PROG,   align = 0x80
  r0 {0 H3 E7 J* c4 I        .f_glb> IRAM align = 0x80) H3 q( i; J1 q( C3 z2 X
        .ref_glb > IRAM align = 0x80
1 n9 h0 |% G* G  V}3 Z: \; N2 p! q, T- D6 V

( E& W8 E1 v& r+ Z4 s: l* ]8 l6 O! S
编译加了-O3 优化参数: w* l, Z2 s% n7 f* ]  N

: }! e7 n- V, {, X4 _7 g
+ Z" z8 V, l0 l, g( @6 p; F- F* O9 O, h
" X7 g. ]0 j( X* R4 Z

$ j' I" \$ K% |1 k! N4 ^
; J3 ^4 C( K! T5 t! M7 z- d# |8 W
作者: 广州创龙莫工    时间: 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的 ， 所以开启栈空间地址的缓存就可以解决问题" I  F! T, V9 @# Q- s) q) t' w' X% ]0 M
* e1 k( a) X' ^% ~0 J* A
2. 相差20倍是算法本身的特性， 偶数帧的计算量比较大



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