This is a patch to solve two problems:
1. It makes gmp run faster on Intel Core2 CPUs (i.e. Woodcrest, Conroe,
and friends) under Linux
2. It makes gmp work (and run fast) under Mac OS X on Core2 CPU
machines (e.g. Mac Pro)
As an added bonus, it actually gives a little speed up to gmp on AMD64
machines as well.
To Install on a 64 bit Intel Mac (e.g. Mac Pro)
-------------------------------------------------------
1. Download gmp-4.2.1-core2-port.tar.gz
2. Uncompress and untar it. Let's say that it's in the directory
~/gmp-4.2.1-core2-port
3. Download GMP version 4.2.1
4. Uncompress and untar GMP. Let's say that it's in the directory
~/gmp-4.2.1
5. Change into the gmp-4.2.1-core2-port directory and run the install
script (if you want to see what it's doing, just read it... it's a
very simple script).
> cd ~/gmp-4.2.1-core2-port
> ./install_gmp_4.2.1_core2_patch.sh ~/gmp-4.2.1
6. Configure gmp for a 64 bit Intel Mac as such:
> cd ~/gmp-4.2.1
> ./configure --build=x86_64-apple-darwin CFLAGS="-m64 -fast"
(You can, of course, add whatever other config options you want. Be
sure to use the CFLAGS environmental variable given above on the
command line. Otherwise, the CFLAGS setting that configure generates
by default will give you compilation problems.)
7. Build it! Execute the following:
> make
8. Check it! Execute the following:
> make check
9. Install it.
> sudo make install
To Install on a Linux machine.
-------------------------------------------------------
1. Download gmp-4.2.1-core2-port.tar.gz
2. Uncompress and untar it. Let's say that it's in the directory
~/gmp-4.2.1-core2-port
3. Download GMP version 4.2.1
4. Uncompress and untar GMP. Let's say that it's in the directory
~/gmp-4.2.1
5. Change into the gmp-4.2.1-core2-port directory and run the install
script (if you want to see what it's doing, just read it... it's a
very simple script).
> cd ~/gmp-4.2.1-core2-port
> ./install_gmp_4.2.1_core2_patch.sh ~/gmp-4.2.1
6. Configure gmp as normal.
> cd ~/gmp-4.2.1
> ./configure
(You can, of course, add whatever other config options you want.)
7. Build it! Execute the following:
> make
8. Check it! Execute the following:
> make check
9. Install it.
> sudo make install
NOTES:
1. Wow! The GMP code base is really well organized! It was very easy
for me to find out exactly what files needed changing. Nice work guys!!
2. In amd64call.asm all I changed was to make the addressing relative to
the rip register rather than absolute. The Apple 64bit ABI doesn't support
absolute addressing. Since Linux can use either addressing mode, it
makes sense to use position independent code... it's more portable and
there's no real performance difference.
3. In add_n and sub_n I re-wrote the code to accomidate the Woodcrest
nuances. Mainly, I unrolled the main loop and I got rid of the "inc"
instruction (which causes a false dependency on the flag register and
thus stalls the pipeline). Of course, this also meant that I had to
save the carry flag between loop iterations using the "lahf" and
"sahf" instructions. These instructions are available on the Mac Pro
using the Apple assembler, but because some early x86_64 CPUs didn't
support those instructins, the GNU assembler doesn't allow those
mnemonics on 64bit machines (even when the CPU will support it). So,
my assembly code includes some m4 code which calls the shell script
"lahf_sahf_test.sh" which determines if the lahf and sahf instructions
are available on the CPU. If so, then it includes some hand assembled
bytes to get around GNU as limitations. Otherwise, it falls back to
using "setc" and "bt" which are slower.
4. On my 2.66 GHz Mac Pro, I was able to get a GMPbench score of 8263.
5. You'll notice a Makefile and a bunch of extraneous files. These are
used for testing the code outside of the GMP source tree. The Makefile
will produce a file called mpn_test which just runs the routines through
a bunch of speed and correctness tests and compares them against the
original GMP 4.2.1 assembly files.
6. On Mac OS X I haven't found a nice way yet to build dynamic
libraries. The biggest obstical is that the Apple "libtool" and the
GNU "libtool" have incompatible syntax. My guess is that in the near
future the GNU libtool will support the Apple libtool for creating
dynamic shared libraries. For the mean time, I'll be content with
static libraries. If you find a simple solution please let me know.
Jason Worth Martin
Asst. Prof. of Mathematics
James Madison Univ.
martinjw@jmu.edu
