Hi Lone,
I think generally we can roughly split the task of profiling into two distinct categories.
1. Microbenchmarking
2. Full-system profiling
For
Microbenchmarking specific parts of code, a full-program profiler doesn't always do such a great job anyway. You can either:
- Extract the functions of interest to a smaller program of interest you can run through xsim as I mentioned previously (using the --gprof or --trace option to get some output to analyse).
or
- Use xscope with 'start_stop' probes. These probes just send a timestamp + id code up to the host, which can then be viewed with a program like 'gtkwave'. As a quick example, I converted the 'simpleLoop' program to send these probes.
You can build it with a command like "xcc -target=XK-EVK-XU316 simpleLoop.c ./simpleLoop.xscope -o simpleLoop.xe"
Then you can run it on hardware with a command like "xrun --xscope-file ./simpleLoopOut ./simpleLoop.xe" (connect in xgdb has a similar argument)
Then you can use gtkwave to open the simpleLoopOut.gtkw file and view the waveforms. (you should also be able to view the .vcd file with any VCD viewer)
simpleLoop.c:
Code: Select all
#include <math.h>
#include <stdio.h>
#include <xscope.h>
int main(){
int i;
float x = 0;
for (i = 0; i < 2000; ++i){
xscope_start(SIN_FUNCTION);
x +=sin(x);
xscope_stop(SIN_FUNCTION);
}
printf("Done with computation\n");
return 0;
}
simpleLoop.xscope:
Code: Select all
<xSCOPEconfig ioMode="basic" enabled="true">
<Probe name="sin function" type="STARTSTOP" datatype="NONE" units="t" enabled="true"/>
</xSCOPEconfig>
Docs on xscope target library:
https://www.xmos.com/documentation/XM-0 ... brary.html
Docs on xscope config file:
https://www.xmos.com/documentation/XM-0 ... ope-format
For
full-system profiling, where you're trying to figure out what your system is generally doing, it can be useful to use a technique similar to the "poor man's profiler"
https://poormansprofiler.org/
In short: start your program, then stop it in xgdb after a short (random) period of time. When it is stopped, investigate what it is doing and make some notes. Then repeat this a few times, and you will probably notice some patterns emerge, which will probably be useful.
If you want, it is possible to script this (as demonstrated in the above website). You will lose the detail of doing a full investigation, but might get some nice high-level information.
Just be aware that if your system is doing anything real-time critical, then all of the real-time guarantees will have been broken by stopping it in the debugger. Therefore you may need to re-start the program between samples.
If you're interested in reading more about this technique, this stack overflow post has a bunch of interesting thoughts on one person's exploration of using gdb for profiling:
https://stackoverflow.com/a/1779343/4798231
Hope this is helpful, let me know if you would like any more pointers.
Cheers,
Ciaran