- ghc-devs - Haskell.org

Strange failures in directory/
by Simon Peyton Jones 23 Jan '15

23 Jan '15

I'm getting these validate failures from "sh validate -fast": Unexpected failures: ../../libraries/directory/tests getHomeDirectory001 [exit code non-0] (normal) .. and about 20 more similar complaints ... The failure report is this: Compile failed (status 256) errors were: [1 of 1] Compiling Main ( getHomeDirectory001.hs, getHomeDirectory001.o ) *** unexpected failure for getHomeDirectory001(normal) BUT if I "cd libraries/directory/tests", and say "make TEST=getDirContents001", I get no failures. Here is a clue. If I "cd testsuite/tests" and say "make TEST=getDirContents001", I get this: =====> getHomeDirectory001(normal) 4288 of 4405 [0, 0, 13] cd ../../libraries/directory/tests && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o getHomeDirectory001 getHomeDirectory001.hs >getHomeDirectory001.comp.stderr 2>&1 cd ../../libraries/directory/tests && ./getHomeDirectory001 </dev/null >getHomeDirectory001.run.stdout 2>getHomeDirectory001.run.stderr =====> getHomeDirectory001(normal) 4301 of 4405 [0, 0, 13] cd ../../libraries/directory/tests && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o getHomeDirectory001 getHomeDirectory001.hs >getHomeDirectory001.comp.stderr 2>&1 cd ../../libraries/directory/tests && ./getHomeDirectory001 </dev/null >getHomeDirectory001.run.stdout 2>getHomeDirectory001.run.stderr Note that it gets compiled TWICE. This is likely to cause problems when multi-threading. Anyone have any ideas? Simon

2 1

Re: Proposal for removing transformers dependency
by Johannes Waldmann 23 Jan '15

23 Jan '15

> ... a proposal for removing transformers dependency from ghc library. +1 - J.W. (I subscribed to this list just to send this one message ...)

1 0

GHC HEAD failure [was: Re: [commit: ghc] master: Update Haddock submodule (34d68d8)]
by Karel Gardas 23 Jan '15

23 Jan '15

Hello, last night build on i386-freebsd, i386/amd64-solaris and smartos-x86 failed with problem on configuring haddock: "inplace/bin/ghc-cabal" check utils/haddock 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. "inplace/bin/ghc-cabal" configure utils/haddock dist "" --with-ghc="/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-stage1" --with-ghc-pkg="/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-pkg" --flag in-ghc-tree --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -U__i686 -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -U__i686 -fno-stack-protector " --configure-option=--with-gmp-includes="/usr/include/gmp" --configure-option=--with-gmp-libraries="/usr/lib" --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/xpg4/bin/ar" --with-alex="/buildbot//bin/alex" --with-happy="/buildbot//bin/happy" Configuring haddock-2.16.0... ghc-cabal: At least the following dependencies are missing: ghc >=7.9 && <7.11 gmake[1]: *** [utils/haddock/dist/package-data.mk] Error 1 gmake: *** [all] Error 2 At least i386-solaris is using ghc 7.8.2 as a bootsrap ghc and amd64-solaris is using ghc 7.10.0.20141222 as a bootstrap ghc. This is IIRC 7.10 rc1. I've thought the general policy is to keep GHC buildable by two last release generation in the past and if this policy still applies then haddock is probably a culprit here. Perhaps it was done by the commit below which is the reason I address you directly Mateusz. If not, and the failure is caused by something else, then please excuse me for this email. Thanks! Karel On 01/23/15 01:12 AM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/34d68d8e83676c5010e9bc5d4619f2487… > >> --------------------------------------------------------------- > > commit 34d68d8e83676c5010e9bc5d4619f24879f222af > Author: Mateusz Kowalczyk<fuuzetsu(a)fuuzetsu.co.uk> > Date: Fri Jan 23 00:14:00 2015 +0000 > > Update Haddock submodule > > >> --------------------------------------------------------------- > > 34d68d8e83676c5010e9bc5d4619f24879f222af > utils/haddock | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/utils/haddock b/utils/haddock > index d61bbc7..bf77580 160000 > --- a/utils/haddock > +++ b/utils/haddock > @@ -1 +1 @@ > -Subproject commit d61bbc75890e4eb0ad508b9c2a27b91f691213e6 > +Subproject commit bf77580eb40fa960b701296ac828372d127a43dd > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Proposal for removing transformers dependency
by Alexander V Vershilov 22 Jan '15

22 Jan '15

Hello. I'm coming with a proposal for removing transformers dependency from ghc library. The reason for this proposal that it's not possible to build consistent environment where a modern libraries (that depend on a newer transformers or mtl-2.2) and libraries that use ghc API are used together. And often people are tend to use version that is bundled with ghc, even if newer are available. As transformers usage are quite limited in ghc, and it's really relevant in ghc-bin, it's possible to duplicate the code, and provide required fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers. I have prepared a proof of concept [1], however it doesn't look very clean and it's quite possible that will require some generalization, for example introduction of the ghc-transformers-instances package that will have all required instances. Should I continue doing this? Are there any things to consider and fix? [1] https://github.com/qnikst/ghc/compare/wip/remove-tf -- Alexander

8 15

RE: [commit: ghc] master: 32-bit performance wibbles (387f1d1)
by Simon Peyton Jones 22 Jan '15

22 Jan '15

BOTHER! I have no idea how my commit, which was meant to change two all.T files, also ended up adding libraries/haskell98. I'll revert and re-commit. I also inadvertently did 'git pull' rather than 'git pull --rebase' so there's a merge node too. But I don't know how to undo that, and probably no harm done. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 22 January 2015 09:41 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: 32-bit performance wibbles (387f1d1) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/387f1d1ec334788c3e891e9304d4 | 27bc804998f4/ghc | | >--------------------------------------------------------------- | | commit 387f1d1ec334788c3e891e9304d427bc804998f4 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Tue Jan 20 17:31:13 2015 +0000 | | 32-bit performance wibbles | | Less for GHC, more for Haddock | | | >--------------------------------------------------------------- | | 387f1d1ec334788c3e891e9304d427bc804998f4 | libraries/{integer-simple => haskell98}/.gitignore | 0 | libraries/haskell98/Array.hs | 15 + | libraries/haskell98/Bits.hs | 8 + | libraries/haskell98/CError.hs | 8 + | libraries/haskell98/CForeign.hs | 7 + | libraries/haskell98/CPUTime.hs | 9 + | libraries/haskell98/CString.hs | 7 + | libraries/haskell98/CTypes.hs | 7 + | libraries/haskell98/Char.hs | 18 + | libraries/haskell98/Complex.hs | 11 + | libraries/haskell98/Directory.hs | 46 +++ | libraries/haskell98/ForeignPtr.hs | 7 + | libraries/haskell98/IO.hs | 74 ++++ | libraries/haskell98/Int.hs | 7 + | libraries/haskell98/Ix.hs | 10 + | libraries/haskell98/LICENSE | 28 ++ | libraries/haskell98/List.hs | 34 ++ | libraries/haskell98/Locale.hs | 17 + | libraries/haskell98/MarshalAlloc.hs | 7 + | libraries/haskell98/MarshalArray.hs | 7 + | libraries/haskell98/MarshalError.hs | 22 ++ | libraries/haskell98/MarshalUtils.hs | 7 + | libraries/haskell98/Maybe.hs | 16 + | libraries/haskell98/Monad.hs | 19 + | libraries/haskell98/Numeric.hs | 48 +++ | libraries/haskell98/Prelude.hs | 196 ++++++++++ | libraries/haskell98/Ptr.hs | 7 + | libraries/haskell98/Random.hs | 407 | +++++++++++++++++++++ | libraries/haskell98/Ratio.hs | 10 + | libraries/{integer-gmp => haskell98}/Setup.hs | 0 | libraries/haskell98/StablePtr.hs | 7 + | libraries/haskell98/Storable.hs | 7 + | libraries/haskell98/System.hs | 15 + | libraries/haskell98/Time.hs | 22 ++ | libraries/haskell98/Word.hs | 7 + | libraries/haskell98/changelog.md | 15 + | libraries/haskell98/haskell98.cabal | 86 +++++ | libraries/haskell98/prologue.txt | 9 + | testsuite/tests/perf/compiler/all.T | 7 +- | testsuite/tests/perf/haddock/all.T | 13 +- | 40 files changed, 1240 insertions(+), 7 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 387f1d1ec334788c3e891e9304d427bc804998f4 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: Request for assistance from Haskell-oriented startup: GHCi performance
by Simon Peyton Jones 20 Jan '15

20 Jan '15

Konrad That does sound frustrating. I think your first port of call should be Manuel Chakravarty, the author of accelerate. The example you give in your stackoverflow post<http://stackoverflow.com/questions/27541609/difference-in-performance-of-co…> can only be some weird systems thing. After all, you are executing precisely the same code (namely compiled Accelerate code); it’s just that in one case it’s dynamically linked and excecuted from GHCi and in the other it’s linked and executed by the shell. I have no clue what could cause that. I wonder if you are using a GPU and whether that might somehow behave differently. Could it be the difference between static linking and dynamic linking (which could plausibly account for some startup delay)? Is it a fixed overhead (eg takes 100ms extra) or does it run a factor of two slower (increase the size of your test case to see)? I’d be happy to have a Skype call with you, but I am rather unlikely to know anything helpful because it doesn’t sound like a core Haskell issue at all. You are executing the very same machine instructions! The overheads of the GHC API to compile and run the expression “main” are pretty small. I’m copying ghc-devs in case anyone else has any ideas. Simon From: Konrad Gądek [mailto:kgadek@gmail.com] Sent: 14 January 2015 13:59 To: Simon Peyton Jones Cc: Piotr Młodawski; kgadek(a)flowbox.io Subject: Request for assistance from Haskell-oriented startup: GHCi performance Dear Mr Jones, My name is Konrad Gądek and I'm one of the programmers at Flowbox ( http://flowbox.io ), a startup that is to bring a fresh view on image composition in movie industry. We proudly use Haskell in nearly all of our development. I believe you may remember our CEO, Wojciech Daniło, from discussions like in this thread: https://phabricator.haskell.org/D69 . What can be interesting for you is that to achieve our goals as a company, we started developing a new programming language - Luna. Long story short, we believe that Luna could be as beneficial for the Haskell community as Elixir is for Erlang. However, we found some major performance problems with the code that are as critical for us as they are cryptic. We have found difficulties in pinpointing the actual issue, not to mention solving it. We're getting a bit desperate about that, nobody so far has been able to help us, and so we would like to ask you for help. We would be really really grateful if you could take a look, maybe your fresh ideas could shed some light on the issue. Details are attached below. Is there any chance we could arrange eg. a Skype call so we could further discuss the matter? Thank you in advance! Background Currently Luna is trans-compiled to Haskell and then compiled to bytecode by GHC. Furthermore, we use ghci to evaluate expressions (the flow graph) interactively. We use accelerate library to perform high-performance computations with the help of graphic cards. The problem Executing some of the functions from libraries compiled with -O2 (especially from accelerate) is much slower than calling it from compiled executable (see http://stackoverflow.com/questions/27541609/difference-in-performance-of-co… and https://github.com/AccelerateHS/accelerate/issues/227) Maybe there is some other way to interactively evaluate Haskell code, which is more lightweight/more customizable ie. would not require all ghc-api features which are probably slowing down the whole process? Is it possible to just use ghc linker and make function calls simpler and more time efficient? Details We feed ghci with statements (using ghc-api) and declarations (using runStmt and runDecls). We can also change imports and language extensions before each call. The overall process is as follows: * on init: · * set ghcpath to one with our custom installation of ghc with preinstalled graphic libraries * set imports to our libraries * enable/disable appropriate language extensions * for each run: · * generate haskell code (including datatype declarations, using lenses and TemplateHaskell) and load it to ghci using runDecls * for each expression: o * run statements that use freshly generated code * bind (lazy) results to variables * evaluate values from bound variables, and get it from GhcMonad to runtime of our interpreter (see http://hackage.haskell.org/package/hint–0.4.2.1/docs/Language-Haskell-Inter…<http://hackage.haskell.org/package/hint%E2%80%930.4.2.1/docs/Language-Haske…>) This behaviour was observed when using GHC 7.8.3 (with D69 patch) on Fedora 20 (x86-64), Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Tried so far 1. Specializing nearly everything in accelerate library, specializing calls to accelearate methods (no speedup). 2. Load precompiled, optimised code to ghci (no speedup). 3. Truth to be told, we have no idea what to try next. -- Konrad Gądek typechecker team-leader in Flowbox

2 1

Re: [commit: ghc] master: comments only (9894f6a)
by Gabor Greif 20 Jan '15

20 Jan '15

Hi Simon, JFTR, you seem to be after the trailing zeros in the code you commented. If the bitmap is *really* that sparse then it might be profitable to rewrite it in terms of __builtin_ctz (when present). Some CPUs even have instructions for this. http://hardwarebug.org/2010/01/14/beware-the-builtins/ Possibly one could even switch to checking *leading* zeros by reformulating the algorithm and eliminate a few more instructions. http://www.hackersdelight.org/ might be another source for inspiration. Cheers, Gabor On 1/20/15, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/9894f6a5b4883ea87fd5f280a2eb4a8ab… > >>--------------------------------------------------------------- > > commit 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Wed Jan 14 08:45:07 2015 +0000 > > comments only > > >>--------------------------------------------------------------- > > 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b > rts/sm/Scav.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/rts/sm/Scav.c b/rts/sm/Scav.c > index 2ecb23b..781840c 100644 > --- a/rts/sm/Scav.c > +++ b/rts/sm/Scav.c > @@ -285,6 +285,8 @@ scavenge_large_srt_bitmap( StgLargeSRT *large_srt ) > > for (i = 0; i < size / BITS_IN(W_); i++) { > bitmap = large_srt->l.bitmap[i]; > + // skip zero words: bitmaps can be very sparse, and this helps > + // performance a lot in some cases. > if (bitmap != 0) { > for (j = 0; j < BITS_IN(W_); j++) { > if ((bitmap & 1) != 0) { > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 3

Playing with the profiler
by Luís Gabriel 20 Jan '15

20 Jan '15

Hi there, I'm doing some experiments with the GHC time profiler and I need to add a new field to the Cost Centre structures. I managed to add the field in the *CCS.h* header as well as in *codeGen/StgCmmProf.hs* but for some reason the program is crashing during garbage collection. As I have no experience with the GHC internals, I'm having trouble to find the problem. It would be very nice if someone could give me some clue to find this bug. The patch on GHC as well as the test sample and stack traces can be found here: https://gist.github.com/luisgabriel/39d51cf4d661c7e62e22 Thanks, Luís Gabriel

2 2

Re: vectorisation code?
by David Feuer 20 Jan '15

20 Jan '15

Richard Eisenberg wrote: > Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out (not just with CPP, for better syntax highlighting). Include a Note explaining what `vectorise` does and why it's not there at the moment. However, move the actual vectorisation code somewhere else in the repo, outside of the source directories (`utils`? a new `attic` directory?). I don't know too much about git, but I would think we'd want to remove it from master and add a commit putting it back in to a dph branch.

1 0

RE: cminusminus.org does not have a link to the spec
by Simon Peyton Jones 20 Jan '15

20 Jan '15

Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit "import" statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei

4 6