嵌入式开发者社区

标题: 自己的算法连续两次运行消耗时间差20倍 [打印本页]

作者: bobhi009    时间: 2018-8-14 09:19
标题: 自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑 ) ^3 u2 W0 Z  D/ V0 J# c
9 c! S2 W, J+ ]2 f% ~( g# w; w
环境: 创龙提供的mcsdk (linux3.3 + bios6 + syslink)% F/ I/ O- b5 j3 H3 q
自己的算法连续两次运行消耗时间差20倍, 而且跟算法本身应该没有关系, 因为算法在dsplink 的开发环境下是运行的没有问题的
$ [; H. ?3 Q" a应该是mcsdk这套开发环境的影响。 有谁知道是什么原因?
8 E9 @+ T2 W! A
1 `% G5 k& W$ h& b0 @8 c  ?' a
6 |* J1 D7 s; ]
下面是统计结果
& b- i* G  B/ b$ d6 y2 ^' F统计方法: 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间    
  P" s% G, J9 m" @: T4 G- `emucycle0_0 = EMUCNT0;
7 {  X" z. e' u7 h& r; wemucycle1_0 = EMUCNT1;+ @( Q3 ]+ s9 \- Z
emucycle0_1 = EMUCNT0;
! V+ o  S2 B0 Z4 t5 zemucycle1_1 = EMUCNT1; ' c  X8 T, \) h/ f, p
emuoverhead = (emucycle0_1 - emucycle0_0);
) S* {* u2 e- g, d' E4 e$ R$ Z5 \( O0 R2 j+ ~
算法();
8 e& t6 A& B' d3 R; ]0 Z  I9 v4 N
6 k1 `# n% M- t! w5 ~7 b& remucycle0_1 = EMUCNT0;7 t; F: ]7 e2 J1 n
emucycle1_1 = EMUCNT1;
+ L8 ^2 t$ Q' X: {4 _2 ~2 g& k, H( x; r% Y: {- l( l9 Z1 O/ {
Cycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;
( R% v0 u+ O% t3 Q+ v9 ?; M' J( H$ O* i2 \" n
$ x- M+ F( a1 M& n. v1 v
统计结果: 每隔一次, 数据处理的时间会是前一次的将近20倍
4 r: w) `8 u4 q0 ]$ ]" V7 Q9 l DSP> cycles: 196468  :  11814000
* j) [! @0 C" y5 g. f DSP> times: 430.85 us with CPU 456.
$ p5 I. ]1 ~, t: f: f& M. L2 j% U! Z DSP> cycles: 3238292  :  11814000
& _/ f7 m2 P* L# f1 P8 h3 M: ^1 B DSP> times: 7101.52 us with CPU 456.
5 Z+ @* U8 ?8 S  S! v! ~% p/ T9 k, h DSP> cycles: 157860  :  11814000( E# k3 l: S$ ~8 O
DSP> times: 346.18 us with CPU 456.  K+ T6 r$ n! ], E- v' s
DSP> cycles: 3265684  :  11814000
6 g* H( C3 e6 Q DSP> times: 7161.59 us with CPU 456.) K& F7 i) N. g# F/ J: Q% J4 M
DSP> cycles: 156344  :  11814000, Y3 v0 |. e) W% \
DSP> times: 342.86 us with CPU 456.
4 N- [8 N( S& f5 q. w7 y DSP> cycles: 3304428  :  11814000
* O3 p" [' J5 `7 K  e( U DSP> times: 7246.55 us with CPU 456.
7 L: G3 s# ]0 ]* `" e. g6 t$ U
2 ?5 l% N4 Y- s4 L% G& S' c9 G设置:相应的表放到IRAM中了+ E& e9 c1 @# m0 D0 g- y
SECTIONS
( ?1 {6 i/ x. b4 _4 B# t" _{. m- `1 x8 o) `0 Z
    .edma_data>IRAM  align = 0x808 T" P) r# U! v
    .audio_glb> IRAM align = 0x80$ M+ G& V  ~+ A* o: c5 {% @# R0 a
        .f_table>  IRAM,  align = 0x80
5 X7 a. H" J/ j% Y        .f_text>  DSP_PROG,   align = 0x80
$ p5 p) j3 ^- G! s! z/ s        .f_glb> IRAM align = 0x80
! }" F+ w1 R' I- L        .ref_glb > IRAM align = 0x800 E0 v: w4 H1 D" Q" N
}
  ~9 I; h3 s' U( i
7 z% `$ t. q  G4 t: d
' i) h+ C, J- x! b% t6 n" q* R编译加了-O3 优化参数
# e' ^5 [  c0 m% g# c- p' H& K4 z" w: v  p

2 e/ `6 k, n+ i
, L4 j) i4 L0 U9 @& G! l/ s
) I3 q; p  ^0 ~

) h6 m9 M) }$ P2 |) y
0 R/ _% L5 l& f9 z+ ^

作者: 广州创龙莫工    时间: 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的 , 所以开启栈空间地址的缓存就可以解决问题1 v8 i5 T  p: U! m  ]) j

9 C  P) q9 V. _. }4 z6 }" Z, ~2. 相差20倍是算法本身的特性, 偶数帧的计算量比较大




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