RFC: Removing the `-hb` profiling option

Hi all, After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019 This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it. Thoughts? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

I think that biographical profiling is quite nice! I wouldn't say that it
is *more* useful than other modes of profiling, but it is certainly
complementary, and helps give you an idea of what's going on.
So I'd very much vote for fixing it rather than removing it.
-Iavor
On Fri, May 6, 2016 at 2:04 AM, Erik de Castro Lopo
Hi all,
After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it.
Thoughts?
Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

I've used this a lot when looking for leaks. Especially combined with
other things like -hbdrag -hc, so I'd be sad to see it go. Without
it, how do you find lag and drag?
On the other hand, the entire profiling system has been hard to use
because of crashes (perhaps due to that thread-unsafety thing), but
also because of lack of documentation, the fact that SCCs can
drastically change the performance of the things they are trying to
measure, and probably just personal incompetence. But that's not
really directly relevant to -hb, except to say I'd rather fix it than
delete it.
On Fri, May 6, 2016 at 2:04 AM, Erik de Castro Lopo
Hi all,
After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it.
Thoughts?
Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

What about disallowing -hb on threaded builds? That does just sort of punt
it a little bit, it a not quite satisfactory way perhaps
On Friday, May 6, 2016, Evan Laforge
I've used this a lot when looking for leaks. Especially combined with other things like -hbdrag -hc, so I'd be sad to see it go. Without it, how do you find lag and drag?
On the other hand, the entire profiling system has been hard to use because of crashes (perhaps due to that thread-unsafety thing), but also because of lack of documentation, the fact that SCCs can drastically change the performance of the things they are trying to measure, and probably just personal incompetence. But that's not really directly relevant to -hb, except to say I'd rather fix it than delete it.
On Fri, May 6, 2016 at 2:04 AM, Erik de Castro Lopo
javascript:;> wrote: Hi all,
After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it.
Thoughts?
Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

On Fri, May 6, 2016 at 1:39 PM, Carter Schonwald wrote: What about disallowing -hb on threaded builds? That does just sort of punt
it a little bit, it a not quite satisfactory way perhaps But the non-threaded runtime isn't really a first class citizen, is it?
Consider
http://hackage.haskell.org/package/base-4.8.2.0/docs/GHC-Event.html#v:getSys...
which is Nothing on the non-threaded runtime. So you can't really just "run
it unthreaded" to profile any program using that style of implementation.
Even when you don't touch it directly, the program runs very differently.
As for hb, I'd probably cry least about losing -hb but they all serve
different, and in my opinion, important needs.

On 05/06/2016 11:04 AM, Erik de Castro Lopo wrote:
Hi all,
After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it.
I can't say I've ever used the option, but just to inform discussion... Do you have any guesstimate[1] of how much effort it would take to fix vs. just removing? Unless there's a reasonably clear idea of how much effort there's going to be in it[2], I usually err on the side of removal *unless* a really good case can be made. Regards, [1] As ballpark as you like. Even a ratio would work, I think. [2] Which tends to not be the case for threading-related issues.
participants (6)
-
Bardur Arantsson
-
Carter Schonwald
-
davean
-
Erik de Castro Lopo
-
Evan Laforge
-
Iavor Diatchki