#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