Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: low |Milestone: 7.2.1 Component: Compiler | Version: 6.10.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by batterseapower): See also #5075 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad -+-- Reporter: simonpj |Owner: Type: run-time performance bug | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonpj): Indeed GHC isn't a supercompiler and doesn't specialise recursive functions for their call sites. As it happens, Peter Jonsson started yesterday as an intern to try just that! But as of today, no. (Except that, perhaps inconsistently, within a single module, we specialise overloaded functions (including recursive ones) at the types where they are called locally. You can use a SPECIALISE pragma to make that happen for types where there is no local call.) Even non-recursive functions are inlined only if they look small enough. That can indeed lead to dictionaries being passed instead of code being duplicated. Meanwhile I'll look at the simpler example -- thanks. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad
-+--
Reporter: simonpj |Owner:
Type: run-time performance bug | Status: new
Priority: normal|Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by augustss):
I expect the code to be the same as the code for
{{{
main = do
rs - newIORef 0
ri - newIORef 0
writeIORef ri 1
let loop = do
i - readIORef ri
if i 1e3 then do
s - readIORef s
writeIORef rs (s + 1/i)
writeIORef ri (i+1)
loop
else
return ()
loop
s - readIORef rs
putStrLn $ Almost infinity is ++ show s
}}}
Because that's what the code does. Getting that far would require
specializing the recursive while function (why doesn't ghc specialize
recursive functions?).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad
-+--
Reporter: simonpj |Owner:
Type: run-time performance bug | Status: new
Priority: normal|Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by augustss):
A first thing to look at is the fact that there's still dictionaries in
the code.
There's no unresolved overloading in Inf.hs, so all dictionaries should be
gone.
To avoid the disturbing recursive while function, try this code instead:
{{{
inf = runE $ do
s - auto 0
i - auto 0
i =: 1
if1 ((i :: E m Double) = 1e3) $ do
s += 1/i
i += 1
retrn s
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad -+-- Reporter: simonpj |Owner: Type: run-time performance bug | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonpj): * cc: lenn...@augustsson.net (added) Comment: Lennart, I've taken a quick look. As you say, it generates quite a lot of code. I attach the result of -ddump-simpl for `Inf.hs` compiled with -O. There is indeed one function that return a simple constructor from a sum type, namely `+=_r1mk`. Doing the CPR transform for this would indeed be a significant improvement. But is that it? Can you point to other lost optimisations? For example, `while` is recursive so we can't inline that. I'm sure you're right that we should get good code here, but because I don't know the code, it's harder to spot what should be done that isn't getting done. Can you help? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad -+-- Reporter: simonpj |Owner: Type: run-time performance bug | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * milestone: = 6.12 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad ---+ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.1 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Lennart reports that GHC generates very poor code for his cmonad package. If you want to look at a simple example, look at the Inf.hs example included in package `cmonad-0.1.1`. It's very simple, and ghc generates fantastically bad code for it. It would be great if you could nail down why it's so amazingly unoptimal. Even with everything inlined and no overloading left, ghc seems to ignore the INLINE directives and use dictionaries left and right. When I looked at it a year ago or so, it was a return of one constructor in a sum. That is, a function always returns the same constructor, so the case analysis of the return value is not needed; it should be returned as an unboxed tuple instead Another unrelated problem, I think, is that ghc needs to promote in-memory variables to registers when possible. Perhaps the new code generator has such a transformation? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
