Example 2: Benchmarking the Relative Performance of
Memories
the approximate number of millions of processor cycles executed (see
Table
2-1). The first row in
Statistical Profiler's final estimates of the percentage of execution time
spent in the
bubble_sort()
differ slightly from those in
bubble_sort()
Table 2-1. Typical Results from Example 2
Code and Data Disposition
Everything in external memory
in L2 memory
bubble_sort()
in L1 code memory
bubble_sort()
Everything in external memory, plus
code cache on
All code in external memory, plus code
cache on, plus data arrays in L1 data
memory
By default, VisualDSP++ maps as much code and data as possible to inter-
nal L1 and L2 memories when building a program. However, this
project's options contain a setting that maps all of the code and data from
into external memory, and so the just obtained profiling results
Sorts.c
represent the worst-case performance for our application. In the following
sections, we will modify the placement of some parts of the program and
observe the effects.
One way to alter the default placement of an individual code function or
data variable is to place a
C source file. This directive causes the VisualDSP++ compiler to place the
item in the output section named in the directive. The available section
names are defined in the linker description (
2-6
Table 2-1
and
quick_sort()
Table 2-1
is using most of the processor time.
Elapsed
Seconds
19
13
13
10
1
section
Getting Started with ADSP-BF548 EZ-KIT Lite
shows typical values, along with the
functions. Your figures may
but still will show that, as expected,
Core
Cycles
9533
7079
6866
5367
612
directive in front of its definition in the
) file that the project
.ldf
Bubble Sort
Quick Sort
%
%
74
23
66
30
64
32
87
11
68
25
Need help?
Do you have a question about the EZ-KIT and is the answer not in the manual?