Replacement for GMP: Update
Peter Tanski
p.tanski at gmail.com
Thu Aug 10 01:31:44 EDT 2006
Simon PJ, Simon, Esa and John,
Here is an update on what I have been doing so far in making a grand
attempt to replace GMP.
(1) evaluate replacement libraries
LibTomMath:
Pros-
* has all the operators GMP offered
Cons-
* slow; about half as fast as OpenSSL in my tests for simple
mathematical operations, much slower if you account for time to
write or resize memory. (There is another MP library, which
LibTomMath is based on, that is also very slow--student work)
* not even reentrant; needs significant modification
* beta-release; needs a bit of work to get it to production level
* configuration needs to be written (not really portable, messy)
ARPREC:
Pros-
* very fast (essentially does everything through the
Floating Point Unit of a CPU)
* complex mathematical operations
* very precise
* already thread safe (through C++ thread-safe statics)
Cons-
* no bitwise operations (not even left and right-shifts)
* difficult configuration (everything runs by setting a precision
level;
("precision level" ~= number of words (doubles) in array)
it does not automatically resize memory; conversion from
MP Real to Integer relies specially on careful precision-level)
* memory inefficient (underestimates the number of real digits you
can fit into a double, i.e., a 64-bit double has 48 bits of
precision,
holding about 9.6 digits per byte, resulting in an 848-byte array
to hold an MP number with 1000 digits).
OpenSSL:
Crypto++ (http://www.eskimo.com/~weidai/cryptlib.html):
Botan (http://botan.randombit.net/):
Pros-
* all of these are fast, since all use Integers to support
cryptography;
(Crypto++ and Botan are C++ crypto-libraries, all licenses good)
* all of these provide most basic mathematical operations
Cons-
* none of these provide &, |, ^(xor) bitwise operators
* Botan has least mathematical operators of the three
* none provide lcm operator
* all would realistically have to have the Integer libraries stripped
out of the distribution and repackaged for GHC
Summary: I finally settled on modifying OpenSSL, since that would be
the easiest to work with under GHC's hood (plain C code, not C++). I
have to:
a. make OpenSSL's BN thread-safe (add thread local storage, at least)
b. optimally add configure-conditional parallelism to BN (through PVM)
c. add &, |, ^, lcm and a few other operations
d. separate the BN from the rest of OpenSSL and rename the symbols
to avoid conflicts (necessary because I have to modify the library
anyway)
(2) work on GHC:
* finally understand C--; know what I need to modify
* work through Makefiles: touch and go; I haven't mapped out all the
variable settings from configure.in on down when it comes to DLLs
Comment:
for the Makefile in ghc/rts, in lines 300-346,
GC_HC_OPTS += -optc-O3
--isn't this problematic? gcc, from -O2 on includes -fgcse which may
*reduce* runtime performance in programs using computed gotos;
-fgcse is actually run twice, because -frerun-cse-after-loop is also
set at -O2. Would it be better to pass individual flags, such as
-funroll-loops and -falign-loops=16 (ppc, Intel setting)?
(3) I have been looking at how to implement a dual-constructor-in-a-
pointer for Integer (i.e., merge constructors of small Integers and
big Integers into the Int#). Would that solution be workable or
might it break current Haskell programs? Just a thought.
-Peter
More information about the Glasgow-haskell-users
mailing list