September 2018 - ghc-tickets

[GHC] #11719: Cannot use higher-rank kinds with type families
by GHC 29 Oct '18

29 Oct '18

#11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket came out of a discussion with Richard in this mailing list post: https://mail.haskell.org/pipermail/haskell- cafe/2016-March/123462.html Here's the code that should work, but doesn't: {{{ import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * type family (f :: a ~> b) @@ (x :: a) :: b data Null a = Nullable a | NotNullable a type family ((f :: b ~> c) ∘ (g :: a ~> b)) (x :: a) :: c where (f ∘ g) x = f @@ (g @@ x) type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where -- this fails :( -- BaseType k x = (@@) k x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #15071: :set usage in ghci tests breaks platform independence of output
by GHC 29 Oct '18

29 Oct '18

#15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance: {{{ --- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 +++ "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 @@ -7,7 +7,6 @@ GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fno-diagnostics-show-caret - -fexternal-dynamic-refs -fignore-optim-changes -fignore-hpc-changes -fno-ghci-history }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15076: Typed hole causes GHC to panic (No skolem info)
by GHC 29 Oct '18

29 Oct '18

#15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypedHoles, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14040 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (forall t. Proxy t -> Proxy (f t)) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Cb[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror
by GHC 29 Oct '18

29 Oct '18

#15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Wall-missed-specialisations -Werror`, warnings are produced, but they aren't fatal. `-Werror` should make them fatal but doesn't. A somewhat-minimal example: {{{#!hs {-# OPTIONS_GHC -Wall-missed-specialisations -Werror #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings3 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings are: {{{ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7
by GHC 29 Oct '18

29 Oct '18

#15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error. With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands {{{#!bash c:\Users\user.name\wrk> bash $ mkdir ghc-pkg-check $ cd ghc-pkg-check $ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown- mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k $ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf - $ cd ghc-8.2.2/bin/ $ ./ghc-pkg.exe --version GHC package manager version 8.2.2 Segmentation fault }}} The error arises irrespective of how and with what arguments to call `ghc- pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console: {{{#!bat > stack build --arch=i386 --resolver=11.9 }}} I checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I **did not check** the problem **on another versions** of MS Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14552: GHC panic on pattern synonym
by GHC 29 Oct '18

29 Oct '18

#14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType, | ViewPatterns | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes, ViewPatterns, PatternSynonyms, TypeOperators, KindSignatures, PolyKinds, DataKinds, TypeFamilies, TypeInType, GADTs #-} import Data.Kind data family Sing a type a --> b = (a, b) -> Type type family (@@) (f::a --> b) (x::a) :: b data Proxy a = Proxy newtype Limit' :: (k --> Type) -> Type where Limit' :: (forall xx. Proxy xx -> f@@xx) -> Limit' f data Exp :: [Type] -> Type -> Type where TLam' :: Proxy f -> (forall aa. Proxy aa -> Exp xs (f @@ aa)) -> Exp xs (Limit' f) pattern FOO f <- TLam' Proxy (($ Proxy) -> f) }}} ---> {{{ $ ghci -ignore-dot-ghci 119-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 119-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {a_a1Mh b_a1Mi rep_a1MB r_a1MC} tenv [a1MC :-> r_a1MC] cenv [] tys [k_a1Mj[ssk:3]] cos [] needInScope [a1Mj :-> k_a1Mj[ssk:3]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families
by GHC 29 Oct '18

29 Oct '18

#15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program and GHCi session which uses it: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Foo where import Data.Kind type family T1 (x :: f (a :: Type)) class C (a :: Type) where type T2 (x :: f a) }}} {{{ $ ghc2/inplace/bin/ghc-stage2 --interactive Foo.hs -fprint-explicit- foralls GHCi, version 8.7.20180831: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall {a} (f :: * -> *). f a -> * }}} Something is strange about the visibility of `a` in the kinds of `T1` and `T2`. In `T1`, it's visible, but in `T2`, it's not! I would expect them to both be visible, since they were both mentioned by name in each type family's definition. This isn't of much importance at the moment, but it will be once visible kind application lands, as this bug will prevent anyone from instantiating the `a` in `T2` using a kind application. I indicated 8.5 as the version for this ticket since this behavior has changed since GHC 8.4, where you'd get the following: {{{ $ /opt/ghc/8.4.3/bin/ghci Foo.hs -fprint-explicit-foralls GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall (f :: * -> *) a. f a -> * }}} Here, both `a`s are visible. However, it's still wrong in that `a` should be listed before `f` in `T2`'s telescope, since `a` was bound first (in `C`'s class head), before `f`. In that sense, the current behavior is a slight improvement, although we're not fully correct yet. The only difference between `T1` and `T2` is that `T2` is associated with a class, which suggests that there is some difference in code paths between the two that is accounting for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15685: Pattern signature not inferred
by GHC 28 Oct '18

28 Oct '18

#15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Should this pattern synonym declaration fail, {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, GADTs, PatternSynonyms #-} import Data.Kind data NS f as where Here :: f a -> NS f (a:as) data NP :: (k -> Type) -> ([k] -> Type) where Nil :: NP f '[] pattern HereNil = Here Nil }}} {{{ $ ghci -ignore-dot-ghci hs/457.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/457.hs, interpreted ) [flags changed] hs/457.hs:11:19: error: • Could not deduce: f ~~ NP f0 from the context: (as ~ (a1 : as1), GHC.Types.Any ~ '[]) bound by the signature for pattern synonym ‘HereNil’ at hs/457.hs:11:1-26 ‘f’ is a rigid type variable bound by the signature for pattern synonym ‘HereNil’ at hs/457.hs:11:1-26 Expected type: NS f as Actual type: NS (NP f0) ('[] : as0) • In the expression: Here Nil In an equation for ‘HereNil’: HereNil = Here Nil • Relevant bindings include $bHereNil :: NS f as (bound at hs/457.hs:11:9) | 11 | pattern HereNil = Here Nil | ^^^^^^^^ hs/457.hs:11:24: error: • Kind mismatch: cannot unify (f :: a -> *) with: NP a0 :: [GHC.Types.Any] -> * Their kinds differ. Expected type: f a1 Actual type: NP a0 GHC.Types.Any • In the pattern: Nil In the pattern: Here Nil In the declaration for pattern synonym ‘HereNil’ | 11 | pattern HereNil = Here Nil | ^^^ Failed, no modules loaded. Prelude> }}} It can be given a pattern signature, my question is can this not be inferred {{{#!hs -- pattern HereNil :: NS (NP f) ('[]:as) pattern HereNil :: () => (nil_as ~ ('[]:as)) => NS (NP f) nil_as pattern HereNil = Here Nil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue
by GHC 28 Oct '18

28 Oct '18

#15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The eventlog framework currently writes all environment variables to the eventlog file. This may cause a security issue as some external tools expect user to set credentials in environment variables. It's possible for the user to publish an eventlog which contains credentials without knowing it. In general it's not a good idea to set credentials in environment variables but I think GHC should stop writing environment variables to the eventlog implicitly and this feature should be opt-in. I'm not sure if this feature is widely used or if we can just drop it. If it's used to some extend maybe we can provide a function that does this job in a library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14854: The size of FastString table is suboptimal for large codebases
by GHC 28 Oct '18

28 Oct '18

#14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Context: I was profiling a no-op rebuild (build once, do incremental build with nothing changed) of a large code base. It takes `35.829s`, and according to the profile about `20%` of the time is spent in `mkFastStringByteString`. I run it with `-dfaststring-stats +RTS -s` and got: {{{ FastString stats: size: 4091 entries: 829959 longest chain: 268 has z-encoding: 0% 50,011,906,640 bytes allocated in the heap 7,936,277,664 bytes copied during GC 3,106,526,336 bytes maximum residency (8 sample(s)) 123,108,224 bytes maximum slop 10169 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 117 colls, 37 par 32.390s 2.293s 0.0196s 0.0911s Gen 1 8 colls, 3 par 19.722s 2.266s 0.2832s 0.6936s Parallel GC work balance: 60.62% (serial 0%, perfect 100%) TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.009s ( 0.009s elapsed) MUT time 277.370s ( 31.261s elapsed) GC time 52.113s ( 4.558s elapsed) EXIT time 0.005s ( 0.001s elapsed) Total time 329.497s ( 35.829s elapsed) Alloc rate 180,307,295 bytes per MUT second Productivity 84.2% of total user, 87.3% of total elapsed }}} That's pretty bad, fitting `800k` elements in `4k` buckets is hard. To confirm this indeed could be improved I changed the size to `2^20` (`1048576`) and also removed division in `hashStr` function (it come up on `perf` profile), like this: {{{ hashStr :: Ptr Word8 -> Int -> Int -- use the Addr to produce a hash value between 0 & m (inclusive) hashStr (Ptr a#) (I# len#) = loop 0# 0# where loop h n | isTrue# (n ==# len#) = I# h | otherwise = loop h2 (n +# 1#) where !c = ord# (indexCharOffAddr# a# n) -- !h2 = (c +# (h *# 128#)) `remInt#` -- hASH_TBL_SIZE# -- NOTE: below is multiplication by 127 (a prime) and division by 2^20, it's by no means the best hashing function !h2 = (c +# ((h `uncheckedIShiftL#` 7#) -# h)) `andI#` hASH_TBL_SIZE_MASK# }}} Here's what I ended up with: {{{ FastString stats: size: 1048576 entries: 829959 longest chain: 8 has z-encoding: 0% 51,012,218,048 bytes allocated in the heap 8,948,377,768 bytes copied during GC 3,543,797,248 bytes maximum residency (8 sample(s)) 139,428,352 bytes maximum slop 10502 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 115 colls, 39 par 32.261s 2.677s 0.0233s 0.2225s Gen 1 8 colls, 3 par 21.786s 2.329s 0.2911s 0.5737s Parallel GC work balance: 48.75% (serial 0%, perfect 100%) TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.008s ( 0.008s elapsed) MUT time 65.508s ( 23.791s elapsed) GC time 54.047s ( 5.006s elapsed) EXIT time 0.007s ( 0.001s elapsed) Total time 119.570s ( 28.806s elapsed) Alloc rate 778,712,134 bytes per MUT second Productivity 54.8% of total user, 82.6% of total elapsed }}} The realtime improvement is nice (`-20%`), but even nicer is the "serial" time improvement, from `329.497s`to `119.570s` (`2.75x` speedup). This is on modified 8.0.2, but the related code looks about the same on HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11