Re: Patch to enable GHC runtime system with thr_debug_p options...
On 03/12/12 20:11, Joachim Breitner wrote: Dear Michał, Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb Michał J. Gajda: On 12/02/2012 09:20 PM, Joachim Breitner wrote: I noticed that Ubuntu, as well as Debian and original packages come without some variants of threaded debugging binaries. A recent change added of printing a stack trace with -xc option requires using both -ticky and profiling compile options, which in turn forces program to be compiled in a -debug RTS way. Since stack trace looks like indispensable debugging tool, and convenient parallelization is strength of Haskell, I wonder is there any remaining reason to leave beginners with a cryptic error message when they try to debug a parallel or threaded application, and want to take advantage of stack trace? The resulting ghc-prof package would be increased by less than 1%. Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream --- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.0 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug # Usually want the debug version ifeq $(BootingFromHc) NO I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default. Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? thr_debug is already enabled by default. thr_debug_p is not currently enabled, but only because we very rarely need it, so there wouldn't be any problem with enabling it by default. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Extending GHCi
Hi! I'm currently trying to extend ghc-vis[1], a tool to visualize live data structures in GHCi and GHC compiled programs, similar to GHCi's :print and vacuum. I want to show the type of a subexpression visualized in ghc-vis. As types aren't stored in GHC they have to be reconstructed. For this I need read access to internal GHC(i) information, like the type of data constructors. Type reconstruction is already happening inside GHCi's debugger[2]. Another concern is having a feature for binding a subexpression to a GHCi variable, so that it appears in :show bindings and can be used within the current GHCi session. To me it seems like neither is currently possible from a program running within GHCi. Therefore I just started an extensible GHCi, called eGHCi[3]. So far it should compile on GHC 7.4.2 and 7.6.1, but does nothing else than the regular GHCi. I took the relevant files to compile my own GHCi binary from the corresponding GHC versions, just as ghci-haskeline[4] did before. In order to get type reconstruction and bindings running I'm planning to provide a function runInGhci :: GhciMonad a - IO a which enables programs running in eGHCi to run commands inside the GhciMonad. Another change I'm planning is a function setupHandler :: Event - GhciMonad a - IO () which sets an event handler up to be called whenever the specified event occurs. For now the only event I would need is PostEvaluation, which is evoked after an evaluation occured. I want to use this to update the view of ghc-vis automatically after the user entered a new command on the GHCi command line. My first thought was to define new GHCi commands (like :def) instead of functions, but then only the user could use them, and not the programs running inside of GHCi. Now I'm wondering whether the approaches I have in mind are sensible or if anyone can think of a better way to achieve my goals? Is there a way to extend GHCi without copying some of its source code? Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? Thanks, Dennis Felsing [1] http://felsin9.de/nnis/ghc-vis [2] http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger#TypeReconstruction [3] git clone git://r0q.ath.cx/eghci [4] http://hackage.haskell.org/package/ghci-haskeline ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extending GHCi
Now I'm wondering whether the approaches I have in mind are sensible or if anyone can think of a better way to achieve my goals? Is there a way to extend GHCi without copying some of its source code? Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? I can't really help here. But I'm interested in more powerful ways to extend GHCi, too. I'm mostly interested in things that will speedup development (e.g. Hoogle tab-completion, integration of testing tools). I think once we have a more powerful API to hook things into a running GHCi, people will create useful things that you wouldn't have imagined beforehand. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Simon Marlow marlo...@gmail.com: This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault Thanks for doing all the experiments and putting this page together, it certainly helps us to make a more informed decision. If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), and there are fewer bugs affecting the linker on that platform than OS X. I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I think the benefits outweigh the penalty there, and I can probably investigate to find out where the overhead is coming from. I agree with your opinion. Firstly, correctness is more important than performance. (It's Haskell, after all.) Secondly, the RTS linker is an unnecessary time sink, and developer cycles are precious. Thirdly, when shipping production systems, people can always link statically to get best performance. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Agreed. I'd much rather never again problems in ghci + linking, Its one of the biggest sources of exotic bugs for new haskellers on OS X, for all that i've never quite managed to ever pin down a simple test case to replicate those problems point being: ghci should do normal dynamic linking for reduced engineering complexity + an end to it doesn't work in ghci woes that some folks periodically enncount +1 -Carter On Tue, Dec 4, 2012 at 9:33 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: Simon Marlow marlo...@gmail.com: This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault Thanks for doing all the experiments and putting this page together, it certainly helps us to make a more informed decision. If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), and there are fewer bugs affecting the linker on that platform than OS X. I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I think the benefits outweigh the penalty there, and I can probably investigate to find out where the overhead is coming from. I agree with your opinion. Firstly, correctness is more important than performance. (It's Haskell, after all.) Secondly, the RTS linker is an unnecessary time sink, and developer cycles are precious. Thirdly, when shipping production systems, people can always link statically to get best performance. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
I'm curious how much of the compile twice situation for static and dynamic libraries could actually be shared. Even if it's not likely to be implemented in the next year or two, IMO it would make a big difference if it were feasible to generate both static and dynamic libraries at the same time and share some large percent of the compile time. It seems to me that making GHCi always dynamic but GHC static by default, with the default being for Cabal to build both static and dynamic libraries, is the right answer. After all, static binaries are the right answer for binaries on everything but a few resource-limited mobile platforms anyway. Doubling the compile times is harsh, but I think it's particularly justifiable if it were something that eventually, if it annoys someone enough, they will pound out the code to fix it. Or... how hard would it be to make GHCi fall back to interpreting modules from any packages that don't have dynamic libraries? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Performance Tsar
On 01/12/2012, at 1:42 AM, Simon Peyton-Jones wrote: | While writing a new nofib benchmark today I found myself wondering | whether all the nofib benchmarks are run just before each release, I think we could do with a GHC Performance Tsar. Especially now that Simon has changed jobs, we need to try even harder to broaden the base of people who help with GHC. It would be amazing to have someone who was willing to: * Run nofib benchmarks regularly, and publish the results * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep track of regressions * Investigate regressions to see where they come from; ideally propose fixes. * Extend nofib to contain more representative programs (as Johan is currently doing). That would help keep us on the straight and narrow. I was running a performance regression buildbot for a while a year ago, but gave it up because I didn't have time to chase down the breakages. At the time we were primarily worried about the asymptotic performance of DPH, and fretting about a few percent absolute performance was too much of a distraction. However: if someone wants to pick this up then they may get some use out of the code I wrote for it. The dph-buildbot package in the DPH repository should still compile. This package uses http://hackage.haskell.org/package/buildbox-1.5.3.1 which includes code for running tests, collecting the timings, comparing against a baseline, making pretty reports etc. There is then a second package buildbox-tools which has a command line tool for listing the benchmarks that have deviated from the baseline by a particular amount. Here is an example of a report that dph-buildbot made: http://log.ouroborus.net/limitingfactor/dph/nightly-20110809_000147.txt Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
