Re: [Haskell-cafe] SoC idea: interactive profiling

Hello Gergely, 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): http://www.nabble.com/ThreadScope:-Request-for-features-for-the-performance-... ThreadScope: http://raintown.org/?page_id=132 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 .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 repository) 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. -- Donnie Jones On Sun, Mar 22, 2009 at 4:03 AM, Patai Gergely wrote:

Hello all,

I entered a little proposal in the issue tracker:

http://hackage.haskell.org/trac/summer-of-code/ticket/1570

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 profiling?

Gergely

-- http://www.fastmail.fm - Does exactly what it says on the tin

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe