Hi Dan, On Friday 04 Mar 2011 21:59:12 Daniel Peebles wrote: > I'm adding Ed to the conversation as he's very interested in this topic, > too.
I do apologise - I was meant to post the previous email back to haskell-cafe but by mistake it went only to you. I hope you do not mind that I am taking the discussion back to the cafe. I attach my email so that other readers of the cafe can see it. > The experts were right about it being impossible to work with GHC's > GMP – until recently. "foreign import c" calls are indeed going to call GC > when you don't want it, but when they split integer-gmp out of GHC's own > RTS, Duncan Coutts (one of those experts) added the "foreign import prim" > construct so that he could do exactly what you want, and operate on GMP > integers with GHC-allocated memory without worrying about temporary > storage blowing up while you aren't looking. > > So in general, I'd lean more towards replacing all your ccall bindings to > MPFR with cmm bindings. It does require some GHC internals knowledge but > is fairly mechanical, and would solve all the problems, without requiring > a rewrite of GMP (that would be slower anyway). > > Ed is actually going to get started on a fairly simple binding to a subset > of MPFR for one of his projects, using the CMM approach based on the > structure of my natural-gmp package > (https://github.com/pumpkin/natural-gmp, which is itself based heavily on > integer-gmp, but reworked to work fine from cabal rather than depending on > GHC's build process). Once he is done with that, you might want to refer > to his implementation to make your more complete MPFR binding work with > integer-gmp (and thus make no speed sacrifices). If this is the best approach, I would welcome help with this as I will not have much time to work on it until the summer due to teaching commitments and the need to publish work done earlier. > I would also like a gmp-compatible replacement, but it's going to > necessarily be slower and would prefer to be able to have fast > computations over floating-point numbers AND integers/naturals. Eek, I made a mistake, I apologise again - the proposal I was quoting in the announcement is not what I had in mind. I was meant to refer to a mention by igloo at the very end of http://hackage.haskell.org/trac/ghc/ticket/311 which is a very different proposal from the one I linked to and the one you seem to refer to here. I was not at all thinking of writing a gmp compatible replacement. I was thinking of taking gmp sources and mechanically modify the exported names and modify integer-gmp to use those modified names. Thus there would be no difference in the speed of Integer as it would still use an exact clone of the original gmp in exactly the same way as now but not interfere with what the usual gmp code does via other libraries. Please correct me if I this approach is not feasible or if there is some advantage in using cmm over this proposal that I am missing. Michal -- |o| Michal Konecny <[email protected]> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
--- Begin Message ---Hello Dan, Thank your for your suggestions. I implemented the dependency on integer-simple because I need hmpfr to work in the short term. In the long term, I would like to adopt a better approach. At the moment I do not know enough about ghc internals to be able to determine the approach, so I welcome your pointers. I know that Aleš, who knows more about the ghc internals, has tried various things but could not make hmpfr work with the current integer-gmp. I did not file a bug because there was a similar ghc ticket open for quite some time (#601) and it has been closed when it became possible to use integer-simple instead of integer-gmp. That is why I felt that the best solution to the problem at present is to use integer-simple. I am not an expert but based on what I read experts say on the topic I concluded that it is close-to-impossible to make ghc+integer-gmp work with libraries such as mpfr that heavily use gmp. Of the suggested solutions we are aware of, the one that seems to me and Aleš most promising is to create a clone of gmp that differs from the original only in the names of all exported symbols and distribute it as a part of ghc to be dynamically linked with all executables produced by ghc. The clone could be produced using a script to allow easy updates with new versions of gmp. I would be interested whether someone has been trying or has plans to try to implement this approach. The reason why I like this approach than writing cmm wrappers around MPFR and prim importing them is that it is more maintainable and also opens the way for other libraries that depend on gmp to work with ghc. Michal On Friday 04 Mar 2011 20:27:10 you wrote: > According to Duncan Coutts (whom I asked about this issue in #ghc), the > solution here is to use the new foreign import prim machinery to talk to > MPFR. This prevents GC from occurring during the MPFR calls and will make > everything work nicely without reimplementing GMP. > > Dan > > On Fri, Mar 4, 2011 at 3:09 PM, Daniel Peebles <[email protected]> > wrote: Have you submitted a bug report to GHC of why it can't work with > the current integer-gmp binding? I know that GHC's collector is collecting > MPFR's temporary data, but maybe it'd be good to get a discussion going on > what can be done to stop it from doing this even in the context of the > existing integer-gmp + GHC's allocator (even if this needs to be a patch > to MPFR to talk to GHC a bit here and there). Might it help to go through > CMM like the GMP binding does, for example? > > I'd really like to see libraries that use GMP work nicely with GHC, without > going and reimplementing GMP more slowly and so on. -- |o| Michal Konecny <[email protected]> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
