gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Profiling

#151837 - nczempin - Wed Mar 05, 2008 8:35 pm

To get acquainted with DS coding, I have started playing around with coding Game of Life and optimizing the hell out of it, along the lines of Abrash's Black Book, chapters 17 and 18.

Once I had a working program, the next step for optimization was, of course, getting the code profiled.

I couldn't find a Profiler for the DS, so I guessed I had to hand-profile with using a timer (incidentally, why is the clock() function not implemented in libnds?).

In the medium term, I would like to be able to instrument and profile my code, on an Emulator or on a DS. Surely this would be useful to others too.

So, has anybody spent any sizable number of brain cells on how to get a profiler running for DS homebrew? Call-graph would be a good start, but a by-instruction like VTune would be cool too. Perhaps the ARM7 can be coerced into checking on its brother somehow, as any performance optimization is perhaps likely to focus on the ARM9 code.

#151838 - silent_code - Wed Mar 05, 2008 9:10 pm

simon has posted his profiler (the one he used for his quake port). look for it.
(it's strange to write in english to a german, when one's living there, too! :^D )

#151842 - nczempin - Wed Mar 05, 2008 9:48 pm

silent_code wrote:
simon has posted his profiler (the one he used for his quake port). look for it.
(it's strange to write in english to a german, when one's living there, too! :^D )


You'll get used to it ;-) We can always switch to German in any pms.

I'm actually from Berlin too (Friedenau), but have cancelled my lease; I will pack my stuff next week and drive down next weekend.

But enough of the private business ;-)

I'll go look for the quake profiler, I hope it's universal or can be adapted.

#151845 - nczempin - Wed Mar 05, 2008 10:29 pm

nczempin wrote:
silent_code wrote:
simon has posted his profiler (the one he used for his quake port). look for it.


I'll go look for the quake profiler, I hope it's universal or can be adapted.


Hmm.

What I found in the DS quake I source code (direct dl) was this:
CygProfiler

While of course it would be nice to be able to profile your code without having to include actual call_profiler() lines, I guess it is a good enough start.

Only one thing bothers me: It saves the results as a file (like most profilers do), but I have heard problems with SD cards' filesystems being corrupted etc.

If there really are that many issues with FSs, perhaps one should just use what commercial cartridges do: save to the internal flash. Presumably, there are ways to do so in libnds and friends...

Of course for this profiler, I would have to change the source. Not wanting to change too many things at once, I'll try to get it working with the state-of-the-art FS-lib, whichever that is.

#151881 - simonjhall - Thu Mar 06, 2008 10:54 am

I stuck the files for this on the quake web site many moons ago (and put a link on gbadev, too)
http://quake.drunkencoders.com/profiler/cyg-profile.c
http://quake.drunkencoders.com/profiler/cyg-profile.h
http://quake.drunkencoders.com/profiler/resolve (rename this file to resolve.pl once you've downloaded it)

To use it, again I've put instructions in another thread on here, compile with -finstrument-functions -mpoke-function-name on the source that you want to instrument (don't do it to interrupt handlers, or stuff that does file access cos you'll get it stuck in a loop and run out of stack).
Call cygprofile_begin() to set up the data structures, then call cygprofile_enable() to start instrumentation and then when you want to stop profiling your code (eg when you quit your program) call cygprofile_end(). Job done.

You do not need to do this for each function you want to profile - it will instrument every function called until you call cygprofile_end.

(btw you'll want to wiggle the code slightly to call your own file-writing and opening functions, plus you need to provide the number of hblanks since program start in 'hblanks')
_________________
Big thanks to everyone who donated for Quake2

#151886 - Dwedit - Thu Mar 06, 2008 11:23 am

I once made a modified version of VisualBoyAdvance named "VBA_TEH_PROFILER", which counted the number of times each address was executed (up to 32 bit number). Very useful for profiling ASM code.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#151891 - simonjhall - Thu Mar 06, 2008 12:08 pm

Oh man I would kill for one of those on the DS. I was considering writing something similar that ran on the real machine (eg you'd pass in a function pointer and it would then emulate and time that function). Not enough free time...
_________________
Big thanks to everyone who donated for Quake2

#151894 - nczempin - Thu Mar 06, 2008 12:46 pm

simonjhall wrote:
Oh man I would kill for one of those on the DS. I was considering writing something similar that ran on the real machine (eg you'd pass in a function pointer and it would then emulate and time that function). Not enough free time...


surely one of the open-source emus could be expanded in a collaborative effort?

and you'd just need to stretch the little free time out to a longer period.

There's nothing like a commercial deadline to get a project finished quickly, but there's nothing like a persistently improving open-source project to eventually catch up and surpass...

#151996 - wintermute - Fri Mar 07, 2008 11:45 pm

Quote:
There's nothing like a commercial deadline to get a project finished quickly, but there's nothing like a persistently improving open-source project to eventually catch up and surpass...


Name one.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#152011 - HyperHacker - Sat Mar 08, 2008 4:48 am

7zip? Maybe?
_________________
I'm a PSP hacker now, but I still <3 DS.

#152017 - nczempin - Sat Mar 08, 2008 12:02 pm

wintermute wrote:
Quote:
There's nothing like a commercial deadline to get a project finished quickly, but there's nothing like a persistently improving open-source project to eventually catch up and surpass...


Name one.


devkitPro

#152135 - elhobbs - Mon Mar 10, 2008 3:30 pm

not to discredit devkitarm or libnds, but I bet it is easier to develop for the DS using the nintendo toolchains and libraries. I will grant persistently improving, but I doubt that they surpass the official toolchains.

#152137 - wintermute - Mon Mar 10, 2008 3:54 pm

You've obviously never been a licensed Nintendo developer then :P

Seriously though, there are some aspects of devkitARM that are easier than the official tools, some places where we have more freedom and a few places that still need a lot of work. We certainly haven't surpassed those tools but we're definitely catching up.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#152151 - nczempin - Mon Mar 10, 2008 7:38 pm

nczempin wrote:
wintermute wrote:
Quote:
There's nothing like a commercial deadline to get a project finished quickly, but there's nothing like a persistently improving open-source project to eventually catch up and surpass...


Name one.


devkitPro


With a bit of subconscious work, I have come up with a few more:
ogg vorbis
ext3 (ext4?)
firefox
netbeans
eclipse
xvid
azureus
tex


I haven't seen the official devkits, so I can't really say what they are like. But I've read a post in one of these boards that claimed only one little thing was missing. If that missing piece really is a requirement, then someone will scratch that itch.

I also find it telling that apparently many commercial developers are willing to shell out for no$gba, when there is an official emulator out. Admittedly, no$gba is not an open-source project.