Gergely Edward has it right. Functional programs allocate a lot of intermediate stuff. ((a+b)*c-d) allocates two intermediate Integers and discards them pretty soon afterwards. GHC's code generator and garbage collector are good at both allocation and gc of young dead objects. Using malloc/free would require a finaliser-style interface, which is significantly less efficient. That might matter a lot for an arithmetic-intensive program, and not at all for one where Integer arithmetic was incidental. However, you could perfectly well imagine a third package (alongside integer-gmp and integer-simpl), let's call it integer-gmp-malloc. This would use the malloc/free interface, with finalisers to free space when no longer referenced from the GHC heap. It might be faster than integer-simple, and more inter-operable than integer-gmp. Also, freeing us from the GPL constraints of GMP, while offering better performance than integer-simple, would be great. See also http://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Please do record the information or insights you get on a GHC wiki page! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Gergely Risko | Sent: 22 October 2013 22:45 | To: ghc-devs@haskell.org | Subject: Why do we put GMP allocations on GHC heaps? | | Dear GHC gurus, | | I've been looking into how GHC uses GMP (with the hidden agenda of | taking the work of replacing it with something that is BSD license | compatible and so can be linked in and shipped statically by default). | | I think I more or less understand how GMP memory is managed and how the | GC works together with it. Actually understanding the "how" was not | that hard, everything is quite clearly commented. | | What I couldn't find any reference for is the "why". Why does GHC do | this? Would it be possible to just not do this and let GMP malloc and | free for itself (obviously we would have to call mpz_free here and | there, but that seems doable). | | I have multiple ideas, but don't know which one (if any) is correct: | - performance reasons, | - memory defragmentation reasons, | - GHC GC moves around stuff and that would somehow break, | - the previous one + threads + race conditions. | | Second question: let's assume for a moment that we don't have any | licensing issues with a GMP like library, can be linked statically into | GHC, but we decide to go with the same allocation methodology as with | GMP. Am I right when I think that linking statically solves the | technical issues too. | | 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? | | Third question: is replacing with openssl bn an acceptable path to | you guys? I saw that 6 years ago there were work on getting | integer-simple performance wise good enough to be the default and then | adding other bignum libraries externally, but none of this happened. | I see how sexy project it is computer science wise to write a bignum | library in Haskell, but will we really do it? | | Thanks, | Gergely | (errge) | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs