November 2013 - ghc-tickets

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

26 Nov '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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: -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:22 simonpj]: > A neat approach might be to say that, when doing the fixpoint on a recursive group, trim off any nested CPR info from the demand signatures we use when processing the RHSs. Woudn’t that be far too imprecise? That would completely prevent nested CPR in loops, like `factIO` above... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

26 Nov '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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: -------------------------------------+------------------------------------- Comment (by simonpj): Great example! Graham Hutton would be interested, since he wrote a [http://www.cs.nott.ac.uk/~gmh/wrapper.pdf paper about worker/wrapper] (JFP 2009). A neat approach might be to say that, when doing the fixpoint on a recursive group, trim off any nested CPR info from the demand signatures we use when processing the RHSs. Simom -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error
by GHC 26 Nov '13

26 Nov '13

#2408: threadWaitRead on mingw32 threaded causes internal error -----------------------------------+--------------------------- Reporter: kirby | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Changes (by blackbox.dev): * status: closed => new * cc: blackbox.dev.ml@… (added) * failure: => Runtime crash * version: 6.8.3 => 7.6.1 * owner: simonmar => * resolution: fixed => Comment: This bug still occurs, see last comment on https://github.com/twittner /zeromq-haskell/issues/8 {{{ display.exe: internal error: waitRead# on threaded RTS (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} Replying to [ticket:2408 kirby]: > threadWaitRead (used in 6.8.x to avoid the non-interruptable getChar) causes internal error on GHC 6.8.2 and 6.8.3: > > {{{ > prompt: test: internal error: waitRead# on threaded RTS > (GHC version 6.8.2 for i386_unknown_mingw32) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > }}} > > This is because in GHC.Conc: > {{{ > threadWaitRead :: Fd -> IO () > threadWaitRead fd > #ifndef mingw32_HOST_OS > | threaded = waitForReadEvent fd > #endif > | otherwise = IO $ \s -> > case fromIntegral fd of { I# fd# -> > case waitRead# fd# s of { s -> (# s, () #) > }} > }}} > So the threaded case is ignored on mingw32, and waitRead# crashes on threaded RTS. > It should be at least written on the threadWaitRead documentation, and a workaround provided. > > I've attached a little program to show the issue (if compiled with -threaded on windows). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2408#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2233: Overhaul System.Process
by GHC 26 Nov '13

26 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 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 hvr): Replying to [comment:21 simonmar]: > Heh, clearly we need to pull the `async` package into the core libraries. But the patches look ok to me. ...that would pull in `stm` as well, wouldn't it? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

26 Nov '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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: -------------------------------------+------------------------------------- Comment (by nomeata): One solution, which seems to make sense, is to make the analysis a little bit less precise and more careful with recursive definition. If I make sure that an `Id` that is a LoopBreaker never has a `DmdResult` that `Converges` (by lub’ing it with `Diverges`), both the example above and the typecheck program of nofib compiles. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

26 Nov '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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: -------------------------------------+------------------------------------- Comment (by nomeata): Analysing the `typecheck` divergence yields a very interesting example of how nested CPR can go wrong, which I’d like to document here. It completely wreak havoc with this innocent function: {{{ repeat :: x -> [x] repeat x = x : repeat x }}} (This requires nesting of sum types, but just imagine for this example that `[]` was a stream data type with only one constructor, if you want). The analyizer figurs out that its demand signature is `DmdType <L,U>tm2(d,tm2(d,tm2(d,d)))`, i.e. it lazily uses its argument and will, with guaranteed convergence, produce a `:` constructor, and evaluating the second parameter thereof will also converge to a `:`, and so on. The signature could actually be infinite; my code cuts them off a a certain depth. This signature is certainly correct. So it seems this is eligible to a worker-wrapper-transformation. But when we do it we end up with (using non-core patterns for clarity): {{{ $wrepeat :: x -> (# a, a, a, [a] #) $wrepeat x = case x : repeat x of (x1:x2:x3:r) -> (# x1, x2, x3, r#) repeat x :: -> [x] repeat x = case $wrepeat x of (# x1, x2, x3, r#) -> (x1:x2:x3:r) }}} and now this diverges. I’m not entirely sure who is at fault here. Since the analysis yields a correct result, most likely the w/w transformation. But that does not seem to have enough information to prevent this. Needs more thinking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2233: Overhaul System.Process
by GHC 26 Nov '13

26 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 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 simonmar): Heh, clearly we need to pull the `async` package into the core libraries. But the patches look ok to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2233: Overhaul System.Process
by GHC 26 Nov '13

26 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 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 duncan): A few follow-up patches. The last one needs rather careful review. It's all rather subtle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD
by GHC 25 Nov '13

25 Nov '13

#8013: Strange closure type error building hs-kqueue on FreeBSD ---------------------------------------+---------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by pgj): * cc: pgj@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8013#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

25 Nov '13

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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: -------------------------------------+------------------------------------- Comment (by nomeata): I’m working on nested cpr now. There a few related tickets (#1885 and #2289), but I’ll report my progress here, mostly because this has the lowest number and the fine `factIO` example. Building on a patch from SPJ I now have a branch that works in simple cases. I have some doubts about correctness (i.e. `bothDmdType` is used both for type applications and cases, but I believe these need to treat the question of convergence differently). Also, it does ''not'' work for the `factIO` example yet, probably because there is an unboxed tuple to begin with. Need to investigate. The testsuite goes through (reporting, as it seems, only differences in, well, demand signatures), but nofib’s `typecheck` fills the memory quickly, so the analysis clearly is not conservative yet.. Need to investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0