[GHC] #10691: certain operations in new integer-gmp are too lazy
#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) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This came up in #ghc the other day. {{{ rwbarton@morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> undefined * 0 0 }}} For consistency not just with Int, but also other integer-* implementations, this should be undefined. Also affected is for example `andInteger`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 hvr): Bummer... I put quite some effort to model the `Integer` type to allow for such case-analysis for being able to avoid allocations and FFI calls in case of operations with absorbing elements... :-/ I wonder if and how `nofib` will regress if e.g. `0` doesn't shortcut anymore... However, I'd rather expect this to be fixed in the `Num` instance rather than crippling `integer-gmp` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): Replying to [comment:1 hvr]:
Bummer... I put quite some effort to model the `Integer` type to allow for such case-analysis for being able to avoid allocations and FFI calls in case of operations with absorbing elements... :-/
I wonder if and how `nofib` will regress if e.g. `0` doesn't shortcut anymore...
You can still save the work of doing a multiplication in GMP, you just have to force evaluation of the other argument when you do so. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 hvr): Replying to [comment:2 rwbarton]:
You can still save the work of doing a multiplication in GMP, you just have to force evaluation of the other argument when you do so.
I'm not sure I understand that; a multiplication with 0 would have made no sense to dispatched a call into GMP anyway, that's not the cost I'm worried about. It's rather forcing of the other argument that may trigger all sorts of potentially costly evaluations and GMP-calls only to ultimately absorb it into a `0`-result... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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 hvr): Fair enough... (but I'd still want a `nofib` delta to see if this has any noteworthy impact...) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 simonpj): I agree with Reid's points in comment:4 Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This is indeed quite surprising, and breaks my own intuition about performance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10691: certain operations in new integer-gmp are too lazy
-------------------------------------+-------------------------------------
Reporter: rwbarton | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
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 Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari
#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: 8.2.1 => 8.0.1 @@ -8,1 +8,1 @@ - For consistency not just with Int, but also other integer-* + For consistency not just with `Int`, but also other integer-* New description: This came up in #ghc the other day. {{{ rwbarton@morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> undefined * 0 0 }}} For consistency not just with `Int`, but also other integer-* implementations, this should be undefined. Also affected is for example `andInteger`. -- Comment: Perhaps we want this in 8.0 afterall. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.10.1 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as e764ede35f5c5b2c41e1670c6a9b831e0a70cd17. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10691#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC