[Openmcl-devel] Profiling for CCL?
Gary Byers
gb at clozure.com
Sun Dec 1 18:52:20 PST 2013
Apple stopped supporting their (generally very good) CHUD tools in OSX
10.7. I've heard that
people have used the general idea described in the CHUD/Shark section of
chapter 12 to
generate a heap image with Mach-O symbol information and gotten useful
information
out of the current profiling tools in XCode, but have never done so.
(One of many reasons
that I still use 10.6 for most things is that I continue to find CHUD
useful.)
oprofile is still being developed and maintained on Linux; for the last
few years, another
Linux profiling tool ("perf") has also been available. On
Debian/Ubuntu, perf is available
as part of a "linux-tools" package. Using perf with CCL generally involves:
- loading the code that you want to profile
- saving an image with ELF symbols prepended, as described in the
oprofile section of chapter 12
- using "perf record" to generate profiling information:
$ perf record ccl -I /path/to/image-with-elf-symbols -e '(progn (dotimes
(i 1000) (fact 1000)) (quit))'
- using "perf report" to analyze that info:
$ perf report
Both (what's left of) the CHUD support and the oprofile/perf stuff
depend on OS support for the
on-chip performance counters offered by most modern CPUs. Their output
tends to be very
detailed and very low-level; they give a bottom-up view of what's
actually going on, but many
people have said that they find it difficult to see the correlation
between that info and code that
they're familar with.
I don't know of any similar OS support on other platforms; I once tried
to install something that
claimed to provide such support on Windows, but got the Windows
equivalent of a kernel panic
before I got very far in trying to use it.
Hans Huebner's advice-based profiler (available in
"ccl:contrib;huebner;advice-profiler;") tries to
take a different approach: it wraps sampling code around existing
definitions. There are inherent
problems with some aspects of this (e.g., it may replace tail-recursive
functions with non-tail-recursive
versions), but when it can be used its output may be easier for most
people to understand. I don't
know if that code is in fact portable to (e.g.) Windows, but don't know
of a deep reason why it couldn't
be. (IIRC, the code tries to use the highest-resolution timing
facilities that it can find; I'm not sure
how hard it tries to find such a thing on Windows.)
On 12/1/13 6:26 PM, Mark H. David wrote:
> Does anyone do profiling on CCL? What's good to use? Saw online (http://ccl.clozure.com/manual/chapter12.html) something for Linux and Mac, two approaches. Anything cross platform? Anything for Windows?
>
> Thanks,
>
> -Mark
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
More information about the Openmcl-devel
mailing list