Difference between revisions of "Building the gmp"

From ApCoCoAWiki
(add section for G5 optimized gmp)
m (grammar)
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
=Versions of the GMP=
 +
 +
We currently use the 4.2.1 release for building and testing. The 4.1.4 release still works at the moment, but we might drop support for that release soon.
 +
 
=Build Options for the GMP=
 
=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.  
+
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  
+
So when configuring the GMP make sure that you choose  
 
  --enable-alloca=no
 
  --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.
 
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=
 
=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.
+
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 gmp vs. Windows=
+
The standard GMP release (4.2.1 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 performance when going this route. The main culprit is 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 [http://fp.gladman.plus.com/computing/gmp4win.htm Building GMP and mpfr with Microsoft Visual Studio 2005] provided by Brian Gladman. Another possible source for a pre-built optimized GMP library can be found at [ftp://deltatrinity.dyndns.org/gmp-4.2.1_DLL_SharedLibs/ deltatrinity.dyndns.org] (This is release 4.2.1).  
  
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 [http://fp.gladman.plus.com/computing/gmp4win.htm 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 [ftp://deltatrinity.dyndns.org/gmp-4.1.4_DLL_SharedLibs/ deltatrinity.dyndns.org].  
+
Starting with 0.97CVS of the CoCoALib we provide a precompiled static GMP 4.2.1 for MSVC 2005 since undefined behaviour might occur if you compile and link against a different GMP on Windows. If you would like to build the CoCoALib with MSVC 2003 you are limited to the GMP release 4.1.4 since Brian Gladman's GMP release 4.2.1 no longer builds with MSVC 2003.
  
The easiest way around this whole mess is to use the MinGW tools which compile the gmp out of the box just fine.  
+
Brian Gladman makes binary builds of his GMP port available. We have set up a [http://fsmath.mathematik.uni-dortmund.de/~mabshoff/gmp-bin/4.2.1 mirror for the 4.2.1 release].
  
=gmp binding for scripting languages=
+
= The GMP vs. the Intel Math Kernel Library=
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:
+
 
 +
The Intel MKL comes with its own implementation of the GMP. So when trying to link the the CoCoALib against the GMP  as well the Intel MKL the linker fails due to mkl_ia32.a (which is 40MB) containing the some symbols twice. The solution is to go into the builder directory of the Intel MKL and create a custom dynamic lib with only BLAS and Lapack symbols. On Linux do:
 +
 
 +
cat blas_list lapack_list > user_list
 +
make ia32 name=libmklspecial.so export=user_list
 +
 
 +
Now you can link against that library with '''-lmklspecial'''.
 +
 
 +
You have to do something analog on Windows as well as MacOSX if you would like to use the Intel MKL.
 +
 
 +
=GMP binding for scripting languages=
 +
If you like to use the CoCoA Library from your favourite scripting language, i.e. if you need to write bindings, you also need access to the built-in native GMP data structures. To make things easy for you we provide links for certain scripting languages:
 
# [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
  
 +
=Better Assembly support for GMP on AMD64=
 +
 +
The 4.2.x release of the GMP provides basic assembly support for Opterons. There are plans for improved assembly code in the next major GMP release. Until then you might check out [http://www.loria.fr/~gaudry/mpn_AMD64/index.html Pierrick Gaudry's webpage] for patch set improving performance over vanilla 4.2.x. It increases the gmpbench score from roughly 8200 on a 2.4 GHz Opteron to about 10.000.
  
=Better Assembly support for GMP on AMD64=
+
=Better Assembly support for GMP on Apple's G5=
  
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.
+
There are patches that provide some faster routines especially for Apple's G5. The patches can be found in the [http://swox.com/list-archives/gmp-devel/2006-March/000613.html gmp-devel archive]. They have been tested with the 4.1.4 and the 4.2 pre-release.
  
 +
=Better Assembly support for GMP on Intel's Core Duo=
  
=Better Assembly support for GMP on Apple's G5=
+
Check out [http://www.math.jmu.edu/~martin/ Jason Martin's homepage] for a patch for Mac OSX and Linux. Support for Windows doesn't exist yet, but might be coming in the future. This patch set also allows one to build a static version of the GMP, which is currently not possible with 4.2.x on MacIntel.
  
There are patches that provide some faster routines especially for Apple's G5. The patches can be found in the [http://swox.com/list-archives/gmp-devel/2006-March/000613.html gmp-devel archive]. They have been tested with the 4.1.4 and the 4.2 prerelease.
+
=Patch to build a static MacIntel GMP 4.2.1=
 +
In order to compile a static 32 bit version for MacIntel you need to apply [http://fsmath.mathematik.uni-dortmund.de/~mabshoff/patches/gmp-4.2.1-static-IntelMac.patch a patch]. The patch was originally written by Alex Martelli, have a look at [http://gmplib.org/list-archives/gmp-bugs/2006-April/000317.html the gmp-bugs mailing list] for more details.

Latest revision as of 11:06, 26 April 2007

Versions of the GMP

We currently use the 4.2.1 release for building and testing. The 4.1.4 release still works at the moment, but we might drop support for that release soon.

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.2.1 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 performance when going this route. The main culprit is 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 pre-built optimized GMP library can be found at deltatrinity.dyndns.org (This is release 4.2.1).

Starting with 0.97CVS of the CoCoALib we provide a precompiled static GMP 4.2.1 for MSVC 2005 since undefined behaviour might occur if you compile and link against a different GMP on Windows. If you would like to build the CoCoALib with MSVC 2003 you are limited to the GMP release 4.1.4 since Brian Gladman's GMP release 4.2.1 no longer builds with MSVC 2003.

Brian Gladman makes binary builds of his GMP port available. We have set up a mirror for the 4.2.1 release.

The GMP vs. the Intel Math Kernel Library

The Intel MKL comes with its own implementation of the GMP. So when trying to link the the CoCoALib against the GMP as well the Intel MKL the linker fails due to mkl_ia32.a (which is 40MB) containing the some symbols twice. The solution is to go into the builder directory of the Intel MKL and create a custom dynamic lib with only BLAS and Lapack symbols. On Linux do:

cat blas_list lapack_list > user_list
make ia32 name=libmklspecial.so export=user_list

Now you can link against that library with -lmklspecial.

You have to do something analog on Windows as well as MacOSX if you would like to use the Intel MKL.

GMP binding for scripting languages

If you like to use the CoCoA Library from your favourite scripting language, i.e. if you need to write bindings, you also need access to the built-in 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

Better Assembly support for GMP on AMD64

The 4.2.x release of the GMP provides basic assembly support for Opterons. There are plans for improved assembly code in the next major GMP release. Until then you might check out Pierrick Gaudry's webpage for patch set improving performance over vanilla 4.2.x. It increases the gmpbench score from roughly 8200 on a 2.4 GHz Opteron to about 10.000.

Better Assembly support for GMP on Apple's G5

There are patches that provide some faster routines especially for Apple's G5. The patches can be found in the gmp-devel archive. They have been tested with the 4.1.4 and the 4.2 pre-release.

Better Assembly support for GMP on Intel's Core Duo

Check out Jason Martin's homepage for a patch for Mac OSX and Linux. Support for Windows doesn't exist yet, but might be coming in the future. This patch set also allows one to build a static version of the GMP, which is currently not possible with 4.2.x on MacIntel.

Patch to build a static MacIntel GMP 4.2.1

In order to compile a static 32 bit version for MacIntel you need to apply a patch. The patch was originally written by Alex Martelli, have a look at the gmp-bugs mailing list for more details.