[Haskell-cafe] foreign import and gmp

Thomas DuBuisson thomas.dubuisson at gmail.com
Thu Aug 9 00:49:57 CEST 2012


On Wed, Aug 8, 2012 at 3:24 PM, Lars Kuhtz <haskell at kuhtz.eu> wrote:
> On 8/8/12 2:55 PM, Thomas DuBuisson wrote:
>> You need to build GHC using the integer-simple library (instead of the
>> 'integer-gmp' library).  From the 6.12.1 release notes:
>>
>> """
>> It is now possible to build GHC with a simple, BSD-licensed Haskell
>> implementation of Integer, instead of the implementation on top of
>> GMP. To do so, set INTEGER_LIBRARY to integer-simple in mk/build.mk.
>> """
>
> How to I build the Haskell platform in this case? Is it enough to just
> use a GHC that was build with INTEGER_LIBRARY=integer-simple in the
> build of the platform, or do I need to somehow configure the platform
> build to prevent packages from importing integer-gmp?

I don't understand this question largely because I don't understand
the need to consider an entity called "the Haskell Platform".  You can
build and install individual libraries.  Some of those libraries will
not build and install the trivial way (cabal install BLAH) but will
build and install when given a flag (cabal install -f integer-simple
BLAH).  I hope (but have not put in any effort) for the HP community
to push for a single solution that includes tivial compile-time
detection of the integer support, thus making flags unnecessary.

>
>> In addition, some libraries depend on integer-gmp (sadly).  This is
>> usually part of an optimization and when I see it I tend to send in a
>> patch adding an "integer-simple" flag so you can cabal install it by
>> including "-finteger-simple" on the command line (text is an example
>> of one such library).
>
> Does this mean that text does already support this flag?

Yes: http://hackage.haskell.org/packages/archive/text/0.11.2.2/text.cabal

>
>> And that's it!  Your integer operations will run slower but you should
>> get stable operation even when using the GMP library.
>
> What about operations on Integers with small values? Are they still
> efficient, i.e. directly mapped to operations on native int?

For that you'll have to look at the integer-simple package, perform
some benchmarks, or wait another five minutes for someone besides me
to answer.  Even small Int's are represented via a slightly more
involved ADT so I expect there will be more pointers and measurably
more overhead.

Cheers,
Thomas



More information about the Haskell-Cafe mailing list