YES!
Grand idea.
I have a Traktor cpu and wanna find out whether gcc will produce faster code for native binaries(along with a xop flag), so I am more than willing to test it.
I have win7 x64 OS.

[QUOTE=ATH;287086]Lately I have been wondering if it would be feasible to make a "compiling-kit" for GMP-ECM, so people could compile their own version.

Since Msys and Mingw64 do not need to be installed they could be just compressed along with some batch files for compiling mpir and gmp-ecm. If it works it would be just a matter of starting msys and running a few batch files to compile it.

Any interest in this idea? Anyone want to test if it works? It will involve downloading a 77 Mb 7zip-file.

Edit:
Forgot to mention this is for 64 bit Windows only. I could make one for 32 bit later if needed.[/QUOTE]
If I could be guided through the process, I'd like to try it.

win7 x64 at the moment.

If anyone else want to try compile gmpecm on your own machine (64 bit windows only), you need at least 650 Mb free on your c-drive. Thanks to Karl M Johnson for testing this. Thanks to WraithX for teaching me how to compile 64bit gmpecm.

1) Get the 82 Mb zip-file: [URL="http://www.hoegge.dk/mersenne/gmpecmcompile.zip"]gmpecmcompile.zip[/URL]
2) Extract gmpecmcompile.zip with 7-zip ([url]http://www.7-zip.org/[/url]) to the root of your c-drive: c:\ This will extract 3 folders: Msys, Mingw64, Python27 and a batch file: msys.bat
3) Run the c:\msys.bat (or the C:\msys\1.0\msys.bat). This will open the msys command window.
4) type: "mpircompile.bat" to compile MPIR. Choose in the menu which processor you have by typing A,B,C,D,E,F,G,H,I or J.
5) type: "gmpecm-compile.bat" to compile GMP-ECM. It will tune parameters for your computer so it will be best to turn off other programs during this.
6) get your ecm.exe in "C:\msys\1.0\home\gmpecm64" or in "C:\msys\1.0\local\bin"




More detailed explanation of the batch files:
mpircompile.bat will run config.guess to get the suggested build, which MPIR does very well. Then it will run:
configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -std=gnu99 -march=<processor> -mtune=<processor>" --enable-gmpcompat --build=<build> --host=<build>
where <processor> can be: corei7-avx, corei7, core2, atom, bdver1 (bulldozer), barcelona, opteron-sse3, opteron, athlon64-sse3, athlon64 and where <build> is the build from config.guess. For corei7-avx it adds the -mavx flag and for bulldozer it adds -mavx -mxop flags.
Then it will do:
make
make install
make check

gmpecm-compile.bat will first update the gmpecm64 folder to the latest svn, then it will run:
autoreconf -i
configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -std=gnu99 -march=<processor> -mtune=<processor>" LDFLAGS="-Wl,--stack,16777216" --enable-asm-redc --build=x86_64-w64-mingw32 --disable-assert --with-gmp=/usr/local
make
make check
make ecm-params; make
make install
where <processor> is the same as in MPIR compiling, and again -mavx added for core7-avx and -mavx -mxop for bulldozer.

[QUOTE=bdodson;286948]Looks like the comparison depends rather close on the size
of the numbers; ...
where the 63-binary was from ecm63mpircore2-64-asmredc.zip but
reports using gmp, ... and the i2
is the core2 binary with MPIR, but without redc. Actually, win reports
using redc, so maybe this is up in the range where without asm-redc
is better. Anyway, I'll be using ATH's i2 binary from here, up.

I still have the largest range to check, c290-c3xx, using B1=600M,
a 63-binary vs the winner here. -Bruce[/QUOTE]
Well, just for completeness, and before the outfiles get cat'ed away,
3m653, C289 with B1 = 600M gives a third different timing outcome
[code]
c3m653a.1:Step 1 took 6391657ms
c3m653a.1:Step 2 took 991745ms

c3m653b.1:Step 1 took 6389941ms
c3m653b.1:Step 2 took 987174ms

c3m653ci2.1:Step 1 took 6672147ms
c3m653ci2.1:Step 2 took 1002322ms

c3m653di2.1:Step 1 took 6915727ms
c3m653di2.1:Step 2 took 1011776ms [/code]
both with default B2 = 9535594068016. That's 63 winning in step1 ...

-Bruce

[QUOTE=bdodson;287917]Well, just for completeness, and before the outfiles get cat'ed away,
3m653, C289 with B1 = 600M gives a third different timing outcome
both with default B2 = 9535594068016. That's 63 winning in step1 ...

-Bruce[/QUOTE]

Maybe you should try and compile them yourself? I assume all you computers are the same processor, so just compile on one machine and delete folders afterwards, no installation needed.



Added an option to compile the old GMP-ECM 6.3 since it seems a few percent faster.

[QUOTE=ATH;287948]Added an option to compile the old GMP-ECM 6.3 since it seems a few percent faster.[/QUOTE]

Hello ATH,

I just saw a note posted to the gmp-ecm discuss mailing list saying that there was a speed regression in 6.4. Paul says that he has corrected this in svn version 1708. You can find his post here:

[url]http://lists.gforge.inria.fr/pipermail/ecm-discuss/2012-February/004103.html[/url]

Hopefully you, and especially Bruce ;) , will find this patched version useful.

Indeed, runs better!

A bit difficult to get from behind a corporate firewall -- and build without aclocal/automake etc already installed. See README.dev

After a lot of compilation attempts and benchmarks, I've finally found out the optimal compiling flags for Bulldozer CPUs.
-mtune, along with -march should be "bdver1" and -mxop and -mavx flags should be added.
By adding tho last flags you will have a 1-3% slowdown in stage1, but up to 7% increase in speed in stage2, which will result in a faster version overall.

Added SVN 1711 binaries, they are comparable speed with GMP-ECM 6.3 now:[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

I skipped both the GMP binaries (always slower) and the ones with --disable-asm-redc since there haven't been any difference lately.

The Corei7 No AVX binary is SVN 1712.

[QUOTE=ATH;288595]Added SVN 1711 binaries, they are comparable speed with GMP-ECM 6.3 now:[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

I skipped both the GMP binaries (always slower) and the ones with --disable-asm-redc since there haven't been any difference lately.

The Corei7 No AVX binary is SVN 1712.[/QUOTE]
Works great, thanks.
[QUOTE=lorgix;286589]I just did a quick test with a ~10k-digit number. Trying '-pp1'

B1=30 works, but if I add '-B2scale 4' it fails.
B1=100 fails, but if I add '-B2scale 0.5' it works.

It prints the stage1 time before it fails.

Higher bounds work for smaller inputs.[/QUOTE]
Does anybody know why this happens? Compiling my own binaries didn't affect this problem.

Which binary should we use for 64-bit Windows Vista when reliability and stability are of the utmost importance?

In Linux we are happily using the following package:

[code]GMP-ECM 6.3 [configured with GMP 5.0.1 and --enable-asm-redc]

$ ecm -printconfig
Compilation options:
Included GMP header files version 5.0.1
GWNUM_VERSION undefined
HAVE_SSE2 undefined
HAVE___GMPN_ADD_NC = 1
HAVE___GMPN_MOD_34LSUB1 = 1
HAVE___GMPN_REDC_1 = 1
MEMORY_DEBUG undefined
NATIVE_REDC = 1
TUNE_MULREDC_THRESH = 16
TUNE_SQRREDC_THRESH = 11
WINDOWS64_ABI undefined
WANT_ASSERT undefined
WANT_SHELLCMD undefined
_OPENMP undefined
MPZMOD_THRESHOLD = 128
REDC_THRESHOLD = 512
MUL_NTT_THRESHOLD = 256
NTT_GFP_TWIDDLE_DIF_BREAKOVER = 11
NTT_GFP_TWIDDLE_DIT_BREAKOVER = 11
PREREVERTDIVISION_NTT_THRESHOLD = 16
POLYINVERT_NTT_THRESHOLD = 256
POLYEVALT_NTT_THRESHOLD = 128
MPZSPV_NORMALISE_STRIDE = 128[/code]Thanks!

:max:

[SIZE=1][I] Edit: The CPU is a Sandy Bridge i5, if that matters.[/I][/SIZE]