嵌入式开发者社区
标题:
自己的算法连续两次运行消耗时间差20倍
[打印本页]
作者:
bobhi009
时间:
2018-8-14 09:19
标题:
自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑
* O; y% |- D+ d* H7 D- `- I4 a
- z# G' ^/ `0 X9 k! H, _
环境： 创龙提供的mcsdk (linux3.3 + bios6 + syslink)
7 H8 c' r) E" ^" @. a
自己的算法连续两次运行消耗时间差20倍， 而且跟算法本身应该没有关系， 因为算法在dsplink 的开发环境下是运行的没有问题的
( m- \% I8 |) f( @ k( d% {7 f
应该是mcsdk这套开发环境的影响。 有谁知道是什么原因？
5 P! E' g6 R& \; L( N
6 Z% Y6 J" a. P' K3 @1 z/ O Q
3 w. F8 i+ J* k5 l. N) M
下面是统计结果
2 N9 O9 `0 q" H; ~' b
统计方法
： 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间
# \: m, {3 D9 H$ a$ ?: w
emucycle0_0 = EMUCNT0;
0 u' |7 n$ }9 w
emucycle1_0 = EMUCNT1;
5 M7 F2 j. Z: c
emucycle0_1 = EMUCNT0;
; L) K1 P* ?1 K4 V$ K& w
emucycle1_1 = EMUCNT1;
( `; d# F% h" A7 E! B
emuoverhead = (emucycle0_1 - emucycle0_0);
5 D4 s3 x1 G: v1 @3 C6 c2 X% ^
0 s/ O( M8 N5 ~- \& S) `2 t
算法();
2 J0 b" ]8 \+ b2 P. q, B
4 f9 K# a N4 n2 ]
emucycle0_1 = EMUCNT0;
" q. v- g: b. D1 @1 d( G
emucycle1_1 = EMUCNT1;
1 M% ~2 e6 H9 t# g& B
$ q7 V9 x! a7 m9 z0 |% ~' v
Cycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;
* l, @* W: K) _# W/ r4 A ~
( u ?+ n( ~' G# z) B/ L. k
2 _! Q: @* x! T
统计结果
： 每隔一次， 数据处理的时间会是前一次的将近20倍
6 p0 f# A( H- a- @8 |: W
DSP> cycles: 196468 : 11814000
* U7 y' t% R- N; v8 D6 h) V5 n1 d
DSP> times: 430.85 us with CPU 456.
& P. D1 `; p. m2 N
DSP> cycles: 3238292 : 11814000
^4 e9 E S3 T! q' z% i1 j
DSP> times: 7101.52 us with CPU 456.
9 _4 r9 l" e: F- @9 y
DSP> cycles: 157860 : 11814000
Z! P1 {- y, w
DSP> times: 346.18 us with CPU 456.
3 F* c5 ~5 {3 G5 [' P+ H/ r
DSP> cycles: 3265684 : 11814000
; T; H+ R' e. b H
DSP> times: 7161.59 us with CPU 456.
9 ~; a% E% c2 ~% Z! d
DSP> cycles: 156344 : 11814000
) J- F0 G! e7 d/ D( P( j
DSP> times: 342.86 us with CPU 456.
! ^# j: G, X- i5 X2 S0 @. e
DSP> cycles: 3304428 : 11814000
' S. i/ y% V2 F% h
DSP> times: 7246.55 us with CPU 456.
& a" g6 ^) U7 E+ a' R' }: j% q8 _
$ L# F0 k$ ?# a, Y O( X
设置
：相应的表放到IRAM中了
! T8 ~! o* z" ?
SECTIONS
8 O! H- }! H1 O
{
, S6 I) j3 a- b' ~
.edma_data>IRAM align = 0x80
9 _4 Q }% Y2 V5 ~ t
.audio_glb> IRAM align = 0x80
/ H N" d: v6 J& n
.f_table> IRAM, align = 0x80
- c" T& a- o# S! O9 U0 P
.f_text> DSP_PROG, align = 0x80
$ ^$ ]+ J/ h! e; B3 U$ L$ j% b. o
.f_glb> IRAM align = 0x80
+ X) E5 R r$ `
.ref_glb > IRAM align = 0x80
. ^% Z: a! `9 d* q1 C. j( O9 H( C$ j
}
( U$ ]6 t5 k* b2 {' u/ z$ p
c; b E( U- Z2 V
+ e0 |; u1 P I* s% q( p: F
编译加了-O3 优化参数
& [. b' p0 r2 {/ }% n6 M
: ]+ r0 [( n, j. O
& ?& X \) H8 a
; Z W+ y& V0 ?2 l* z
4 ^* G1 {9 U7 u5 Q) J2 v$ I7 @
8 H; {# T _1 U$ E2 y. Y
$ {" }; d9 O( p) y' 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的 ， 所以开启栈空间地址的缓存就可以解决问题
- Q3 e, B& `6 Y. T" ?" r/ g
# f: | M. L# f
2. 相差20倍是算法本身的特性， 偶数帧的计算量比较大
欢迎光临 嵌入式开发者社区 (https://www.51ele.net/)
Powered by Discuz! X3.4