Re: CLN, GMP inputs

[Hans Aberg]

One thing I forgot to say about GHC is that once it has detected a small
number overflow, it changes to large numbers, and does not change back to
the small number representation again. So if one has a single large
intermediate number, followed by small numbers, then that single large
number will slow down all subsequent computations.

So I think that this speaks for adding a small number representation to
GMP, because one can then make sure that one moves back into small number
representations whenever possible.

Also, my guess is that the GHC overflow checks are pretty time consuming.
Here is a quote from Marcin 'Qrczak' Kowalczyk <address@hidden> (S# =
small number, J# = large number):

>Ghc's primops use a restriced set of types
>and rarely allocate memory themselves. For example plusInteger#
>has the type
>    Int# -> ByteArr# -> Int# -> ByteArr# -> (# Int#, ByteArr# #)
>where (# x, y #) means to return both values on the stack.
>It is wrapped for integer addition thus:
>
>plusInteger :: Inteter -> Integer -> Integer
>plusInteger i1@(S# i) i2@(S# j)  = case addIntC# i j of { (# r, c #) ->
>                                   if c ==# 0# then S# r
>                                   else toBig i1 + toBig i2 }
>plusInteger i1@(J# _ _) i2@(S# _) = i1 + toBig i2
>plusInteger i1@(S# _) i2@(J# _ _) = toBig i1 + i2
>plusInteger (J# s1 d1) (J# s2 d2) = case plusInteger# s1 d1 s2 d2 of
>    (# s, d #) -> J# s d
>
>Returning one of two variants from a primop requires expressing it
>similarly to a C struct, without type punning. So it could be this:
>    plusInteger# :: Int# -> ByteArr#
>                 -> Int# -> ByteArr#
>                 -> (# Int#, Int#, ByteArr# #)
>plusInteger (J# s1 d1) (J# s2 d2) = case plusInteger# s1 d1 s2 d2 of
>    (# 0#, i, _ #) -> S# i
>    (# _,  s, d #) -> J# s d

So it seems me that it would be more efficent doing that stuff in the lower
level that GMP works with.

  Hans Aberg