On Wed, Oct 23, 2013 at 12:03 PM, Gergely Risko wrote:

On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp 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/