Difference between revisions of "Building the gmp"

From ApCoCoAWiki
(→‎gmp binding for scripting languages: add link to python bindings for the gmp)
(add Assembly support for GMP on AMD64)
Line 20: Line 20:
 
# [http://cvs.savannah.gnu.org/viewcvs/dotgnu-libs/GMP-Sharp/ C# bindings] from the DOTGnu project.
 
# [http://cvs.savannah.gnu.org/viewcvs/dotgnu-libs/GMP-Sharp/ C# bindings] from the DOTGnu project.
 
# [http://www.egenix.com/files/python/mxNumber.html mxNumber] and [http://gmpy.sourceforge.net/ gmpy] for python
 
# [http://www.egenix.com/files/python/mxNumber.html mxNumber] and [http://gmpy.sourceforge.net/ gmpy] for python
 +
 +
 +
=Assembly support for GMP on AMD64=
 +
 +
The 4.1 release of the gmp doesn't provide assembly support for Opterons, hence performace is not as good as it could be. There are plans for better support on Opteron  in the next major gmp release. Until then you might check out [http://www.lix.polytechnique.fr/Labo/Pierrick.Gaudry/mpn_AMD64/ this webpage] by Pierrick Gaudry for a special Opteron build.

Revision as of 12:27, 14 March 2006

Build Options for the GMP

There are many different possible configurations when building the gmp. One that is very important to CoCoA is how to allocate memory in the gmp since large numbers can overflow the stack quite easily. For a general overview for the gmp 4.1 have a look at http://www.gnu.org/software/gmp/manual/html_node/Build-Options.html.

So when configuring the gmp make sure that you choose

--enable-alloca=no

in order to use malloc and thereby using the heap instead of the stack. This entails a small (roughly 2% or so) performance penalty but at least your computation finishes instead of segfaulting for mysterious reasons.

Possible Workaround for Stack Size Issue

If you cannot recompile your gmp a workaround is to set your stack to unlimited or a larger value than you are currently using. This should be possible on most Linux/Unix systems. It actually depends on you installation whether there are hard limits or not. For more details check out man limit or man ulimit depending on the shell you are using or check with your friendly system administrator. On MacOSX 10.4 and higher the stack size is limited to 64 MB and you need root privileges to change that. On Windows we are currently not aware of a possibilty of changing stack size during runtime. One can set the size of the stack a binary uses during compile time.

The gmp vs. Windows

The standard gmp release (4.1.4 at the moment) does not compile on Windows when using the Microsoft Visual Studio compiler. While it is technically possible the build the non-optimized C version of the gmp it is only a stop gap measure since one looses lots of performace when going this route. The main culprit the gas style assembly syntax in the gmp. One way around this is to use nasm style assembly syntax. A complete Visual Studio project to build an optimized gmp can be found on Building GMP and MPFR with Microsoft Visual Studio 2005 provided by Brian Gladman. Another possible source for a prebuild optimized gmp library can be found at deltatrinity.dyndns.org.

The easiest way around this whole mess is to use the MinGW tools which compile the gmp out of the box just fine.

gmp binding for scripting languages

If you like to use the CoCoA Library from your fourite scripting language, i.e. if you need to write bindings, you also need access to the buildin native gmp data structures. To make things easy for you we provide links for certain scripting languages:

  1. C# bindings from the DOTGnu project.
  2. mxNumber and gmpy for python


Assembly support for GMP on AMD64

The 4.1 release of the gmp doesn't provide assembly support for Opterons, hence performace is not as good as it could be. There are plans for better support on Opteron in the next major gmp release. Until then you might check out this webpage by Pierrick Gaudry for a special Opteron build.