#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): On the other hand - Making `(*)` strict means the strictness analyser can prevent some cases of thunk build-up when the accumulated expression is going to be multiplied by a variable. Most of the time the value that is in the lazy argument position of `(*)` really will be needed, and much of the rest of the time (when the integers involved are small) computing it will be cheaper than building the thunks anyways. It's quite possible that there will be speed-ups in nofib from a strict `(*)` as well as slow-downs. - There are two different ways to make a `(*)` that is lazy when one argument is zero (it can't be lazy on both sides), and the one currently chosen in integer-gmp is not documented, nor is it consistent between different operations (`undefined * 0 = 0`, but `0 .&. undefined = 0`). - It's easy and cheap to turn any of the three versions (strict in both arguments, lazy in first argument, lazy in second argument) into any other, so I don't think there is much value in providing more than one. None is strictly superior or inferior to the others in terms of performance, and the version that is strict in both arguments is clearly the least surprising choice for several reasons. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler