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 > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > 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 >> [email protected] <javascript:_e({}, 'cvml', '[email protected]');> >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
