[GHC] #14980: Runtime performance regression with binary operations on vectors

[GHC]

#14980: Runtime performance regression with binary operations on vectors
-------------------------------------+-------------------------------------
        Reporter:  ttylec            |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:  vector
                                     |  bitwise operations
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 I have written a script to analyze the library selections in the 4
 different build scenarios. Cabal with GHC 8.0.2 and cabal with GHC 8.2.2
 both pull in the exact same libraries (except for `base`, obv.); so I only
 compared cabal with GHC 8.0.2 (`good1`), stack LTS 9.21 (`good2`), and
 stack LTS 11.1 (`bad`).

 I deleted `~/.stack`, and made clean builds for each of the three and
 verified that the `good` ones expose the desired behavior, and the `bad`
 one regresses. Then I listed the packages that got installed (from
 `.stack/snapshots/...` and `.cabal-sandbox/.../...packages.conf.d`), and
 compared the three lists. I threw out all the packages that met any of the
 following criteria:

 - the package is not in all 3 lists (meaning that it's not a direct
 dependency, and the difference must also be reflected in some other
 package choice)
 - the package version for the `bad` list matches one of the `good` lists
 exactly (meaning that it cannot be the culprit)

 The remaining list is this (columns giving the installed versions for the
 `good1`, `good2` and `bad` lists in this order):

 {{{
                          aeson:      1.4.0.0 |      1.1.2.0 |      1.2.4.0
                      criterion:      1.4.1.0 |      1.1.4.0 |      1.3.0.0
                      primitive:      0.6.4.0 |      0.6.2.0 |      0.6.3.0
                     scientific:      0.3.6.2 |      0.3.5.2 |      0.3.5.3
                  terminal-ansi:      0.8.0.4 |      0.6.3.1 |      0.8.0.2
 }}}

 Which is interesting, in that the `bad` versions are all between the
 `good1` and `good2` versions. So if any of these cause the badness, then
 the problem must be a regression that wasn't present in the first version,
 and has been fixed between the second and the third version.


 Another remarkable fact is that Cabal installs the exact same versions of
 all the libraries for GHC 8.0.2 and GHC 8.2.2, despite `base` versions
 being different - this could mean one of two things:

 a) Cabal fails to detect the correct version of `base` (using the system-
 wide GHC install instead of the one demanded by `--with-compiler`), so we
 end up resolving libraries for 8.0.2, and it just happens to compile
 cleanly with 8.2.2 anyway; or

 b) All the required libraries happen to have bounds on `base` that are
 compatible with both 8.0.2 and 8.2.2, so Cabal's resolver ends up
 producing the exact same solution for both compilers.

 a) would be a bug, b) would be a lucky coincidence.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14980#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler