嵌入式开发者社区
标题:
自己的算法连续两次运行消耗时间差20倍
[打印本页]
作者:
bobhi009
时间:
2018-8-14 09:19
标题:
自己的算法连续两次运行消耗时间差20倍
本帖最后由 bobhi009 于 2018-8-16 12:00 编辑
6 x$ { j) s7 P( v
# E/ r+ ?$ x$ A/ A
环境： 创龙提供的mcsdk (linux3.3 + bios6 + syslink)
: E0 N) l0 V7 ~4 ?0 F4 p
自己的算法连续两次运行消耗时间差20倍， 而且跟算法本身应该没有关系， 因为算法在dsplink 的开发环境下是运行的没有问题的
: B, s7 V0 Q/ M' D9 S
应该是mcsdk这套开发环境的影响。 有谁知道是什么原因？
. V' V, v9 `& l* E) g
$ F6 A; [. |( L* W$ B
@& Y" M9 h! d# R
下面是统计结果
) H/ ]; k4 W# `+ \. ^. R( N. `! Q
统计方法
： 通过EMUCNT0 EMUCNT1 寄存器统计算法执行周期 再除以主频得到运行时间
# O& N$ k! y6 K2 X E& }" _
emucycle0_0 = EMUCNT0;
( S {7 e) F! X- M" Q5 @5 l' L% Q
emucycle1_0 = EMUCNT1;
/ y+ F: @* H: F5 k; W
emucycle0_1 = EMUCNT0;
2 c5 u9 Z* G9 V# m2 H4 K& r
emucycle1_1 = EMUCNT1;
. P+ I3 Q" B# }. o
emuoverhead = (emucycle0_1 - emucycle0_0);
5 f: K+ H$ z6 B( m6 ?' M3 F4 C% @- [
' c8 t2 _3 ~+ h! I
算法();
$ ~2 Q9 k5 E2 h$ M% W: @. y- q) D5 c
# K2 G, X4 u, U) }* ]. V o0 h
emucycle0_1 = EMUCNT0;
5 P$ |0 J9 i0 W3 i( W J Z
emucycle1_1 = EMUCNT1;
9 Z4 V! l: A+ u! H7 A y% T
- s1 x$ f9 Z5 G7 A2 f
Cycle = ((emucycle0_1 - emucycle0_0) - emuoverhead) * 4;
; g/ s! u% {' @: b: Y* t) D3 s
1 m$ u$ n" c5 x; r
) ^' h6 s9 s. f4 F3 M" k+ `
统计结果
： 每隔一次， 数据处理的时间会是前一次的将近20倍
* E' H' H, c: V, K D, H( j' @* ]
DSP> cycles: 196468 : 11814000
! U$ @$ U1 _1 g# ^5 V2 a) I
DSP> times: 430.85 us with CPU 456.
; f9 C! w9 Z) W2 Z
DSP> cycles: 3238292 : 11814000
% {0 N$ I+ w9 q; l' f2 F: N
DSP> times: 7101.52 us with CPU 456.
% b; O" A4 T5 }4 S% Y9 u
DSP> cycles: 157860 : 11814000
- e: V* I/ \ M! u" ?/ N
DSP> times: 346.18 us with CPU 456.
9 E7 Q, o, a! |0 f, z8 K; @
DSP> cycles: 3265684 : 11814000
& T/ Z1 t8 Y. ?
DSP> times: 7161.59 us with CPU 456.
1 W' y. F- h( s' p7 f& `
DSP> cycles: 156344 : 11814000
% c* x3 I( H+ z% s
DSP> times: 342.86 us with CPU 456.
5 k6 ^) B+ M- K
DSP> cycles: 3304428 : 11814000
2 }# T1 V" s8 u/ J$ x, O" ~ J
DSP> times: 7246.55 us with CPU 456.
2 L4 V) G" x3 Q. J
6 ?2 H9 W3 L2 v
设置
：相应的表放到IRAM中了
7 B! H1 S! h$ v7 c7 b; U8 I8 L
SECTIONS
. ~4 f8 d. W. o9 s2 Z: ?4 Q+ I
{
* b. z; ?# V5 v; E" x4 f4 G
.edma_data>IRAM align = 0x80
. U) W, U3 c' y) n- v
.audio_glb> IRAM align = 0x80
- b$ b2 w8 D5 ^# y
.f_table> IRAM, align = 0x80
1 m5 t+ I* S1 M2 f) G1 ?7 C
.f_text> DSP_PROG, align = 0x80
& Q& M$ R* W7 U
.f_glb> IRAM align = 0x80
" T5 [, ?; i/ i- e3 E
.ref_glb > IRAM align = 0x80
& i x. _" t9 [6 C, N4 M
}
5 t/ o* h$ ~3 n7 n' S, ~, q4 F
. X* d' K% v, g& H& G8 }; B
- i( Z% S5 \' O# B9 u; u# F5 p% I
编译加了-O3 优化参数
) G3 l/ C$ a1 u$ O
2 F! t, H' ~4 \6 U$ `$ {
5 y* z3 H. `0 Z% ^8 N7 a
6 }1 r3 a5 Y) |2 P% q
# L& y. i# } |- p8 _9 m' g4 @
% ^/ P+ b3 D1 C& |% D
+ d1 L+ Z6 X+ l8 Z% n Z4 O
作者:
广州创龙莫工
时间:
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 C! l* I+ S' c1 Z: s
, _. H6 k' x' d1 ]
2. 相差20倍是算法本身的特性， 偶数帧的计算量比较大
欢迎光临 嵌入式开发者社区 (https://51ele.net/)
Powered by Discuz! X3.4