#915: Implement list fusion using streams instead of foldr/build
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: task | Status: new
Priority: low | Milestone: 7.2.1
Component: libraries/base | Version: 6.8
Keywords: fusion | Testcase: N/A
Blockedby: | Difficulty: Project (more than a week)
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by Blaisorblade):
Replying to [comment:22 batterseapower]:
> AFAIK this ticket is no closer to being practical now that when dons
added that comment 18 months ago.[...]
> However, it is still the case that noone knows how to implement concat /
concatMap efficiently and without improving GHCs Core optimisers.[...]
> An alternative to coming up with a clever library modification would be
to improve GHCs optimiser.
> [...I]t is upsetting that stream fusion requires so much more work on
the part of the optimiser to get right, compared to the fairly simply
rewrite rule story with foldr/build.
I wanted to focus on this part of the comment, which is about whether you
actually want to merge the code. If this is agreed upon, then one needs to
find somebody willing to finish the job, but that's easier with an
agreement.
The paper argues (or claims) that the improved optimization is generally
useful and not specific to stream fusion. Do you disagree? Is the code
exceedingly ugly? Would you be ready to publish it somewhere? Are there
any benchmark results from applying the optimization alone, compared with
the standard optimizer? The paper mentions shortly that usually improves
nofib performance slightly.
I also wonder: is sometimes the SAT transformation done by hand by
programmers for performance?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/915#comment:31>
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
