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 <mle+hs@mega-nerd.com> 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 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 <mle+hs@mega-nerd.com> 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 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 <qdunkan@gmail.com> wrote:
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 <mle+hs@mega-nerd.com <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 <carter.schonwald@gmail.com
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