#13056 - NoMis - Thu Dec 04, 2003 6:41 pm
i want to profile my code. i readed that there is a way to do this in VBA with gprof. i also found this topic in the forum http://forum.gbadev.org/viewtopic.php?t=1164&highlight=gprof but i don't get used to it. does anyone ever profiled a gba application and can tell me how it works.
NoMis
#13068 - Miked0801 - Thu Dec 04, 2003 7:43 pm
We use No$GBA to do our profiling here. It's not the best in the world as our method hogs CPU time away from the app, but it works nicely. Basically, No$ has a feature that allows it to output the contents of a register to disk. We set up a timer interrupt that fires off very quickly, then write out to disk where the code pointer was when the interrupt fired off. Then we have an external program parse this list and compare it against the .map file to translate code pointers to symbols. Finally, we add up all the symbols, and divide against the total in the file to get a percentage of use per symbol. This works great and has been a boon in development.
Mike
#13071 - NoMis - Thu Dec 04, 2003 8:14 pm
I'm a bit in the beginner state so i don't understand completly. i understand the stuff with the timer and the interrupt, writing the LR out every time the interrupt handler calls. but i don't even know what a .map file is and how to parse it.
Is there no easier way to accomplish this using gprof.
NoMis
#13118 - Quirky - Fri Dec 05, 2003 8:17 pm
I have been playing about trying to get profiling working too. Using the -pg (profiling, debugging) option on gcc means you need a valid bunch of profiling routines. These are included in "libVBA.zip" download on the VBA website. mcount, monstart, etc - just like in libgmon.a that comes with some gcc distributions (Mingw for example).
OK, so I've compiled the VBA lib (one .s, one header file) and linked it in to my project, that sorted "undefined ref to mcount" out . But now I get error messages like these at link time, for all modules in the project...
| Code: |
./o/pausemenu.o: In function `show_menu':
./o/pausemenu.o(.text+0x8): undefined reference to `LP0'
./o/pausemenu.o: In function `handle_pause_keys':
./o/pausemenu.o(.text+0x4c): undefined reference to `LP1'
./o/pausemenu.o: In function `move_pause_up':
./o/pausemenu.o(.text+0xcc): undefined reference to `LP2'
./o/pausemenu.o: In function `move_pause_down':
./o/pausemenu.o(.text+0xdc): undefined reference to `LP3'
./o/pausemenu.o: In function `pause_select':
./o/pausemenu.o(.text+0xec): undefined reference to `LP4'
./o/pausemenu.o: In function `pause_deselect':
./o/pausemenu.o(.text+0xfc): undefined reference to `LP5'
|
Anyone know what I'm missing? Where have these LPX references come from? I guess gcc inserts them at the start (end?) of each call, but what am I supposed to link in that defines them?
#13125 - Quirky - Fri Dec 05, 2003 10:43 pm
I should add that I was using devkitadv r5 beta3. And compiling some modules in thumb. That seems to have been the problem, because compiling in arm initially sorted everything out, except my program didn't run (for various reasons that I don't fancy investigating/revising, probably interrupt related...)
So, I was reading the VBA readme for profiling, I should have RTFM a bit closer ealier, and here's what it says:
| Quote: |
| - LPxx undefined when linking (missing . before LP causes the problem) |
The first bug noted in that readme (mov\tip,lr not a valid instruction (typo in gcc/config/arm/arm.h)) seems to have been fixed though, as in the previous devkit I couldn't even compile.
The fix for the undefine ref is to recompile GCC or hack cc1 with a hex editor. As I don't fancy the former much, I have tried the latter and while it links ok, I haven't had much success getting anything to actually run....
#13130 - Quirky - Fri Dec 05, 2003 11:45 pm
I finally go a profile out! I'll write the steps here so that someone else may benefit.
I went back to Devkit Advance B.Sf. (before sourceforge) and hexedited cc1.exe as described in the VBA-SDL readme. This gets rid of 2 bugs, one caused by a \t being in place of a space and the other caused by .LP later being referenced as LP (without the . ) I couldn't get this to work with release 5 b3, but that is probably my fault more than anything.
I compiled my whole project in non debug mode, i.e. no -pg option set. Then I deleted the .o files for the modules I wanted to profile. The one with main in, the one with my renderer and other stuff, etc. It's important not to profile your interrupt routine! Common sense really, but that was one thing that botched my profiling up.
I had to add monstartup(start address, end address); just before my main loop, and a way to dump out the gmon profile by calling moncleanup() (when you get killed in the game). I got the start and end addresses for monstartup from my .map file (-Wl,-Map,file.map), the actual values I guess aren't too important as long as you have the routines you want to profile in the range (?)
Then I recompiled these modules with -pg
ok, so now I had an .elf with profiling enabled. Start VBA-SDL with the options --profile=60 -N game.elf
that means 60hz profiling (--profile=60), and don't fudge up on debug symbols (-N).
I played about a bit in the game, got killed (thus dumping out the gmon.out profile info) and exited VBA.
To see the info, I used this line:
gprof --brief game.elf
if you don't compile with -pg, you can still get a flat profile by using the --no-graph option of gprof.
I hope someone finds that useful. Now to figure out how to get gprof to spit out the profile in a nicer, more understandable form....
#13138 - ampz - Sat Dec 06, 2003 2:54 am
It would be fairly easy to add profiling to a emulator...
#13142 - tepples - Sat Dec 06, 2003 4:09 am
What I do for profiling is just change the blend mode register or the background color (i.e. palette entry 0) before and after the loop I'm trying to profile.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13149 - torne - Sat Dec 06, 2003 6:04 am
| tepples wrote: |
| What I do for profiling is just change the blend mode register or the background color (i.e. palette entry 0) before and after the loop I'm trying to profile. |
Timing a particular loop..etc is not normally the goal of profiling; when I profile code, I am generally interested in seeing what proportion of the processor's time is spent where, in order I can tweak whatever turns out to be the biggest CPU hog.
#13158 - tepples - Sat Dec 06, 2003 4:38 pm
| torne wrote: |
| when I profile code, I am generally interested in seeing what proportion of the processor's time is spent where, in order I can tweak whatever turns out to be the biggest CPU hog. |
OK, my explanation was a bit unclear. I often set color 0 at various points in my game loop: red for this, green for that, white for something else, etc., and back to sky blue at the end. That way, the color of the thickest bar is the biggest CPU hog.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13161 - ampz - Sat Dec 06, 2003 8:24 pm
Your game must look much like the loading screens on the C64 when profiling. :-)
Still, a neat way to do it.
#13165 - Omega81 - Sat Dec 06, 2003 10:57 pm
this might be a stupid question so bear with me. What does it mean to profile your code? are you trying to know how much resources it takes or what?
thank you
_________________
Keep it real, keep it Free, Keep it GNU
#13166 - tepples - Sun Dec 07, 2003 12:05 am
"Profiling" code refers to measuring how fast one or more parts of a computer program runs, in order to improve its time performance. "Profiling in breadth" means measuring the relative amounts of time that different parts of one program take, in order to find likely candidates for heavy optimization. "Profiling in depth" means measuring how long one small part of a program takes, especially in different versions of the program, to see whether changes to a program have in fact made it faster. I tend to use either the color bar method or VCOUNT reads for both types of profiling.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13179 - torne - Sun Dec 07, 2003 2:07 pm
| tepples wrote: |
| torne wrote: | | when I profile code, I am generally interested in seeing what proportion of the processor's time is spent where, in order I can tweak whatever turns out to be the biggest CPU hog. |
OK, my explanation was a bit unclear. I often set color 0 at various points in my game loop: red for this, green for that, white for something else, etc., and back to sky blue at the end. That way, the color of the thickest bar is the biggest CPU hog. |
That makes more sense, but still seems a bit of a vague way to do it. =)
#13218 - FluBBa - Mon Dec 08, 2003 11:16 pm
Someone (was that you Tepples?) said that they even have a "color 0" on the PS2 for that purpose alone.
_________________
I probably suck, my not is a programmer.
#13225 - tepples - Tue Dec 09, 2003 2:09 am
Many systems' video chips have a border color that can be written during draw. The Dreamcast has one, and I've only seen it used for profiling.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#14666 - sasq - Sat Jan 10, 2004 1:46 pm
Yeah the PS2 has a border-color register available only for the sake of optimizing.
Optimizing by measuring rasterime that way has been standard among demo coders since the beginning... I used to have a lot of pencil marks at the side of my amiga monitor :)