A64/Win32/gmp proggy

[paulunderwood]

Could someone compile the attached program for Windows 32-bit running on an Athlon64 please. Attach the executable to your reply in this thread...

(I know it's not using the method of differences )

Is there a big difference between running this under win32 and win64?

[paulunderwood]

Sorry: I cleaned up the code -- attached is the replacement which I'd like compiled for a Athlon64 running 32bit XP...

[paulunderwood]

I've tried using "mingw" but with no success -- and I think it'll only do 32-bit stuff anyway.

Is there any difference between compiling for win32 and for win64 (both on AMD64) with a windows-based compiler?

[gribozavr]

I have a more general question: is it posibe to use full 64-bit registers, 64 bit x 64 bit = 128 bit multiply instructions etc on AMD64 while running 32-bit windows? If it is, please tell me more about it: how to compile, are any "workarounds"/code modifications needed? With this information we could compile mfactor for win32/AMD64. It will help operation billion digits as well as 100 million digits prefactor project.

[jasonp]

Originally Posted by gribozavr

I have a more general question: is it posibe to use full 64-bit registers, 64 bit x 64 bit = 128 bit multiply instructions etc on AMD64 while running 32-bit windows?

32-bit windows will never let you see 64-bit registers. The machine has to be in 64-bit mode for that.

jasonp

[Tumo]

Originally Posted by jasonp

32-bit windows will never let you see 64-bit registers. The machine has to be in 64-bit mode for that.

jasonp

True to that.. I have Opterons in both Windows and Linux.
I have both 32 and 64 bit Linux. To get a native 'long' to be 64 bits,
you must be in 64 bit mode. The GMP 'ui' operator wants unsigned
long and that implies 64 bits... which you don't get in 32 bit mode
with Mingw or GCC (which requires 'long long' for 64 bit)' unless you
recompile the entire G/MP library.

However.. when addressing a 64bit x 64bit multiply wanting to catch
the extra bits into a 128 bit register..... The SSE set allows this in
both 32 and 64 bit modes. On the A-64/Opteron, you may also
access the 2nd SSE2 register set in 64 bit mode (which is lots of
fun to use both simultaneously)... and allows some fast math.

I personally will avoid the FPU entirely in 64 bit mode when doing
integer math. Two techniques are available. a) standard Hi/Low half
math like we use for 32x32 bit multiplies in 32 bit mode... simply copied
verbatum into 64 bit code or b) using a Fortran 'Complex*16' with an
'Equivalence' (an equivalent C structure will also work) to map your
math to and then extract the parts as two 64 bit ints.

I prefer to stay in the Integer register set in 64 bit mode simply
because I have 2x as many AND they are 64 bits. Results in
lightning fast code.


As for the code you asked... I will compile it however you want...

available options:

1. 32 bit Windows.
2. 32 bit Linux (static or dynamic)
3. 64 bit Linux (static or dynamic)


Just give a hollar.

[paulunderwood]

As for the code you asked... I will compile it however you want...

available options:

1. 32 bit Windows.
2. 32 bit Linux (static or dynamic)
3. 64 bit Linux (static or dynamic)


Just give a hollar.

Thanks for the offer which I'll take you up on...

Can you compile the program for 32-bit Windows with as much optimisation for A64 as you can get... using "-march=athlon64" I guess. Whether you have to recompile GMP I leave to up to you.

TIA

[Tumo]

Originally Posted by paulunderwood

Thanks for the offer which I'll take you up on...

Can you compile the program for 32-bit Windows with as much optimisation for A64 as you can get... using "-march=athlon64" I guess. Whether you have to recompile GMP I leave to up to you.

TIA

Paul,
I assume that you have Cygwin installed. Please make sure you have
the latest version installed/updated to. Also, please make sure you
have GCC version 4 (it's under the software development part of the
Cygwin setup gui) and also under Math, grab the G/MP version 4 update.

This will guarantee compatibility. I am attempting to get both the
Mingw (stand-alone) and GCC (requires cygwin1.dll) versions working
in 32 bit for first cut.

For reference to all who use Cygwin on Win/XP or 2K with ANY Athlon-64
processor (I have clawhammer, newcastle, san diego, and sledgehammer cores), the GCC optimization to use is "-march=k8" . Anything 'tighter'
results in a conflict within the cygwin library because it was built for i686.

I recommend the following to all AMD users doing any Prime/Math related
code AND decide to do it in C. (Please avoid C++ *whenever* possible)..

(please double check me on these, i may be mis-spelling them... i'm doing it from memory)

Options: -march=k8 -O2 -fomit-frame-pointers -fstrength-reduce -fschedule-insns

You may experiment with the -msse2 -mfp-math=sse,387 or 387,sse preferences with each application. There are some additional options to use with these as well.

Lastly... Try not to use more than ONE register variable in a function unless you are doing code that does a lot of direct 1:1 load-calculate-store type sequences. We only are permitted to use 4 of the 8 registers the A-64's give us and cygwin/gcc likes to make heavy use of 2 registers for array indexing / pointer ops. (Remember, all local variables are base+offset calculations on the stack and that costs 1 register right there).

All are welcome to email / msg me directly with questions / comments / corrections / anything. I have been working with AMD's for a long time and also am working with some of the newer TBA products. (I still have a K6-2 running just fine at 550 mhz and 28C under full load).

[paulunderwood]

I assume that you have Cygwin installed. Please make sure you have
the latest version installed/updated to. Also, please make sure you
have GCC version 4 (it's under the software development part of the
Cygwin setup gui) and also under Math, grab the G/MP version 4 update.

The program is not to be run on my computers (which are all linux/32bit), rather it is to be run on a friends win32/athlon64 combination.

Ideally the program should be created as a "static" executable (with no reliance on external libraries to run.)

[Tumo]

Originally Posted by paulunderwood

The program is not to be run on my computers (which are all linux/32bit), rather it is to be run on a friends win32/athlon64 combination.

Ideally the program should be created as a "static" executable (with no reliance on external libraries to run.)

Thanks for that info. I will build using the MingW version of the G/MP library then. Most installations of G/MP assume that Cygwin is available unless you download G/MP directly and built it yourself.

FYI: The proggy is already up and running nicely in Cygwin... making a few Cygwin-level adjustments to it for speed up at this time so you will have a higher cache-hit ratio, which will further improve when compiled static.

[paulunderwood]

On second thoughts: If all that is required is readily available DLL then the Cygwin build will be fine...