- ghc-devs - Haskell.org

Initial state of gc_thread.mut_spin
by Patrick Palka 01 Oct '13

01 Oct '13

Hi everyone, In new_gc_thread(), why is gc_thread.mut_spin initialized to the 'released' state instead of the 'acquired' state (as with gc_spin)? I think this is wrong for two reasons: 1. During the first GC (but not during subsequent GCs), gcWorkerThread() releases mut_spin but mut_spin is not 'acquired' at this point. 2. The initial state of mut_spin is inconsistent with the final state of mut_spin at the end of a GC (it is in the 'acquired' state then). So it seems to me that mut_spin should be initialized to the 'acquired' state, like gc_spin is. Doing so would address these two points. Does this change make sense?

1 0

FW: [Haskell-cafe] The RTSOPTS "-qm" flag's impact on runtime
by Simon Peyton-Jones 01 Oct '13

01 Oct '13

Simon: did you see this? A factor of 50 in runtime seems pretty significant! Simon -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Iustin Pop Sent: 30 September 2013 23:14 To: Haskell Cafe Subject: [Haskell-cafe] The RTSOPTS "-qm" flag's impact on runtime Hi all, I found an interesting case where the rtsopts -qm flag makes a significant difference in runtime (~50x). This is using GHC 7.6.3, llvm 3.4, program compiled with "-threaded -O2 -fllvm" and a couple of language extension. Source is at http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=chameneosre…, on the language shootout benchmarks. Running the code without -N results (on my computer) in around 4 seconds of runtime: $ time ./orig 6000000 … real 0m3.919s user 0m3.903s sys 0m0.010s This is reasonably consistent. Running -N4 (this is an 8-core machine) results in the surprising: $ time ./orig 6000000 +RTS -N4 … real 1m15.154s user 1m38.790s sys 2m7.947s The cores are all used very erratically (continuously changing 5%-20%-40%) and the overall cpu usage is ~27-28%. Note the surprising 2m7s of sys usage, which means the kernel is involved a lot… Note that removing the explicit forkOn and running with -N4 results in somewhat worse performance: real 2m6.548s user 2m13.470s sys 2m3.043s So in that sense the forkOn itself is not at fault. What I have found is that -qm is here a life saver: $ time ./orig 6000000 +RTS -N4 -qm real 0m2.773s user 0m5.610s sys 0m0.123s Adding -qa doesn't make a big difference. To summarise more runs (in terms of cpu used, user+sys): with forkOn: - -N4: 228s - -N4 -qa: 110s - -N4 -qm: 6s - -N4 -qm -qa: 6s without forkOn: - -N4: 253s - -N4 -qa: 252s - -N4 -qm: 5s - -N4 -qm -qa: 5s (Note that "without forkOn" is a bit slower in term of wall-clock, as the "with forkOn" version distributes the work a bit better, even if it uses overall a tiny bit more CPU.) So the question is, what does -qm actually do that it affects this benchmark so much (~50x)? (The docs are not very clear on it) And furthermore, could there be an heuristic inside the runtime such that automatic thread migration is suspended if threads are "over-migrated" (which is what I suppose happens here)? thanks for any explanations, iustin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

I've moved the primitive package to github
by Bryan O'Sullivan 30 Sep '13

30 Sep '13

Roman seems to have gone silent, and primitive being broken with GHC HEAD means that there's a ton of packages we can't build right now. Accordingly, I've imported the old darcs repo into git and published it on github. https://github.com/haskell/primitive Austin, please plan to fix the GHC build to get its copy of primitive from here, once we have it working with HEAD.

5 14

Re: [commit: ghc] master: Fix AMP warnings for explicit Prelude imports (#8004) (b9127f4)
by Patrick Palka 30 Sep '13

30 Sep '13

On Sun, Sep 29, 2013 at 9:10 PM, <git(a)git.haskell.org> wrote: > + isPrelude :: ImportDecl Name -> Bool > + isPrelude = (== "Prelude") . moduleNameString . unLoc . ideclName Can't you just do unLoc (ideclName imp) == pRELUDE_NAME here?

2 1

Re: [commit: packages/base] master: Expose performMinorGC (#8257) (c1491e6)
by Christiaan Baaij 30 Sep '13

30 Sep '13

Shouldn't the last line of the patch be?: > +foreign import ccall "performGC" performMinorGC :: IO () the rts doesn't export a function called "performMinorGC". -- Christiaan On Sep 30, 2013, at 12:24 AM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/c1491e683d3edc31fd20bd3b3021d3a62… > >> --------------------------------------------------------------- > > commit c1491e683d3edc31fd20bd3b3021d3a620aa0184 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Sun Sep 29 09:42:06 2013 -0500 > > Expose performMinorGC (#8257) > > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > > c1491e683d3edc31fd20bd3b3021d3a620aa0184 > System/Mem.hs | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/System/Mem.hs b/System/Mem.hs > index f162a75..2ad75ce 100644 > --- a/System/Mem.hs > +++ b/System/Mem.hs > @@ -14,11 +14,19 @@ > -- > ----------------------------------------------------------------------------- > > -module System.Mem ( > - performGC > - ) where > - > +module System.Mem > + ( performGC > + , performMajorGC > + , performMinorGC > + ) where > import Prelude > > --- | Triggers an immediate garbage collection > -foreign import ccall {-safe-} "performMajorGC" performGC :: IO () > +-- | Triggers an immediate garbage collection. > +performGC :: IO () > +performGC = performMajorGC > + > +-- | Triggers an immediate garbage collection. > +foreign import ccall "performMajorGC" performMajorGC :: IO () > + > +-- | Triggers an immediate minor garbage collection. > +foreign import ccall "performMinorGC" performMinorGC :: IO () > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Re: [GHC] #8173: GHC uses nub
by Kim-Ee Yeoh 29 Sep '13

29 Sep '13

On Sun, Sep 29, 2013 at 2:56 PM, GHC <ghc-devs(a)haskell.org> wrote: > According to the results, sadly the 5% performance gain in compile time > was complete bogus. Sorry. =( > Does anyone have any insight into why? How can a future benchmark avoid such bogusity? The only -- I might add, implicit -- rec is to run things twice. -- Kim-Ee

1 0

Make compiler_stage2_dll0_MODULES multi-line
by Dr. ERDI Gergo 29 Sep '13

29 Sep '13

Hi, Currently, compiler_stage2_dll0_MODULES is defined on a single line in compiler/ghc.mk. This means at least on git, any two changes to it on separate branches results in a merge conflict (I don't know if darcs handles same-line changes better). Is there any reason we don't change it to multiple lines (with escaped trailing newlines) so that git can merge changes? Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' "Last week, I left my 2 XP CD's on my dashboard in plain view. Someone broke into my car and left 2 more." -- /.

1 0

Re: [GHC] #8371: ghci byte compiler + FFI crashes when used with embedded R
by Dominick Samperi 28 Sep '13

28 Sep '13

Thanks! Turning off R's stack limit checks will not work. I tried this and this leads to a segfault. Fortunately, your experiments led me to a work-around: simply use the -fno-ghci-sandbox flag. R is not thread-safe, and this flag tells ghci to run computations in the main thread instead of forking. On Sat, Sep 28, 2013 at 1:29 AM, GHC <ghc-devs(a)haskell.org> wrote: > #8371: ghci byte compiler + FFI crashes when used with embedded R > -------------------------------+---------------------------------- > Reporter: dsamperi | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: GHCi | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Linux | Architecture: x86_64 (amd64) > Type of failure: GHCi crash | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------+---------------------------------- > > Comment (by rwbarton): > > I can reproduce this without ghci, by putting a forkIO around the body of > main (and adding a threadDelay in the main thread). > > It seems to just be an interaction between R's method for determining the > base address of the stack and the way pthread allocates stacks for new > threads. Try this C example program `pt.c`. > > {{{ > #include <stdio.h> > #include <unistd.h> > #include <pthread.h> > > int Rf_initEmbeddedR(int argc, char **argv); > > void *foo(void *blah) > { > char *args[] = {"pt", "--gui=none", "--silent", "--vanilla"}; > int r; > setenv("R_HOME", "/usr/lib/R", 1); > r = Rf_initEmbeddedR(sizeof(args)/sizeof(args[0]), args); > printf("r = %d\n", r); > } > > int main(void) > { > pthread_t tid; > pthread_create(&tid, NULL, foo, NULL); > while (1) > sleep(1); > return 0; > } > }}} > > {{{ > rwbarton@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR > rwbarton@adjunction:/tmp$ ./pt > Error: C stack usage is too close to the limit > Error: C stack usage is too close to the limit > r = 1 > }}} > > It would probably be best to just disable R's stack limit checks, if > possible. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8371#comment:6> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 3

Re: Executables using GHC API require dynamic linking in GHC 7.7
by Carter Tazio Schonwald 28 Sep '13

28 Sep '13

please report this issue on ghc trac and all the relevant information there in. That is the best way to promptly get folks to see it -Carter On Saturday, September 28, 2013 at 2:55 AM, Christiaan Baaij wrote: > Yes, I have both the static libs and the dynamic libs. > So for every library I have both the 'libHS<PACKAGE-VERSION>.a' and the 'libHS<PACKAGE-VERSION-ghc<GHCVERSION>.dylib' files. > And for all the compiled modules I have both the '.hi' and '.dyn_hi' files. > > So to be clear: > - I have both the static and dynamic versions of all libraries/packages > > - I built a statically-linked executable by setting 'executable-dynamic' in my '.cabal/config' file explicitly to 'False' > - otool -L <EXE> confirms that the executable is indeed statically linked > - Running the statically-linked executable that uses the GHC API, where the GHC API does dynamic linking (e.g. TH) => Segfault > > - I built a dynamically-linked executable setting 'executable-dynamic' in my '.cabal/config' file explicitly to 'True' > - otool -L <EXE> confirms that the executable is indeed dynamically linked. > - Running the dynamically-linked binary that uses the GHC API, where the GHC API does dynamic linking => No problem, behaves normally > > So the problem is not that TH is not working/segfaulting, the problem is that I get segfaults when a statically linked executable does dynamic linking. > At least on OS X. > > -- Christiaan > > > > On Sat, Sep 28, 2013 at 4:23 AM, Carter Schonwald <carter.schonwald(a)gmail.com (mailto:carter.schonwald@gmail.com)> wrote: > > Hey Christian, did you build ghc and libs I both Dylib and static ways? TH uses ghci, and ghci on OS X and a few other platforms uses the system dylinker, so it may be that you've only built certain libs the static way, but ghci requires the dynamic way as of 7.7 > > > > Please let me know if that helps. > > > > > > > > > > On Friday, September 27, 2013, Christiaan Baaij wrote: > > > Dear all, > > > > > > It seems that executables that use the GHC API require to be dynamically linked on GHC 7.7. > > > At least in the case that an GHC API function has to perform linking. > > > Statically linked executable SEGFAULT when a GHC API function tries to do linking. > > > > > > I build 'haddock' from source by doing a 'cabal install' in the 'utils/haddock' directory of my ghc build tree. > > > Here is the output of my statically linked haddock when I run it on one of my libraries: > > > Haddock coverage: > > > Warning: main:CLaSH.Util: Could not find documentation for exported module: X > > > Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses > > > 95% ( 18 / 19) in 'CLaSH.Util' > > > 100% ( 8 / 8) in 'CLaSH.Core.TyCon' > > > 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' > > > 100% ( 5 / 5) in 'CLaSH.Core.DataCon' > > > 100% ( 3 / 3) in 'CLaSH.Core.Literal' > > > 100% ( 5 / 5) in 'CLaSH.Core.Var' > > > Bus error: 10 <-- SEGFAULT > > > > > > Here is the output of my dynamically linked haddock when I run it on one of my libraries: > > > Haddock coverage: > > > Warning: main:CLaSH.Util: Could not find documentation for exported module: X > > > Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses > > > 95% ( 18 / 19) in 'CLaSH.Util' > > > 100% ( 8 / 8) in 'CLaSH.Core.TyCon' > > > 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' > > > 100% ( 5 / 5) in 'CLaSH.Core.DataCon' > > > 100% ( 3 / 3) in 'CLaSH.Core.Literal' > > > 100% ( 5 / 5) in 'CLaSH.Core.Var' > > > 100% ( 5 / 5) in 'CLaSH.Core.Term' > > > 100% ( 8 / 8) in 'CLaSH.Core.Subst' > > > 100% ( 24 / 24) in 'CLaSH.Core.Type' > > > <… lots of warnings about missing link destination … > > > > ~/Documents/devel/clash/src (master *)$ > > > > > > I believe that the use of TH in the CLaSH.Core.Var file triggers the segfault in the statically linked version. > > > I'm trying to create a smaller test case than running haddock on my library, but have been unsuccessful so far. > > > That is why I haven't posted a bug report on the bug tracker yet. > > > If somebody thinks I should, then please say so :-) > > > > > > My platform is: > > > OS: OS X 10.8.5 > > > XCode: X-Code CL-tools 4.6.2 > > > GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546) > > > Build.mk: > > > SRC_HC_OPTS = -O -H64m > > > GhcStage1HcOpts = -O -fasm > > > GhcStage2HcOpts = -O2 -fasm > > > GhcHcOpts = -Rghc-timing > > > GhcLibHcOpts = -O2 > > > HADDOCK_DOCS = NO > > > > > > I hope somebody can test this on linux with dynamic linking. > > > As this bug affects haddock, I think it is quite important that somebody with more knowledge of dynamic linking looks into this. > > > > > > Regards, > > > > > > Christiaan > > > > > > > > > > > > _______________________________________________ > > > Glasgow-haskell-users mailing list > > > Glasgow-haskell-users(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1

Re: [GHC] #8173: GHC uses nub
by Kim-Ee Yeoh 27 Sep '13

27 Sep '13

On Fri, Sep 27, 2013 at 8:14 PM, GHC <ghc-devs(a)haskell.org> wrote: > A 5% improvement in compile time is remarkable, if it's true. Great! But > I'm always worried about the noise in compile times measured in seconds. > Does anyone else think the noise in runtimes is alarming considering that the following is the fib-analysis of /binary-identical/ programs? > Min -0.1% -0.0% -25.4% -32.2% -1.3% > Max +0.1% +0.0% +19.0% +22.2% +10.0% Shouldn't we find an explanation for this before believing the compile time numbers? What would cause these wide swings on the benchmarking machine? p.s. For the record: Should do more rigorous statistical testing instead of naive percentages, yes? -- Kim-Ee

2 2