October 2013 - ghc-devs

Re: Why do we put GMP allocations on GHC heaps?
by Austin Seipp 24 Oct '13

24 Oct '13

On Wed, Oct 23, 2013 at 12:03 PM, Gergely Risko <gergely(a)risko.hu> wrote: > On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <austin(a)well-typed.com> writes: > >> $ ghc foo.hs >> $ ghc -integer-type=gmp foo.hs >> $ ghc -integer-type=openssl foo.hs >> $ ghc -integer-type=simple foo.hs > > Well, I didn't think of this. This would indeed be very cool, > unfortunately it's quite hard if I understood you correctly. > >> As an example, libtomcrypt is damn fast, BSD3 licensed, very small, >> and well-respected. Why don't we: >> >> 1) Take libtomcrypt, modify the symbol names to be private to GHC >> (e.g. prefix everything with `ghc_integer_`) - this means the symbol >> names will be internal to GHC, so this also doesn't affect relinks >> against other copies of libtomcrypt (many projects include their own >> copy.) It is so small it basically comes under our control completely. >> >> 2) We can then offer people a integer-tomcrypt which does not have >> compatibility issues, and does not cause as much pain as the >> integration of widely deployed libraries like GMP/OpenSSL, which are >> in various use by many Haskell packages already. >> >> This should give us the flexibility of integer-simple without >> compromising so much on the efficiency aspect. >> >> This is also a very half-baked idea, but just a suggestion. I'd love a >> more modular solution to Integer as well, as I know many other people >> would. > > Just to be sure I understand the idea: do you mean linking this > ghc_integer_ prefix libtommath statically into ghc and every resulting > haskell binary, right? It makes no sense to link dynamically if the > user can't replace it with a standard libtommath anyways because of the > prefix. Basically, yes. Well, it can also be in a dynamic shared library too (for example, a Haskell library libhsinteger-tommath.so or whatever) - but it's more important for static linking, where we do not want conflicts with other instances. In particular, tommath is used quite a bit and it's small enough people tend to just include copies of it wholesale in their project. So linking -static could actually be a problem in some cases due to this (bringing us back where we started.) The upgrading is not so much a problem, because for dynamically linked Haskell exes, you're probably unlikely to relink them against a new dynamic Haskell library (integer-tommath) anyway, without a recompile. And tommath is small enough It's more about having complete namespace control. > And do you mean shipping this libtommath GHC by default (instead of > integer-simple) and starting to develop an integer-gmp or package on > hackage? > > Gergely > I don't know. :) There are a lot of open questions here, it was just a suggestion of something that A) is not totally inefficient while B) not hurting outside integrations so much. I have no immediate opinions on whether we should gut integer-simple or anything. It seems to work for the cases people want it. At the very least, we want to see what the relative speed between the three is. I think this can be done already by writing a wrapper around tommath in Haskell, and then benchmarking between -simple, -gmp and tommath. If tommath is portable and considerably faster than -simple, then that option of gutting it can be on the table, but I see no rush to do this. The question of switching defaults from GMP to something like this also depends on the benchmarks, really. But again I see no reason to rush this, we should obviously compile some evidence to support the theory first. I should also note there is also TomsFastMath by the same author, which is basically libtommath but with optional support for inline assembly on a variety of architectures (including all the ones we support :) It also still provides a mostly compatible API - and the web page already says TomsFastMath is faster than OpenSSL on amd64 :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

FW: can't make build fail
by Simon Peyton-Jones 23 Oct '13

23 Oct '13

Austin, (or anyone else) #8320 is urgent, but I can't debug it if I can't reproduce it. You can reproduce it. Can you help me do so? Simon From: Simon Peyton-Jones Sent: 22 October 2013 08:08 To: Austin Seipp Subject: can't make build fail Austin I have just done a vanilla "sh validate" on snake.foxdie.org, and it worked fine. Haddock docs were built. So I can't reproduce the failure #8320 on the very same machine that you get the failure. That's weird. You could sudo to me and try in ~/code/HEAD. I didn't make a mk/validate.mk file, so I'm just using the underlying mk/validate-settings.mk Can't debug till I can reproduce! Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Re: [commit: testsuite] master: Update performance test due to fix for #8456 (1e31b00)
by Simon Marlow 23 Oct '13

23 Oct '13

On 18/10/2013 18:21, git(a)git.haskell.org wrote: > @@ -259,13 +261,15 @@ test('T783', > # 2012-10-08: 226907420 (x86/Linux) > # 2013-02-10: 329202116 (x86/Windows) > # 2013-02-10: 338465200 (x86/OSX) > - (wordsize(64), 640324528, 10)]), > + (wordsize(64), 734038080, 10)]), > # prev: 349263216 (amd64/Linux) > # 07/08/2012: 384479856 (amd64/Linux) > # 29/08/2012: 436927840 (amd64/Linux) > # 12/11/2012: 640324528 (amd64/Linux) > # (OldCmm removed: not sure why this got worse, the > # other perf tests remained about the same) > + # 18/10/2013: 734038080 (amd64/Linux) > + # (fix for #8456) Yikes! 10% just for that change to CmmContFlowOpt? Are you sure? Cheers, Simon

1 0

small hiccup in new GND check
by Richard Eisenberg 22 Oct '13

22 Oct '13

Hi all, The implementation of the new GND check is done and was rather straightforward. But, it brings up a new design issue: With the old check, a writer of a class C could say `type role C nominal` to prevent GND use with that class. Now, all classes have nominal parameters, and there is no (clean) way for a class writer to stop the use of GND. Perhaps this is OK -- classes can't in general be abstract -- but I thought we should pause a moment to reflect on this consequence of the design. For the curious, you can see the code in my github fork at https://raw.github.com/goldfirere/ghc/master/compiler/typecheck/TcDeriv.lhs (search for `role_errs`). An example of the new error message is in https://github.com/goldfirere/testsuite/blob/master/tests/roles/should_fail… I'm running further tests now, so wibbles to the above may happen. Richard

3 3

Always false stack checks are not eliminated - fix on the way
by Jan Stolarek 21 Oct '13

21 Oct '13

Hi guys, I accidentally introduced a bug in one of my recent commits ( 94125c97e49987e91fa54da6c86bc6d17417f5cf): stack checks of the form if (Sp < SpLim) goto cUP; else goto cUQ; are not eliminated in the Cmm. I have a fix, but need to validate it and update the comments. It will be ready tomorrow. Janek

2 3

Significant size increase in GHC HEAD's static library sizes
by Herbert Valerio Riedel 21 Oct '13

21 Oct '13

Hello * While generating .deb packages of various GHC 7.x releases[1] I noticed a peculiar jump in the resulting binary .deb package for GHC HEAD (about +50% wrt to GHC 7.6.3); at first I thought this was mostly due to having enabled shared libaries for that particular package, but then I compared the .a sizes, and noticed some significant increases in object sizes: For instance, Cabal's library file jumps to: 24M ghc-6.12.3/Cabal-1.8.0.6/libHSCabal-1.8.0.6.a 27M ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a 28M ghc-7.2.2/Cabal-1.12.0/libHSCabal-1.12.0.a 27M ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0.a 28M ghc-7.6.3/Cabal-1.16.0/libHSCabal-1.16.0.a 41M ghc-7.7.20131018/Cabal-1.18.1.1/libHSCabal-1.18.1.1.a A similiar increase can be observed for the ghc library: 56M 6.12.3/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3.a 65M 7.0.4/lib/ghc-7.0.4/ghc-7.0.4/libHSghc-7.0.4.a 73M 7.2.2/lib/ghc-7.2.2/ghc-7.2.2/libHSghc-7.2.2.a 78M 7.4.2/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2.a 76M 7.6.3/lib/ghc-7.6.3/ghc-7.6.3/libHSghc-7.6.3.a 103M head/lib/ghc-7.7.20131018/ghc-7.7.20131018/libHSghc-7.7.20131018.a But there are other libraries, such as `base` that don't show this kind of size increase. I haven't had time to investigate, but I wanted to report my observation in case somebody has an explanation for this. [1]: https://launchpad.net/~hvr/+archive/ghc Cheers, hvr

2 1

Unexpected failures on Travis
by Joachim Breitner 19 Oct '13

19 Oct '13

Hi, my inofficial travis build of GHC produced reliably these test suite failures. These do not occur when I use my regular GHC development tree, but they do occur with the settins of travis. The settings include echo 'GhcLibWays = v' >> mk/build.mk so I’m inclined to put unless(have_dynamic(),skip) to all these tests, but maybe someone with better understanding of theses issues could comment on them first? The failures I am talking about are Unexpected failures: ghc-api/T7478 T7478 [bad exit code] (normal) plugins plugins06 [exit code non-0] (normal) quasiquotation T7918 [bad exit code] (normal) th TH_Roles3 [stderr mismatch] (normal) th TH_Roles4 [stderr mismatch] (normal) and the error messages in detail can be found on https://s3.amazonaws.com/archive.travis-ci.org/jobs/12722962/log.txt To reproduce this, simply run git https://github.com/nomeata/ghc-complete.git cd ghc-complete ./validate.sh Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 3

Exponential compilation slowdown with ImplicitParams extension.
by Dmitry Vyal 19 Oct '13

19 Oct '13

Greetings, recently GHC-7.6.2 hung while compiling my program. I was able to minify it to this: {-# LANGUAGE ImplicitParams #-} data D = D Int deriving Show slow_to_compile :: IO () slow_to_compile = do tst1 <- return 1 let ?tst1 = tst1 let ?tst2 = tst1 let ?tst3 = tst1 let ?tst4 = tst1 let ?tst5 = tst1 let ?tst6 = tst1 let ?tst7 = tst1 print $ D ?tst1 The compilation finishes actually. But it's very slow. The time depends on number of implicit parameter bindings. Looks like it grows as exponential function of it. As a workaround you can explicitly specify type for tst1. Is it a known issue? Best regards, Dmitry

1 0

Validate failures
by Simon Marlow 19 Oct '13

19 Oct '13

From a validate run just now on x86_64/Linux: Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enoug(normal) rename/should_fail rnfail055 [stderr mismatch] (normal) roles/should_fail Roles12 [bad stderr] (normal) typecheck/should_fail T3468 [stderr mismatch] (normal) Several of these look similar: =====> T3468(normal) 1758 of 3823 [0, 0, 0] cd ./typecheck/should_fail && '/home/simon/code-all/work/ghc-validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make T3468 -v0 >T3468.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./typecheck/should_fail/T3468.stderr 2013-10-08 15:12:35.819480965 +0100 +++ ./typecheck/should_fail/T3468.comp.stderr 2013-10-08 16:54:03.254974833 +0100 @@ -2,13 +2,6 @@ T3468.hs-boot:3:1: Type constructor ‛Tool’ has conflicting definitions in the module and its hs-boot file - Main module: data Tool d - No C type associated - Roles: [phantom] - RecFlag Recursive, Promotable - = F :: forall d a. a -> Tool d Stricts: _ - FamilyInstance: none - Boot file: abstract(False) Tool - No C type associated - RecFlag NonRecursive, Not promotable - FamilyInstance: none + Main module: data Tool d where + F :: a -> Tool d + Boot file: data Tool *** unexpected failure for T3468(normal)

3 2

Xcode 5 support for GHC iOS
by Luke Iannini 19 Oct '13

19 Oct '13

Hi all, Just wanted to let you know I've finished updating GHC iOS to support Xcode 5. The new scripts are at https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find updated instructions at http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . Please let me know if you have any trouble! Cheers Luke

4 6