#2465: View + Pattern Match not fused sufficiently
------------------------------------------+---------------------------------
Reporter: ryani | Owner:
Type: compile-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows |
------------------------------------------+---------------------------------
Comment (by ryani):
I intentionally put the most pie-in-the-sky example in my bug; I realize
this is a hard problem. The code I actually used, which still didn't get
any fusion, only examined a small finite amount of the result of dnaView,
following it by a recursive call to "consts'" using (dnaDrop n dna). In
the "secrets of the GHC inliner" paper, I seem to recall reading that loop
unrolling is just inlining of recursive functions, so I'd hope that
dnaView gets loop-unrolled 2 or 3 times which would solve that problem.
That said, I do think it's possible to get from "consts + dnaView" (code
which I feel is beautiful & slow) to "optConsts" (which is ugly, hand-
optimized code to match what I would like the compiler to generate for
this case).
So, some thoughts...
Is there a better way to write recursive functions that allows GHC to
inline them better? I've seen several examples of this format:
{{{func a b c = go a b c where
go Something = base case
go SomethingElse = combiner (SomeResult) (go RestOfData)}}}
If that really helps, it seems like a trivial transformation to do to
simple recursive functions at compile-time.
I can experiment with a few different constructions of the program, but my
point is that this is what most users would write as the direct
specification -> implementation of this problem, the performance is pretty
bad, and the "right" answer seems tantalizingly close.
When the optimizer is good, it's amazingly good, but when it goes wrong it
looks so much worse by comparison. There isn't much of a "graceful
falloff" in performance, you either get blazing fast or bad.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2465#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
