#149: missed CSE opportunity
--------------------------------------+-------------------------------------
Reporter: nobody | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone: 6.8 branch
Component: Compiler | Version: 5.04.2
Severity: minor | Resolution: None
Keywords: optimisations | Difficulty: Moderate (1 day)
Testcase: simplrun006 | Architecture: Unknown
Os: Unknown |
--------------------------------------+-------------------------------------
Changes (by simonmar):
* priority: high => normal
* difficulty: Unknown => Moderate (1 day)
* severity: normal => minor
* milestone: 6.8.3 => 6.8 branch
Old description:
> {{{
> Don't know if this is a bug, but it was at least
> _surprising_ to find that
>
> playerMostOccur [a] = a
> playerMostOccur (x:xs)| numOccur x (x:xs)
> >
> numOccur
> (playerMostOccur xs) xs
> = x
> | otherwise =
> playerMostOccur xs
>
> was exponentially slower when compiled with ghc-5.04.2
> -O than:
>
> playerMostOccur [a] = a
> playerMostOccur (x:xs)| numOccur x (x:xs)
> >
> numOccur pmo xs
> = x
> | otherwise = pmo
> where pmo =
> playerMostOccur xs
>
> Although the student responsible for the code couldn't
> spot the
> obvious optimisation, I was expecting that GHC's
> optimiser would. :)
> If it's not a bug, could you explain it to me?
>
> -Greg(gregm.at.cs.uwa.edu.au)
> }}}
New description:
Don't know if this is a bug, but it was at least
_surprising_ to find that
{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x
| otherwise = playerMostOccur xs
}}}
was exponentially slower when compiled with ghc-5.04.2
-O than:
{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur pmo xs = x
| otherwise = pmo
where pmo = playerMostOccur xs
}}}
Although the student responsible for the code couldn't
spot the
obvious optimisation, I was expecting that GHC's
optimiser would. :)
If it's not a bug, could you explain it to me?
-Greg(gregm.at.cs.uwa.edu.au)
Comment:
The problem seems to be that Float Out isn't floating out the let
expression in the guard, whereas presumably it used to. The let can't be
floated out past a lambda, but nevertheless floating it would reveal an
opportunity for CSE.
Plan: try floating out ''all'' lets, even if they can't move past a
lambda, and measure the difference on nofib.
Not urgent enough for 6.8.3.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/149#comment:9>
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
