January 2015 - ghc-devs

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 19 Jan '15

19 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 19 Jan '15

19 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

GHC Weekly News - 2015/01/19
by Austin Seipp 19 Jan '15

19 Jan '15

Hi *, It's time for some more GHC news! The GHC 7.10 release is closing in, which has been the primary place we're focusing our attention. In particular, we're hoping RC2 will be Real Soon Now. Some notes from the past GHC HQ meetings this week: - GHC 7.10 is still rolling along smoothly, and it's expected that RC2 will be cut this Friday, January 23rd. Austin sent out an email about this to `ghc-devs`, so we can hopefully get all the necessary fixes in. - Our status page for GHC 7.10 lists all the current bullet points and tickets we hope to address: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 - Currently, GHC HQ isn't planning on focusing many cycles on any GHC 7.10 tickets that aren't '''highest priority'''. We're otherwise going to fix things as we see fit, at our leisure - but a highest priority bug is a showstopper for us. This means if you have something you consider a showstopper for the next release, you should bump the priority on the ticket and yell at us! - We otherwise think everything looks pretty smooth for 7.10.1 RC2 - our libraries are updated, and most of the currently queued patches (with a few minor exceptions) are done and merged. Some notes from the mailing list include: - Austin announced the GHC 7.10.1 RC2 cutoff, which will be on '''Friday the 23rd'''. https://www.haskell.org/pipermail/ghc-devs/2015-January/008026.html - Austin has alerted everyone that soon, Phabricator will run all builds with `./validate --slow`, which will increase the time taken for most builds, but will catch a wider array of bugs in commits and submitted patches - there are many cases the default `./validate` script still doesn't catch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008030.html - Johan Tibell asked about some clarifications for the `HsBang` datatype inside GHC. In response, Simon came back with some clarifications, comments, and refactorings, which greatly helped Johan. ttps://www.haskell.org/pipermail/ghc-devs/2015-January/007905.html - Jens Petersen announced a Fedora Copr repo for GHC 7.8.4: https://www.haskell.org/pipermail/ghc-devs/2015-January/007978.html - Richard Eisenberg had a question about the vectoriser: can we disable it? DPH seems to have stagnated a bit recently, bringing into question the necessity of keeping it on. There hasn't been anything done yet, but it looks like the build will get lighter, with a few more modules soon: https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html - Ben Gamari has an interesting email about trying to optimize `bytestring`, but he hit a snag with small literals being floated out causing very poor assembly results. Hopefully Simon (or anyone!) can follow up soon with some help: https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html - Konrad Gądek asks: why does it seem the GHC API is slower at calling native code than a compiled executable is? Konrad asks as this issue of performance is particularly important for their work. https://www.haskell.org/pipermail/ghc-devs/2015-January/007990.html - Jan Stolarek has a simple question: what English spelling do we aim for in GHC? It seems that while GHC supports an assortment of British and American english syntactic literals (e.g. `SPECIALIZE` and `SPECIALISE`), the compiler sports an assortment of British/American identifiers on its own! https://www.haskell.org/pipermail/ghc-devs/2015-January/007999.html - Luis Gabriel has a question about modifying the compiler's profiling output, particularly adding a new CCS (Cost Centre Structure) field. He's hit a bug it seems, and is looking for help with his patch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008015.html Closed tickets the past few weeks include: #9966, #9904, #9969, #9972, #9934, #9967, #9875, #9900, #9973, #9890, #5821, #9984, #9997, #9998, #9971, #10000, #10002, #9243, #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, and #9836. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RC2 Cutoff at the end of this week
by Austin Seipp 19 Jan '15

19 Jan '15

Hi *, I just wanted to let everyone know we plan on releasing RC2 at the end of this week, on Friday. We're hoping this will be the final RC before we do the actual release, so if you want to get your fixes in for users to test - now is the time! Specifically, here are a few things: - Edward, can you please merge D614 and D603? I think we should pull these into the 7.10 branch. - Erik, can you follow up on D599? It would be nice to have this in early. - Alan, I'll get D538 & D620 into 7.10 today, it just requires a more delicate merge I think (there are probably some parent commits to pick up). - Peter W, I'll get to #9961 later today, but if you don't mind, please post future things to Phabricator - it makes it much easier for a proper review (although your fix looks good still!) - Peter T, D622 looks OK to go into 7.10 and HEAD to me, so I can merge it. I'll follow up with a curated list of Trac tickets for the final release (in another email). Let me know if you have questions. Thanks. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2