Why do we put GMP allocations on GHC heaps?

[Gergely Risko]

On Tue, 22 Oct 2013 21:29:48 -0400, Carter Schonwald <carter.schonwald at gmail.com> writes:

> At some point I'd actually like to explore trying to build a
> satisfactory "integer-fancy" in Haskell, but there's a few technical
> challenges I'll be trying to do first before there'll be an
> engineering story for building a satisfactory Haskell replacement that
> is performant enough to justify dropping Gmp
>
> Basically I think until we can build an alternative with competitive
> performance in straight ghc Haskell, there's no good argument for
> dropping Gmp overall. There are a number of great reasons that
> everyone has mentioned, but it needs to be a net win for everyone
> before the leap could be justifiable. 

I see how clear and nice would a straight haskell implementation would
be.  But do we actually have any chance to be close to GMP or other C
based bignum libraries?  I mean they're in development for years and
probably has a lot of knowledge burnt into them, no?

I consider the following situation already a net win:
  - same performance as now,
  - statically linked, so ldd'ing ghc or a compiled program doesn't show
    gmp, openssl or any other library.  Currently the ldding output of a
    simple haskell binary contains libc + libgmp.  libc is very
    backwards compatible, but gmp causes issues, getting rid of it is
    a win for me,
  - possibility to build Ekmett's MPFR binding.

Do you consider the stability benefit of working status quo stronger
than the ones above?

> If I manage to get my target work for 7.10 sorted out with a few
> months to spare, I may try to spend a few months exploring this,
> though no promises. Current ghc doesn't have the right primops to do
> this yet.

Can you please elaborate on this?  What primops are needed for a pure
haskell solution?

Thanks,
Gergely