#2132: Optimise nested comparisons
--------------------------------------+-------------------------------------
  Reporter:  simonpj                  |          Owner:                  
      Type:  bug                      |         Status:  patch           
  Priority:  lowest                   |      Milestone:  7.6.1           
 Component:  Compiler                 |        Version:  6.8.2           
Resolution:                           |       Keywords:                  
        Os:  Unknown/Multiple         |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |     Difficulty:  Unknown         
  Testcase:                           |      Blockedby:                  
  Blocking:                           |        Related:                  
--------------------------------------+-------------------------------------
Changes (by michalt):

  * status:  new => patch


Comment:

 I think I've fixed the problem with shadowing (I've basically followed the
 approach used in CSE). Everything validates.

 However, the nofib results are not very encouraging (I've attached the
 whole
 output of ```nofib-analyse```):
 {{{
         Program           Size    Allocs   Runtime   Elapsed  TotalMem
 
--------------------------------------------------------------------------------
 ...
 
--------------------------------------------------------------------------------
             Min          -0.1%     -0.0%     -3.5%     -3.8%     -4.8%
             Max          +0.4%     +0.0%     +2.0%     +2.0%     +0.0%
  Geometric Mean          -0.0%     -0.0%     -1.0%     -1.0%     -0.1%
 }}}
 (the results are: clean GHC and ordinary nofib run vs GHC with the patch
 and
 nofib run with EXTRA_HC_OPTS=-fcomparisons).
 I've used the debugging output to see how often the optimization is
 actually
 removing some comparison: in case of GHC compile it managed to remove
 around
 1800 comparisons, in nofib only around 40. So I'm not sure this is worth
 the
 whole additional optimization. It seems that either the patch is not going
 far
 enough or there simply isn't that many opportunities for optimization...?
 If it's
 the former, then the main idea would probably be to extend the pass to be
 able
 to deal with arithmetic [1]. If it's the latter then maybe we should just
 close
 it as wontfix? What do you think?

 [1] Handling, for example things like:
 {{{
   case x <# y + 5 of
     case x <# y + 4 of
       ...
 }}}
 but this will be quite a bit more complex as we need to take into account
 integer overflows, etc.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2132#comment:25>
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

Reply via email to