On Wed, Oct 23, 2013 at 12:03 PM, Gergely Risko <gerg...@risko.hu> wrote: > On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <aus...@well-typed.com> > writes: > >> $ ghc foo.hs >> $ ghc -integer-type=gmp foo.hs >> $ ghc -integer-type=openssl foo.hs >> $ ghc -integer-type=simple foo.hs > > Well, I didn't think of this. This would indeed be very cool, > unfortunately it's quite hard if I understood you correctly. > >> As an example, libtomcrypt is damn fast, BSD3 licensed, very small, >> and well-respected. Why don't we: >> >> 1) Take libtomcrypt, modify the symbol names to be private to GHC >> (e.g. prefix everything with `ghc_integer_`) - this means the symbol >> names will be internal to GHC, so this also doesn't affect relinks >> against other copies of libtomcrypt (many projects include their own >> copy.) It is so small it basically comes under our control completely. >> >> 2) We can then offer people a integer-tomcrypt which does not have >> compatibility issues, and does not cause as much pain as the >> integration of widely deployed libraries like GMP/OpenSSL, which are >> in various use by many Haskell packages already. >> >> This should give us the flexibility of integer-simple without >> compromising so much on the efficiency aspect. >> >> This is also a very half-baked idea, but just a suggestion. I'd love a >> more modular solution to Integer as well, as I know many other people >> would. > > Just to be sure I understand the idea: do you mean linking this > ghc_integer_ prefix libtommath statically into ghc and every resulting > haskell binary, right? It makes no sense to link dynamically if the > user can't replace it with a standard libtommath anyways because of the > prefix.
Basically, yes. Well, it can also be in a dynamic shared library too (for example, a Haskell library libhsinteger-tommath.so or whatever) - but it's more important for static linking, where we do not want conflicts with other instances. In particular, tommath is used quite a bit and it's small enough people tend to just include copies of it wholesale in their project. So linking -static could actually be a problem in some cases due to this (bringing us back where we started.) The upgrading is not so much a problem, because for dynamically linked Haskell exes, you're probably unlikely to relink them against a new dynamic Haskell library (integer-tommath) anyway, without a recompile. And tommath is small enough It's more about having complete namespace control. > And do you mean shipping this libtommath GHC by default (instead of > integer-simple) and starting to develop an integer-gmp or package on > hackage? > > Gergely > I don't know. :) There are a lot of open questions here, it was just a suggestion of something that A) is not totally inefficient while B) not hurting outside integrations so much. I have no immediate opinions on whether we should gut integer-simple or anything. It seems to work for the cases people want it. At the very least, we want to see what the relative speed between the three is. I think this can be done already by writing a wrapper around tommath in Haskell, and then benchmarking between -simple, -gmp and tommath. If tommath is portable and considerably faster than -simple, then that option of gutting it can be on the table, but I see no rush to do this. The question of switching defaults from GMP to something like this also depends on the benchmarks, really. But again I see no reason to rush this, we should obviously compile some evidence to support the theory first. I should also note there is also TomsFastMath by the same author, which is basically libtommath but with optional support for inline assembly on a variety of architectures (including all the ones we support :) It also still provides a mostly compatible API - and the web page already says TomsFastMath is faster than OpenSSL on amd64 :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
