Seeing the code on Phab it two weeks sounds great. Do you mind expanding on what tick scopes are. It sounds scarily like something that happens at runtime. :)
On Wed, Aug 13, 2014 at 8:49 PM, Peter Wortmann <[email protected]> wrote: > > > At this point I have a bit more time on my hands again (modulo post-thesis > vacations), but we are basically still in “review hell”. > > I think “just” for perf_events support we’d need the following patches[1]: > 1. Source notes (Core support) > 2. Source notes (CorePrep & Stg support) > 3. Source notes (Cmm support) > 4. Tick scopes > 5. Debug data extraction (NCG support) > 6. Generate .loc/.file directives > > We have a basic “okay” from the Simons up to number 2 (conditional on > better documentation). Number 4 sticks out because Simon Marlow wanted to > have a closer look at it - this is basically about how to maintain source > ticks in a robust fashion on the Cmm level (see also section 5.5 of my > thesis[2]). > > Meanwhile I have ported NCG DWARF generation over to Mac Os, and am > working on reviving LLVM support. My plan was to check that I didn’t > accidentally break Linux support, then push for review again in a week or > so (Phab?). > > Greetings, > Peter > > [1] https://github.com/scpmw/ghc/commits/profiling-import > [2] http://www.personal.leeds.ac.uk/~scpmw/static/thesis.pdf > > On 13 Aug 2014, at 20:01, Johan Tibell <[email protected]<mailto: > [email protected]>> wrote: > > What's the minimal amount of work we need to do to just get the dwarf data > in the codegen by 7.10 (RC late december) so we can start using e.g. linux > perf events to profile Haskell programs? > > > On Wed, Aug 13, 2014 at 7:31 PM, Arash Rouhani <[email protected] > <mailto:[email protected]>> wrote: > Hi Johan! > > I haven't done much (just been lazy) lately, I've tried to benchmark my > results but I don't get any sensible results at all yet. > > Last time Peter said he's working on a more portable way to read dwarf > information that doesn't require Linux. But I'm sure he'll give a more > acurate update than me soon in this mail thread. > > As for stack traces, I don't think there's any big tasks left, but I > summarize what I have in mind: > > * The haskell interface is done and I've iterated on it a bit, so it's > in a decent shape at least. Some parts still need testing. > * I wish I could implement the `forceCaseContinuation` that I've > described in my thesis. If someone is good with code generation (I just > suck at it, it's probably simple) and is willing to assist me a bit, please > say so. :) > * I tried benchmarking, I gave up after not getting any useful results. > * I'm unfortunately totally incapable to help out with dwarf debug data > generation, only Peter knows that part, particularly I never grasped his > theoretical framework of causality in Haskell. > * Peter and I have finally agreed on a simple and sensible way to > implement `catchWithStack` that have all most good properties you would > like. I just need to implement it and test it. I can definitely man up and > implement this. :) > > Here's my master thesis btw [1], it should answer Ömer's question of how > we retrieve a stack from a language you think won't have a stack. :) > > Cheers, > Arash > > [1]: http://arashrouhani.com/papers/master-thesis.pdf > > > > > > On 2014-08-13 17:02, Johan Tibell wrote: > Hi, > > How's the integration of DWARF support coming along? It's probably one of > the most important improvements to the runtime in quite some time since > unlocks *two* important features, namely > > * trustworthy profiling (using e.g. Linux perf events and other > low-overhead, code preserving, sampling profilers), and > * stack traces. > > The former is really important to move our core libraries performance up a > notch. Right now -prof is too invasive for it to be useful when evaluating > the hotspots in these libraries (which are already often heavily tuned). > > The latter one is really important for real life Haskell on the server, > where you can sometimes can get some crash that only happens once a day > under very specific conditions. Knowing where the crash happens is then > *very* useful. > > -- Johan > > > > > _______________________________________________ > ghc-devs mailing list > [email protected]<mailto:[email protected]> > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > [email protected]<mailto:[email protected]> > http://www.haskell.org/mailman/listinfo/ghc-devs > > > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
