New core profiling mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

New core profiling mode

Douglas Wilson
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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: New core profiling mode

GHC - devs mailing list

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:[hidden email]] On Behalf Of Douglas Wilson
Sent: 14 November 2017 22:34
To: [hidden email]
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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New core profiling mode

Ben Gamari-3
In reply to this post by Douglas Wilson
Douglas Wilson <[hidden email]> writes:

> 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.
>
Sounds quite reasonable to me.

> 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.

Yes, I think this would be a great idea. I have also wondered in the
past whether it would be worthwhile (optionally?) adding a CSS-like name
SourceNote (e.g. in addition to a SrcSpan, include the name of the
containing binding; for instance "insert.go"). This would make it a bit
easier to understand a backtrace at-a-glance.

> 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!
>
I'm afraid I don't know of any off-hand.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment