[Haskell-cafe] SoC idea: interactive profiling
donnie at darthik.com
Sun Mar 22 13:00:45 EDT 2009
Last Summer, I also proposed a Google SOC project for profiling,
called Parallel Profiling Support for GHC. This project was denied
for the Google SOC mostly due to the scope of the project and the
concern that the project would take far longer than the Summer. As
this project was/is for my Master's thesis, I am still working on it
and we have made a lot of progress, but the Haskell mentors were
correct in saying it would take much longer. My recommendation to
you would be to define your scope to something that is clearly
feasible in the time-frame allotted for Google SOC.
Also, you probably want to familiarize yourself with the work we've
done to improve profiling in GHC.
ThreadScope (Pre-Announcement, Request for Features):
The EventLog framework (used by ThreadScope) is now available in the
GHC RTS ($GHC_ROOT/rts/eventlog) and has been committed to GHC HEAD.
Download GHC HEAD, build GHC, then compile a Haskell program with
-eventlog and execute with +RTS -l -RTS to output a
<prog_name>.eventlog binary file.
We also have available a visualizer agnostic library that parses the
binary eventlog files to be used by any visualizer. I will be
releasing that soon as a cabal package called ghc-events (but it is
available now on http://code.haskell.org/ghc-events as a darcs
Caveat: we are still working on all of these components, so there may
be changes to come. Of course, we expect to keep the ghc-events
library in-step with changes to the GHC RTS eventlog framework to
ensure ghc-events can be used as a library.
I'm not sure if any of this could be useful to you directly for your
Google SOC project, but I wanted to be sure you were aware of the
updates to GHC for profiling.
Just to reiterate, make sure that the scope of your project is well-defined. :)
If you have any questions, feel free to ask.
Best of luck.
On Sun, Mar 22, 2009 at 4:03 AM, Patai Gergely
<patai_gergely at fastmail.fm> wrote:
> Hello all,
> I entered a little proposal in the issue tracker:
> As I see it, the graphical part could be a warm-up exercise with an
> already useful product, and interaction with the rts would be the actual
> challenge. Reasoning about laziness is far from trivial (at least I
> often feel lost when trying to grok all the interaction within Reactive
> ;), and being able to browse profiler output on the spot is something I
> felt the need for a few times already. Eventually, this could be a
> contribution to an IDE project, even though it could as well remain a
> standalone application for all the emacs/vi folk.
> Profiling tools for parallel programs are in the make already, but I
> haven't seen anything more convenient than hp2ps and little add hoc
> solutions for analysing resource usage patterns. How do you all go about
> http://www.fastmail.fm - Does exactly what it says on the tin
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe