- ghc-tickets - Haskell.org

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

07 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 06 Dec '13

06 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 06 Dec '13

06 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 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 -------------------------------------+------------------------------------- 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 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 -------------------------------------+------------------------------------- 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

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

06 Dec '13

#7986: make newBroadcastTChanIO match newBroadcastTChan -------------------------------+------------------------------------------- Reporter: | Owner: WrenThornton | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by khyperia): Is this ticket still valid? If my guess is correct, these functions eventually transformed into `newChan` in libraries/base/Control/Concurrent/Chan.hs, but I'm not sure. Not sure what to do about this ticket, though - it's still in "new" status. (I found it while digging for tickets to do) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7986#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7307: Share top-level code for strings
by GHC 05 Dec '13

05 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 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 ezyang): You may be right; static thunks might be blackholed anyway so the update can be done atomically. But I'd have to check: note the comment also states that static thunks have no payload; this is not true for TopUnpack. I am not sure if adjusting THUNK_STATIC to now take a payload will cause any problems. Probably it's best to check all cases in the RTS that handle this closure type and see if they have any assumptions about payload sie. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0