#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): Even more strangely, I am now getting 8.0.2-like results using 8.2.2: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 417.9 μs (417.5 μs .. 418.3 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 418.3 μs (417.8 μs .. 419.6 μs) std dev 2.364 μs (827.2 ns .. 4.744 μs) benchmarking 64 columns/binary packed time 22.95 μs (22.90 μs .. 23.01 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 22.94 μs (22.91 μs .. 22.97 μs) std dev 105.9 ns (75.87 ns .. 146.9 ns) benchmarking 256 columns/raw unbox vectors time 432.7 μs (422.4 μs .. 443.9 μs) 0.997 R² (0.995 R² .. 0.999 R²) mean 423.4 μs (420.3 μs .. 428.6 μs) std dev 13.41 μs (7.712 μs .. 19.14 μs) variance introduced by outliers: 25% (moderately inflated) benchmarking 256 columns/binary packed time 29.75 μs (29.51 μs .. 30.16 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 29.64 μs (29.57 μs .. 29.86 μs) std dev 395.1 ns (120.1 ns .. 801.2 ns) }}} I'm starting to suspect that the decisive factor here is not GHC itself, but rather something else. Quite possibly, library versions play a role - the cabal builds for 8.0.2 and 8.2.2 use the same versions for all libraries (except base), while the stack builds differ in a few of them. Another possible explanation could be that while I'm forcing the compiler itself when compiling with cabal (`--with-compiler` / `--with-ghc`), I am not doing the same for any of the other tools cabal may be using, and those might not resolve in a compiler-specific way but rather just use whatever is installed system-wide (which happens to be from GHC 8.0.2 right now, but was 8.4.2 when I first started profiling). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14980#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler