December 2013 - ghc-tickets

Re: [GHC] #7091: DPH Matrix product memory usage
by GHC 09 Dec '13

09 Dec '13

#7091: DPH Matrix product memory usage --------------------------------------------+--------------------------- Reporter: mblanco | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Data Parallel Haskell | Version: 7.4.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by benl): * status: new => closed * resolution: => invalid Comment: I've set it to invalid to clean up the ticket data base. This is a research problem, not a bug in the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7091#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 08 Dec '13

08 Dec '13

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 08 Dec '13

08 Dec '13

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by blitzcode): * cc: tim@…, hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7091: DPH Matrix product memory usage
by GHC 07 Dec '13

07 Dec '13

#7091: DPH Matrix product memory usage --------------------------------------------+--------------------------- Reporter: mblanco | Owner: benl Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Data Parallel Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by George): More specifially, in section 5.5 the paper states: nested parallelism can increase the asymptotic space complexity in a way that this paper does not address [15, 19]. ... The flattened version is a hylomorphism that first computes O(n{{{^}}}2) distances before reducing them to determine the maximum. Whereas the sequential version would run in O(n) space, the flattened version needs O(n{{{^}}}2) space to hold the intermediate vector of distances. Given the preceding this issue seems to be a known consequence of the dph algorithm and as such the status of this should be "Not a bug" as it is not a GHC bug. However this is just my opinion and I don't feel I have the expertise to actually change the bug status -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7091#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 07 Dec '13

07 Dec '13

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Would a first step towards something in this direction be a Strict Newtype? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 07 Dec '13

07 Dec '13

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * cc: carter.schonwald@… (added) * failure: => None/Unknown * version: 6.6.1 => 7.7 Comment: bumping the version, this still holds in head -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 07 Dec '13

07 Dec '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): The change of allocations in `cacheprof` is weird: the output of `-ddump- simpl` is identical (ignoring unique numbers and strictness annotations). So there is a change hidden in the libraries somewhere... hopefully nothing to worry about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 07 Dec '13

07 Dec '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Finally I got the code in a shape good enough for controlled experiments. I started with a merge of branch `better-ho-cardinality` and master (at [4025d66/ghc]). This is my baseline. The next measurement is with the nested CPR analysis, but without changing the worker-wrapper code, i.e. the CPR information is only used as far as before. Here is the result (skipping lines with `+0.0%`): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% +0.6% +0.3% +0.6% -3.4% -------------------------------------------------------------------------------- Min +0.0% -0.0% -8.9% -8.7% -3.4% Max +0.1% +0.6% +9.1% +9.1% +3.0% Geometric Mean +0.0% +0.0% -0.4% -0.4% -0.0% }}} I did not look at `cacheprof`, but I am confident that I did not break anything serious by introducing nested CPR to the analysis. Next measurement is is with the worker/wrapper code handling nested CPR, but using `-fnested-cpr-off` to make sure that all CPR information is actually what we had before. I used this to ensure that my `mkWWcpr`-implementation did not regress over the old one (it turned out that I did mess up in various ways, so this is important): {{{ -------------------------------------------------------------------------------- cacheprof +0.0% -0.6% -0.3% -0.6% +1.8% -------------------------------------------------------------------------------- Min +0.0% -0.6% -1.4% -1.7% +0.0% Max +0.0% +0.0% +2.3% +2.4% +1.8% Geometric Mean -0.0% -0.0% +0.1% +0.1% +0.0% }}} And now the exciting part: The same code, but now without `-fnested-cpr- off`: {{{ -------------------------------------------------------------------------------- anna +0.5% +0.1% 0.18 0.19 +0.0% boyer2 +0.5% +0.4% 0.01 0.01 +0.0% bspt +1.1% +0.2% 0.01 0.01 +0.0% cacheprof +0.5% -0.7% +0.6% +1.2% -2.6% calendar +0.5% +0.1% 0.00 0.00 +0.0% comp_lab_zift +0.5% +0.1% +0.0% +0.0% +0.0% infer +0.4% -1.2% 0.09 0.09 +0.0% para +0.4% +0.2% -1.5% -1.5% +0.0% prolog +0.5% +0.2% 0.00 0.00 +0.0% reptile +0.7% +0.3% 0.02 0.02 +0.0% -------------------------------------------------------------------------------- Min +0.4% -1.2% -8.0% -8.0% -4.4% Max +1.1% +0.4% +6.9% +6.9% +4.2% Geometric Mean +0.5% -0.0% +0.0% -0.0% -0.1% }}} so most of the 101 benchmarks are not affected by nested CPR (in its current, prelimary) form at all (besides a quite reliable increase of binary sizes by `+0.5%` – does Size include `.hi`-files?). When it changes the Allocs number the effect is small and indecisive. It may be that fixing #8598 would improve matters (or at least allow nested CPR to occur more often, whether for the better or for the worse, I don’t know.) I might look at that next, but probably off master, as it is an independent feature. Of course it is also quite likely that the nested CPR analysis needs more tuning by looking at code where we want it to fire. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 06 Dec '13

06 Dec '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #8598 Comment: Also see ticket #8598 (CPR after IO action) which is not directly related to nested cpr, but will become more relevant when want to do nested CPR inside `IO`, such as in this example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7986: make newBroadcastTChanIO match newBroadcastTChan
by GHC 06 Dec '13

06 Dec '13

#7986: make newBroadcastTChanIO match newBroadcastTChan -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.6.3 (other) | Keywords: stm Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => stm * resolution: => fixed * status: new => closed * component: Compiler => libraries (other) Comment: Yep, this was committed in https://github.com/ghc/packages- stm/commit/1187332f18de8bdd8ede1d940fe035fe0acac424. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7986#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0