New core profiling mode

[Simon Peyton Jones]

Doug

Good stuff.

Do you know about ticky-ticky profiling?   It is /guaranteed/ not to affect optimisation.  Moreover you can mix modules compiled with and without profiling.  But it’s very low level.

I had not thought of doing /cost-centre/ profiling after optimisation.  That’s an interesting thought.  You’d still have to compile the entire program with profiling (because runtime representations change).  But you’d get the call-stack information etc that cost centres give you, but with a guarantee that optimisation was unaffected.  It’s a sort of middle ground.

Is the end of corePrepPgm the right place to insert the cost-centres? I chose it
because it can't affect any core optimizations if it's last, but perhaps it
could be earlier, or perhaps it needs to act on Stg?

I’d be inclined to do it on STG, just before codegen.  Because it really is a codgen tactic “compile this with cost centres please”.

I need to strip (probably only non-user) ticks out of unfoldings before they are
substituted into a module that uses -fprof-core.

Why?  If you are only adding these cost centres after CorePrep, or in STG, they will never show up in unfoldings anyway.

Simon


From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Douglas Wilson
Sent: 14 November 2017 22:34
To: ghc-devs at haskell.org
Subject: New core profiling mode

Hi ghc-devs,

I've been working on a new mode of adding cost-centres to programs and I'd
like to ask some questions and solicit some feedback. The code is here [fn:1],
it works, provided one enables -fprof-core on all modules.

I've recently been trying to pick some low hanging fruit from ghc compilation
performance. A common frustration was in the difference between profiled and
non-profiled builds. Often I thought had I found a problem in the profiled
build, only to find it was optimized away in the non-profiled build. Several
times an issue was tail-calls not happening in profiled builds.

To solve this problem I've been working on a new way of inserting cost-centres:
adding them to core after simplification (currently at the end of corePrepPgm)
rather than adding them to HsSyn before simplification. This makes it harder to
map cost-centres into source code (You have to -ddump-prep currently), but in
exchange you are profiling the same core program as the non-profilied build.

I intend to investigate whether I can use SourceNotes to create SrcSpans for the
generated cost-centres to somewhat alleviate the need to inspect dumped core.

There are several new flags:

-fprof-core: Enables the aforementioned mode. This is mutually exclusive with
-fprof-auto etc.

-fprof-core-drop-ticks: Non-user ticks are dropped from unfoldings(though I
  don't know how to do this yet).

-fprof-core-tick-binds: ticks are inserted around the RHS of bindings (except
  top-level unlifted bindings).

-fprof-core-tick-cases: ticks are inserted around the scrutinees of cases.

-fprof-core-tick-alts: ticks are inserted around Alt expressions (unless there
  is only one).

Some questions:

I need to strip (probably only non-user) ticks out of unfoldings before they are
substituted into a module that uses -fprof-core. Where is the right place to do
this? I need inlining to proceed exactly as if the ticks were not present,
however I don't want to strip ticks when the unfoldings are created as other
modules may still need them.

Is the end of corePrepPgm the right place to insert the cost-centres? I chose it
because it can't affect any core optimizations if it's last, but perhaps it
could be earlier, or perhaps it needs to act on Stg?

Do you have any examples of programs for which existing profiling tools are
inadequate due to how cost-centres affect simplification? There is an example in
#12893 but something self-contained would be great!

Regards,
Doug Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171115/4e9e2257/attachment-0001.html>