SoC idea: interactive profiling
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
yep, sounds great to me :-)
although with some hacks one can already have a poor mans real time
interface for heap profiling:
http://www.haskell.org/ghc/docs/latest/html/users_guide/hp2ps.html#id2677301
I agree that the effect of laziness can be very hard to grasp, sometimes it
even feels that I traded the annoying side effects from imperative
programming to "lazy effects" in functional programming... Can't seem to
have my cake and lazily eat it :-)
On Sun, Mar 22, 2009 at 10:03 AM, Patai Gergely
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
although with some hacks one can already have a poor mans real time interface for heap profiling: http://www.haskell.org/ghc/docs/latest/html/users_guide/hp2ps.html#id2677301 I'm aware of that, even did it myself a few times. That's part of the reason why I want something better. ;)
I agree that the effect of laziness can be very hard to grasp, sometimes it even feels that I traded the annoying side effects from imperative programming to "lazy effects" in functional programming... Can't seem to have my cake and lazily eat it :-) It's still less painful than "old-fashioned" side effects. You can always look at it as an opportunity to better understand your code, at least for me it was always enlightening in some way when I found the right spot for a `seq`.
Gergely -- http://www.fastmail.fm - And now for something completely different
Hello
"PG" == Patai Gergely writes: PG> Hello all, I entered a little proposal in the issue tracker:
PG> http://hackage.haskell.org/trac/summer-of-code/ticket/1570 PG> As I see it, the graphical part could be a warm-up exercise with an PG> already useful product, and interaction with the rts would be the PG> actual challenge. Reasoning about laziness is far from trivial (at PG> least I often feel lost when trying to grok all the interaction within PG> Reactive ;), and being able to browse profiler output on the spot is PG> something I felt the need for a few times already. Eventually, this PG> could be a contribution to an IDE project, even though it could as PG> well remain a standalone application for all the emacs/vi folk. PG> Profiling tools for parallel programs are in the make already, but I PG> haven't seen anything more convenient than hp2ps and little add hoc PG> solutions for analysing resource usage patterns. How do you all go PG> about profiling? May be providing profiling information for kcachegrind will be a good solution? For example, there are tools for PHP, that allow to view collected information in kcachegrind, and get interactive zooming, etc. -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/
Hello, On Sun, Mar 22, 2009 at 04:08:59PM +0100, Alex Ott wrote:
May be providing profiling information for kcachegrind will be a good solution? For example, there are tools for PHP, that allow to view collected information in kcachegrind, and get interactive zooming, etc.
This is really awesome idea, you're totally not alone who would want this! -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
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
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
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. Yes, I'm aware of that trap. However, I think the ideas I proposed (rather vaguely, I have to admit) could be handled in three months, especially since I can familiarise myself with the relevant parts of the rts before actual work starts, and the first part of the task doesn't even require significant changes, if any.
ThreadScope: http://raintown.org/?page_id=132 I know about that one, that's another reason why I wanted to explore the area of more user-friendly space profiling instead: it seems somewhat neglected. Of course that might be because people don't feel an urgent need for more powerful tools, but I can't tell that without asking the community.
The EventLog framework (used by ThreadScope) is now available in the GHC RTS ($GHC_ROOT/rts/eventlog) and has been committed to GHC HEAD. Thanks for the pointer, I'll check it out.
Just to reiterate, make sure that the scope of your project is well-defined. :) Of course I intend to list some specific subtasks in my proposal, preferably the kind that makes life much easier with minimal changes to the codebase. :)
If you have any questions, feel free to ask. I'll see if I have some after looking at the code. For the time being there's only the one I'd ask anyone: how do you think space profiling could be made more convenient?
Gergely -- http://www.fastmail.fm - Access your email from home and the web
Hello Gergely,
2009/3/22 Patai 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. Yes, I'm aware of that trap. However, I think the ideas I proposed (rather vaguely, I have to admit) could be handled in three months, especially since I can familiarise myself with the relevant parts of the rts before actual work starts, and the first part of the task doesn't even require significant changes, if any.
ThreadScope: http://raintown.org/?page_id=132 I know about that one, that's another reason why I wanted to explore the area of more user-friendly space profiling instead: it seems somewhat neglected. Of course that might be because people don't feel an urgent need for more powerful tools, but I can't tell that without asking the community.
I do agree that a visualizer would be useful for space profiling (and all areas of profiling for that matter).
The EventLog framework (used by ThreadScope) is now available in the GHC RTS ($GHC_ROOT/rts/eventlog) and has been committed to GHC HEAD. Thanks for the pointer, I'll check it out.
Just to reiterate, make sure that the scope of your project is well-defined. :) Of course I intend to list some specific subtasks in my proposal, preferably the kind that makes life much easier with minimal changes to the codebase. :)
Be sure to include a schedule too. I think there was an example Google SOC project to follow as a guideline.
If you have any questions, feel free to ask. I'll see if I have some after looking at the code. For the time being there's only the one I'd ask anyone: how do you think space profiling could be made more convenient?
As I said above, I do think a visualizer for space profiling would be an improvement over the current log file output. I'll let you know if I think of some other suggestions. -- Donnie Jones
participants (5)
-
Alex Ott -
Donnie Jones -
Patai Gergely -
Peter Verswyvelen -
Tomáš Janoušek