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. 

 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. 

On Tuesday, October 22, 2013, Edward Kmett wrote:
Not suggesting we actually switch, but there is one strong 'why': You can't link Haskell code with any library that uses GMP internally internally without switching to using integer-simple. I've been trying with very limited success to get good MPFR bindings for Haskell for ~3 years now as a result.

The most likely fix actually involves changes to MPFR as their constant cache and our garbage collector don't play nice.


On Tue, Oct 22, 2013 at 7:36 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
Hey Gergeley,

> (obviously we would have to call mpz_free here and there, but that
> seems doable).

Actually, this is precisely the problem.  When is a GMP integer freed?
It can have pointers to it from objects on the heap, so this free should
only occur when the integer is dead, with no references from the heap.
How can that be arranged?  Well, the garbage collector is responsible
for figuring this out.  So why shouldn't they just live on the heap, and
then smoothly integrate with the existing garbage collector.

The alternate strategy is to arrange that some sort of "callback" gets
invoked when an object dies.  You can achieve this using our finalizer
support, but you pay an efficiency penalty and cannot guarantee that
the integers will get freed in a timely manner at all.

> More concretely: openssl BN uses the openssl_malloc function can only be
> overridden openssl wide.  But if we link statically, than this override
> won't affect external openssl library bindings, because the openssl
> symbols in our object files won't even be exported, right?

Only if literally two copies of OpenSSL are linked.  This seems unlikely to
work the way you want it to.

Cheers,
Edward
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs