- ghc-devs - Haskell.org

RE: Missed beta reductions
by Simon Peyton Jones 28 Mar '18

28 Mar '18

Yes, it’s possible that he sequence you are seeing is what is happening to you. But why is that not what you want to see? What are you trying to achieve? Since this function might be applied to many different arguments, it’s probably not a good idea to do anything unconditionally… S From: David Feuer <david(a)well-typed.com> Sent: 27 March 2018 01:04 To: Simon Peyton Jones <simonpj(a)microsoft.com>; ghc-devs(a)haskell.org Subject: RE: Missed beta reductions Hmmm. So you think maybe it's doing something like (roughly; I don't have the exact case in front of me) (\p q -> f p (g p q)) this that ==> beta reduce let p = this q = that in f p (g p q) ==> inline q let p = this in f p (g p that) ? I tried marking the "this" in question INLINE CONLIKE [0]. Shouldn't that tell GHC that duplicating it is fine? I really want to see it for RULES. David Feuer Well-Typed, LLP -------- Original message -------- From: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Date: 3/26/18 7:14 PM (GMT-05:00) To: David Feuer <david(a)well-typed.com<mailto:david@well-typed.com>>, ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: RE: Missed beta reductions GHC always beta-reduces. It does not always inline. For that: -ddump-inlinings Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of David Feuer Sent: 26 March 2018 23:59 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Missed beta reductions What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David Feuer Well-Typed, LLP

2 2

Missed beta reductions
by David Feuer 27 Mar '18

27 Mar '18

What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David FeuerWell-Typed, LLP

2 2

Updating Phabricator
by Ben Gamari 26 Mar '18

26 Mar '18

Hello everyone, In around 90 minutes I will start a Phabricator upgrade. It has been a few months since the last update so it may take up 30 minutes or so. I'll send a message before starting. Cheers, - Ben

1 2

Windows
by Simon Peyton Jones 26 Mar '18

26 Mar '18

I've just got a new laptop (the old one's hard disk died) so I'm trying to get to the point of being able to build GHC again. I'm currently stuck here: ./configure configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180323 checking for GHC Git commit id... inferred affdea82bb70e5a912b679a169c6e9a230e4c93e checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Unknown OS msys Any ideas? Thanks Simon

6 12

Curious demand in a function parameter
by Ömer Sinan Ağacan 26 Mar '18

26 Mar '18

Hi, In this program {-# LANGUAGE MagicHash #-} module Lib where import Control.Exception import GHC.Exts import GHC.IO data Err = Err deriving (Show) instance Exception Err f :: Int -> Int -> IO Int f x y | x > 0 = IO (raiseIO# (toException Err)) | y > 0 = return 1 | otherwise = return 2 when I compile this with 8.4 -O2 I get a strict demand on `y`: f :: Int -> Int -> IO Int [GblId, Arity=3, Str=<S(S),1*U(U)><S(S),1*U(U)><S,U>, ...] but clearly `y` is not used on all code paths, so I don't understand why we have a strict demand here. I found this example in the comments around `raiseIO#`: -- raiseIO# needs to be a primop, because exceptions in the IO monad -- must be *precise* - we don't want the strictness analyser turning -- one kind of bottom into another, as it is allowed to do in pure code. -- -- But we *do* want to know that it returns bottom after -- being applied to two arguments, so that this function is strict in y -- f x y | x>0 = raiseIO blah -- | y>0 = return 1 -- | otherwise = return 2 However it doesn't explain why we want be strict on `y`. Interestingly, when I try to make GHC generate a worker and a wrapper for this function to make the program fail by evaluating `y` eagerly I somehow got a lazy demand on `y`: {-# LANGUAGE MagicHash #-} module Main where import Control.Exception import GHC.Exts import GHC.IO data Err = Err deriving (Show) instance Exception Err f :: Int -> Int -> IO Int f x y | x > 0 = IO (raiseIO# (toException Err)) | y > 0 = f x (y - 1) | otherwise = f (x - 1) y main = f 1 undefined I was thinking that this program should fail with "undefined" instead of "Err", but the demand I got for `f` became: f :: Int -> Int -> IO Int [GblId, Arity=2, Str=<S(S),1*U(U)><L,1*U(U)>, ...] which makes sense to me. But I don't understand how my changes can change `y`s demand, and why the original demand is strict rather than lazy. Could anyone give me some pointers? Thanks Ömer

3 2

8.4.1 ghci findings
by Evan Laforge 23 Mar '18

23 Mar '18

I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference.

1 0

RE: ghc 8.0.2 vs 8.4.1 compilation time and performance
by Simon Peyton Jones 23 Mar '18

23 Mar '18

Evan That’s truly great information, thank you. Could you start a GHC ticket for it? Stuff gets lots in email, less so in tickets. The big take-away I got from your message is this: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 The bytes-allocated number has gone up a bit. (Not too surprising… the compiler is doing more.) But the productivity number is down sharply, and consistently so, which translates directly into longer compile times. Somehow, although residency is not increasing, GC time is greatly increased. We have some compiler/perf regression tests that track bytes-allocated, but not that track productivity, which is why we have noticed. It’d be good to figure out what’s gone wrong here. Maybe a change in nursery size or something stupid like that? It’d be great if someone felt up to investigating a bit Thanks for gathering this data. Simon From: Glasgow-haskell-users <glasgow-haskell-users-bounces(a)haskell.org> On Behalf Of Evan Laforge Sent: 21 March 2018 22:05 To: GHC users <glasgow-haskell-users(a)haskell.org> Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 Linux, PC: RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 Linux, PC: score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1

2 1

Why does SpecConstr run far later than specialisation
by Matthew Pickering 20 Mar '18

20 Mar '18

As far as I understand it, the goals of SpecConstr and specialisation are the same. One works for normal value arguments and one works for special type class dictionary arguments. However, looking at the pass order in `SimplCore`, specialisation runs very early before any major simplification but SpecConstr runs very late right at the end of the pipeline. Does anyone know the justification for this? It seems intuitively that they should work in the same way. Cheers, Matt

3 2

What does "return" keyword mean in INFO_TABLE_RET declarations?
by Ömer Sinan Ağacan 20 Mar '18

20 Mar '18

Hi, I'm trying to understand what a "return" list in INFO_TABLE_RET declaration line specifies. As far as I understand a "return" in the declaration line is something different than a "return" in the body. For example, in this definition: (in HeapStackCheck.cmm) INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) return (/* no return values */) { return (ptr); } The return list is empty and it even says "no return values" explicitly, yet it returns something. My guess is that the "return" list in the header is actually for arguments. I found this info table which has an argument: (in StgMiscClosures.cmm) INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs) return (P_ ret) { unwind Sp = Sp + WDS(2); #if defined(PROFILING) CCCS = cccs; #endif jump stg_ap_0_fast(ret); } This is the use site: (in Interpreter.c) #if defined(PROFILING) // restore the CCCS after evaluating the closure Sp_subW(2); SpW(1) = (W_)cap->r.rCCCS; SpW(0) = (W_)&stg_restore_cccs_eval_info; #endif Sp_subW(2); SpW(1) = (W_)tagged_obj; SpW(0) = (W_)&stg_enter_info; RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); If I understand this correctly, the "tagged_obj" code will put the return value in R1, pop the stack (which will have stg_restore_ccs_eval_info at the bottom) and jump to this the info table code shown above. So `P_ ret` is the value of `tagged_obj`, and the "return" list is actually for parameters. Did I get this right? If I did, I'm curious why it's called "return" and not "args" or something like that. Thanks, Ömer

4 7

ghcpkg05
by Simon Peyton Jones 20 Mar '18

20 Mar '18

On my Linux platform, with an in-place build, I get a consistent failure of ghcpkg05. Any ideas how I can fix it? Thanks Simon =====> ghcpkg05(normal) 1 of 1 [0, 0, 0] cd "./ghcpkg05.run" && $MAKE -s --no-print-directory ghcpkg05 Actual stderr output differs from expected: diff -uw "./ghcpkg05.run/ghcpkg05.stderr.normalised" "./ghcpkg05.run/ghcpkg05.run.stderr.normalised" --- ./ghcpkg05.run/ghcpkg05.stderr.normalised 2018-03-19 11:31:12.533918366 +0000 +++ ./ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-03-19 11:31:12.533918366 +0000 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX-ghc<VERSION>.so","libtestpkg-2.0-XXX-ghc<VERSION>.dylib","testpkg-2.0-XXX-ghc<VERSION>.dll"] on library path +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/text/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/containers/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) Unexpected results from: TEST="ghcpkg05"

2 2