[GHC] #10691: certain operations in new integer-gmp are too lazy

[GHC]

#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