Why do we put GMP allocations on GHC heaps?

[Austin Seipp]

On Wed, Oct 23, 2013 at 12:03 PM, Gergely Risko <gergely at risko.hu> wrote:
> On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <austin at well-typed.com> writes:
>
>> $ ghc foo.hs
>> $ ghc -integer-type=gmp foo.hs
>> $ ghc -integer-type=openssl foo.hs
>> $ ghc -integer-type=simple foo.hs
>
> Well, I didn't think of this.  This would indeed be very cool,
> unfortunately it's quite hard if I understood you correctly.
>
>> As an example, libtomcrypt is damn fast, BSD3 licensed, very small,
>> and well-respected. Why don't we:
>>
>> 1) Take libtomcrypt, modify the symbol names to be private to GHC
>> (e.g. prefix everything with `ghc_integer_`) - this means the symbol
>> names will be internal to GHC, so this also doesn't affect relinks
>> against other copies of libtomcrypt (many projects include their own
>> copy.) It is so small it basically comes under our control completely.
>>
>> 2) We can then offer people a integer-tomcrypt which does not have
>> compatibility issues, and does not cause as much pain as the
>> integration of widely deployed libraries like GMP/OpenSSL, which are
>> in various use by many Haskell packages already.
>>
>> This should give us the flexibility of integer-simple without
>> compromising so much on the efficiency aspect.
>>
>> This is also a very half-baked idea, but just a suggestion. I'd love a
>> more modular solution to Integer as well, as I know many other people
>> would.
>
> Just to be sure I understand the idea: do you mean linking this
> ghc_integer_ prefix libtommath statically into ghc and every resulting
> haskell binary, right?  It makes no sense to link dynamically if the
> user can't replace it with a standard libtommath anyways because of the
> prefix.

Basically, yes. Well, it can also be in a dynamic shared library too
(for example, a Haskell library libhsinteger-tommath.so or whatever) -
but it's more important for static linking, where we do not want
conflicts with other instances. In particular, tommath is used quite a
bit and it's small enough people tend to just include copies of it
wholesale in their project. So linking -static could actually be a
problem in some cases due to this (bringing us back where we started.)

The upgrading is not so much a problem, because for dynamically linked
Haskell exes, you're probably unlikely to relink them against a new
dynamic Haskell library (integer-tommath) anyway, without a recompile.
And tommath is small enough It's more about having complete namespace
control.

> And do you mean shipping this libtommath GHC by default (instead of
> integer-simple) and starting to develop an integer-gmp or package on
> hackage?
>
> Gergely
>

I don't know. :) There are a lot of open questions here, it was just a
suggestion of something that A) is not totally inefficient while B)
not hurting outside integrations so much.

I have no immediate opinions on whether we should gut integer-simple
or anything. It seems to work for the cases people want it.

At the very least, we want to see what the relative speed between the
three is. I think this can be done already by writing a wrapper around
tommath in Haskell, and then benchmarking between -simple, -gmp and
tommath. If tommath is portable and considerably faster than -simple,
then that option of gutting it can be on the table, but I see no rush
to do this.

The question of switching defaults from GMP to something like this
also depends on the benchmarks, really. But again I see no reason to
rush this, we should obviously compile some evidence to support the
theory first.

I should also note there is also TomsFastMath by the same author,
which is basically libtommath but with optional support for inline
assembly on a variety of architectures (including all the ones we
support :) It also still provides a mostly compatible API - and the
web page already says TomsFastMath is faster than OpenSSL on amd64 :)

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/