- ghc-tickets - Haskell.org

[GHC] #15474: Error message mentions Any
by GHC 30 Aug '18

30 Aug '18

#15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug. File: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module T15474 where import Data.Kind (Type) data Proxy a type Forall = forall t. Proxy t f1 :: forall (t :: Type). Proxy t f1 = f1 f2 :: Forall f2 = f1 }}} gives an error message mentioning Any: {{{ • Couldn't match type ‘GHC.Types.Any’ with ‘*’ Expected type: Proxy t Actual type: Proxy t0 }}} The appearance of Any is suspicious - I thought it's an implementation detail? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15474> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8279: bad alignment in code gen yields substantial perf issue
by GHC 29 Aug '18

29 Aug '18

#8279: bad alignment in code gen yields substantial perf issue ------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- independently, a number of folks have noticed that in various ways, GHC currently has quite a few different memory alignment related performance problems that can have >= 10% perf impact! Nicolas Frisby notes {{{ On my laptop, a program showed a consistent slowdown with -fdicts-strict I didn't find any obvious causes in the Core differences, so I turned to Intel's Performance Counter Monitor for measurements. After trying a few counters, I eventuall saw that there are about an order of magnitude more misaligned memory loads with -fdicts-strict than without, so I think that may be a significant part of the slowdown. I'm not sure if these are code or data reads. Can anyone suggest how to validate this hypothesis about misaligned reads? A subsequent commit has changed the behavior I was seeing, so I'm not interested in alternatives means to determine if -fdicts-strict is somehow at fault — I'm just asking specifically about data/code memory alignment in GHC and how to diagnose/experiment with it. }}} Reid Barton has independently noted {{{ so I did a nofib run with llvm libraries, ghc quickbuild so there's this really simple benchmark tak, https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs it doesn't use any libraries at all in the main loop because the Ints all get unboxed but it's still 8% slower with quick-llvm (vs -fasm) weird right? [14:36:30] <carter> could you post the asm it generates for that function? [14:36:49] <rwbarton> well it's identical between the two versions <rwbarton> but they get linked at different offsets because some llvm sections are different sizes <rwbarton> if I add a 128-byte symbol to the .text section to move it to the same address... then the llvm libs version is just as fast <rwbarton> well, apparently 404000 is good and 403f70 is bad <rwbarton> I guess I can test other alignments easily enough <rwbarton> I imagine it wants to start on a cache line <rwbarton> but I don't know if it's just a coincidence that it worked with the ncg libraries <rwbarton> that it got a good location <rwbarton> for this program every 32-byte aligned address is 10+% faster than any merely 16-byte aligned address <rwbarton> and by alignment I mean alignment of the start of the Haskell code section <carter> haswell, sandybridge, ivy bridge, other? <rwbarton> dunno <rwbarton> I have similar results on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz <rwbarton> and on Quad-Core AMD Opteron(tm) Processor 2374 HE <carter> ok <rwbarton> trying a patch now that aligns all *_entry symbols to 32 bytes }}} the key point in there is that on the tak benchmark, better alignment for the code made a 10% perf differnce on TAk on Core2 and opteron cpus! benjamin scarlet and Luite are speculating that this may be further induced by Tables next to code (TNC) accidentally creating bad alignment so theres cache line pollution / conflicts between the L1 Instruction- cache and data-caches. So one experiment would be to have the TNC transform pad after the table so the function entry point starts on the next cacheline? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15555: Finish separating the stable name and stable pointer tables
by GHC 29 Aug '18

29 Aug '18

#15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.4.3 System | 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: -------------------------------------+------------------------------------- The stable name table and stable pointer table are both implemented in `rts/Stable.c`, with their code interleaved. As far as I can tell, they basically don't share ''anything''—or at least anything that they actually ''should''. They ''do'' share a mutex, which smells like a terrible idea. Doesn't that just introduce contention between `StableName` and `StablePtr` operations in different threads? They also share an initialization function, `initStableTables`, that appears to allocate both a stable name table and a stable pointer table as soon as either of them is needed. Unless I'm missing something, there's no point whatsoever in doing that. So I think we should actually divide `Stable.c` into `StableName.c` and `StablePtr.c` and give each its own mutex. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7674: Separate StablePtr table from StableName table.
by GHC 29 Aug '18

29 Aug '18

#7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer <David.Feuer@…>): In [changeset:"f48e276a5ba68d8b6fcb4a558022581fb30f9326/ghc" f48e276a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f48e276a5ba68d8b6fcb4a558022581fb30f9326" Finish stable split Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7674#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn
by GHC 29 Aug '18

29 Aug '18

#15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Research needed Component: | Version: 8.5 libraries/base | 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: -------------------------------------+------------------------------------- By importing Data.List, we currently get: {{{#!hs sortBy :: (a -> a -> Ordering) -> [a] -> [a] maximumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a minimumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a sortOn :: Ord b => (a -> b) -> [a] -> [a] }}} I believe sortOn to be a very useful 'shortcut'. In that spirit, I propose we add: {{{#!hs maximumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5945: Lambda lifting
by GHC 28 Aug '18

28 Aug '18

#5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284, #9476 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5945#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15568: Kind variables in type family aren't quantified in toposorted order
by GHC 28 Aug '18

28 Aug '18

#15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- Recently, I noticed that an error message I was experiencing differs between GHC 8.4.3 and GHC 8.6.1+. Take this program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy import GHC.Exts (Any) type family F (a :: j) :: k f :: Proxy a -> Proxy (F (a :: j) :: k) f _ = Proxy :: Proxy (Any :: k) }}} On 8.4.3, you'll get: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F j k a’ Expected type: Proxy k (F j k a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F j k a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But on 8.6.1 and HEAD, you'll instead get: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F k j a’ Expected type: Proxy k (F k j a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F k j a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notice that on 8.4.3, it displays `F j k a`, but on 8.6.1, it displays `F k j a`! After some digging, it turns out that this is because on 8.6.1, the order of `F`'s kind variables are quantified completely differently! On 8.4.3, we have: {{{ λ> :kind F F :: forall j k. j -> k }}} But on 8.6.1, we have: {{{ λ> :kind F F :: forall k j. j -> k }}} I would prefer the old behavior of 8.4.3, since `j k` is what you get after performing a left-to-right, reverse topological sort on the kind variables of `F`, which is consistent with how type signatures quantify their type variables. Currently, this quirk doesn't matter that much (except for error messages, as shown above), but if/when visible kind application is implemented, it'll be more noticeable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11350: Allow visible type application in patterns
by GHC 28 Aug '18

28 Aug '18

#11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructors (and pattern synonyms) when treated as expressions may be applied to types: {{{#!hs {-# LANGUAGE TypeApplications #-} Nothing :: Maybe a Nothing @() :: Maybe () pattern Pair :: a -> a -> (a, a) pattern Pair x y = (x, y) Pair :: a -> a -> (a, a) Pair @Int :: Int -> Int -> (Int, Int) }}} But using them in patterns won't parse: {{{#!hs -- parse error in pattern: @Int maybeToList :: Maybe Int -> [Int] maybeToList (Nothing @Int) = [] maybeToList (Just @Int x) = [x] -- parse error in pattern: @Int add :: (Int, Int) -> Int add (Pair @Int x y) = x + y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak).
by GHC 28 Aug '18

28 Aug '18

#15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (FFI) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**. [[br]][[br]] There are four files attached to this ticket. * **HaskellExports.hs** contains exact one foreign export function; * **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference; * **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory); * **build.sh** is a script for building the library. [[br]] The main program was built with MSVC 2015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 28 Aug '18

28 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): There's another way to go "generational" that takes into account the fact that (I imagine) stable names tend to live a long time. We could have just one hash table, but also keep a list of all the stable names whose underlying objects are in the nursery. When we perform a minor collection, we go through that list and delete the dead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0