[Openmcl-devel] Profilers for OpenMCL

[Gary Byers]

On Tue, 16 Sep 2003, Gary King wrote:

> Are there any profilers (beyond Kantrowitz's) available for OpenMCL?
>
> Thanks,
> --
> Gary Warren King, Lab Manager
> EKSL East, University of Massachusetts * 413 577 0176
>
> "If all you do is ask Ph.D. computer scientists what they want, all
> you'll get is stuff that's good for Ph.D. computer scientists."
>    -- Anita Borg, Founder Institute for Women and Technology
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>

I've done a little bit of work trying to get Apple's CHUD profiling tools
working with OpenMCL.  A little while ago, I was optimistic about this;
now I'm not so sure.

I should qualify that a bit: the CHUD tools certainly work, but they
don't always understand what they're looking at, and therefore can't
always present that to you.  They know how to map a PC value to a C
function name, but have a little more trouble doing anything useful
with lisp code.  (One complicating factor is the fact that lisp code
can be moved around by the GC; there are ways of addressing that.)
So, if you use Shark/Shikari (its old name) to profile some OpenMCL
code, it'll tell you that you're spending a lot of time in a lot of
anonymous places.  (You probably knew that already ...)

Last year's version of the CHUD tools (2.5.x, IIRC) -was- able to
use "traceback tables" (embedded debugging information that follows
a function's code) to identify a function in Shikari.  That functionality
seems to be missing from the newly released CHUD 3.0's profiling application
(SHARK).  (Those who pay very, very close attention to release notes and
such might notice that OpenMCL recovered the ability to embed traceback
tables a few months ago, and that they're currently not generated by
default.  Hmm.  Actually, the release notes were probably even vaguer
than that, now that I think about it.)

It's certainly possible to access the CHUD framework via the FFI, and
I've played around a bit with this.  At the time that I did so, there
was no easy way to lookup a foreign function given an address from
lisp (something like #_dladdr on ELF-based systems); there's now
some lisp-callable code in the OpenMCL kernel to do this.

So, based on my current understanding of the issues, we could either:

 a) pursue the idea of developing lisp-based tools based on CHUD 3.0
 b) stick to CHUD 2.5.x and let Shikari do the dirty work of presenting
    sampling information.
 c) do something else that I haven't thought of.

I'm viewing this whole issue in terms of OSX/CHUD because I don't know
of any other way (on OSX or Linux) to get a reliable, high-frequency
timer interrupt.  Another approach is to just use the low-frequency
(100Hz) interrupt generated by SIGPROF to do time-based sampling; I'd
tried that in 0.13, which used that 100Hz interrupt to drive the lisp
scheduler, and the profiling tools I tried to develop said that
everything spent 100% of its time in the scheduler ...  Since that's
not a factor, the 100Hz timer could at least be used to give you a
coarse idea of where your program's spending its time, and that'd
certainly be better than having little or no idea ...

Gary Byers
gb at clozure.com






_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel