[QUOTE=VictordeHolland;418551]Massive thanks!
That one is almost 20% faster in stage 2 on my Sandy and Ivy Bridge processors compared to the ancient one I was using (GMP-ECM 6.4.4 with MPIR2.6.0 for processor type i7 from [URL="http://gilchrist.ca/jeff/factoring/index.html"]this page[/URL]) .
I wanted to get/compile more recent ones myself, but never got around to do so.[/QUOTE]
+1 from me! Same here! Thanks ATH!

[QUOTE=ATH;417546]Lastest SVN 2745 compiled on for Haswell with GMP 6.1.0 with the following:
./configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -mavx2 -mfma -march=haswell -mtune=haswell" LDFLAGS="-Wl,--stack,16777216" --build=x86_64-w64-mingw32 --disable-assert

[URL="http://www.hoegge.dk/mersenne/gmpecm7-svn2745.zip"]gmpecm7-svn2745.zip[/URL][/QUOTE]

Doesn't play well with interim stage 1 residue files from Prime95

"Error, save file line has no '=' in : [Fri Dec 11 18:"

whereas the version in this : ecm70dev-svn2256-x64-nehalem.zip copes just fine with the missing '=' and carries on.

Not really practical to edit the results file when it contains the residues from 600 curves....

Thanks for the binaries.

They are faster than all previous precompiled versions that I have for my laptop but the auto-increase of B1 bounds has disappeared (-i option) and B2scale also.

It may cause aliqueit to crash in some cases and ecp.py to be tweaked.

Philippe

[QUOTE=ATH;417546]Lastest SVN 2745 compiled on for Haswell with GMP 6.1.0 with the following:
./configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -mavx2 -mfma -march=haswell -mtune=haswell" LDFLAGS="-Wl,--stack,16777216" --build=x86_64-w64-mingw32 --disable-assert

[URL="http://www.hoegge.dk/mersenne/gmpecm7-svn2745.zip"]gmpecm7-svn2745.zip[/URL][/QUOTE]

Many thanks from me, too :bow:
Indeed this version is about 22% faster at stage 2 as my old one with GMP 4.4, very nice!
The zip contains 2 more exe-files 'ecmfactor' and 'multiecm', any info about them available?

@ Gordon: I simply wrote a 20 line proggy with Lazarus, reading a prime95-stage1-output-txt-file, deleting all lines starting with a bracket '[' and resaving it to an gmp-stage2-input-file. I never had problems with the bracket :wink:

[QUOTE=MatWur-S530113;419084]Many thanks from me, too :bow:
Indeed this version is about 22% faster at stage 2 as my old one with GMP 4.4, very nice!
The zip contains 2 more exe-files 'ecmfactor' and 'multiecm', any info about them available?

@ Gordon: I simply wrote a 20 line proggy with Lazarus, reading a prime95-stage1-output-txt-file, deleting all lines starting with a bracket '[' and resaving it to an gmp-stage2-input-file. I never had problems with the bracket :wink:[/QUOTE]

I downloaded Notepad++ and with a bit of regex was able to fix it.

I too am curious about multiecm...

I do not know what "ecmfactor.exe" and "multiecm.exe" are used for. I just include them as they are compiled along side of "ecm.exe". I guess we should ask the GMP-ECM team.

@Gordon: Maybe you should create a thread in the GMP-ECM forum about the issue with interim files from Prime95. I have nothing to do with the GMP-ECM development team, I'm just compiling it (when I can figure out to get it to work).

Is there an additional benefit if compiled with --ffast-math, or is that too dangerous?

Got the latest svn 2749 compiled on a Broadwell laptop only with GMP 6.0.0 unfortunately as 6.1.0 failed to compile (I sent a mail to the gmp site). I also did new compile on haswell and sandybridge with slightly new options:

Broadwell; GMP-ECM7 SVN 2749 with GMP 6.0.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2749-broadwell.zip"]gmpecm7-svn2749-broadwell.zip[/URL] (compiled on Core i5 5200U laptop)

Haswell: GMP-ECM7 SVN 2749 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2749-haswell.zip"]gmpecm7-svn2749-haswell.zip[/URL] (compiled on a Haswell-E Core i7 5960X desktop)

Sandy Bridge: GMPECM7 SVN 2749 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2749-sandybridge.zip"]gmpecm7-svn2749-sandybridge.zip[/URL] (compiled on a Core i7 2720QM laptop)

I got a patch for GMP 6.1.0 on Broadwell:

Broadwell; GMP-ECM7 SVN 2749 with [B]GMP 6.1.0[/B]: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2749-broadwell.zip"]gmpecm7-svn2749-broadwell.zip[/URL] (compiled on Core i5 5200U laptop)

If anyone is still using Core2 for GMP-ECM:

Core2; GMP-ECM7 SVN 2749 with GMP 6.1.0: [URL="hoegge.dk/mersenne/gmpecm7-svn2749-core2.zip"]gmpecm7-svn2749-core2.zip[/URL] (compiled on a Core2Quad (Yorksfield) Q9450)

How do I figure out which version to use on a machine? For example, I have occasional access to a machine running Win 7. Control Panel>System says the processor is a Xeon E3-1246 v3

[QUOTE=wblipp;423230]How do I figure out which version to use on a machine? For example, I have occasional access to a machine running Win 7. Control Panel>System says the processor is a Xeon E3-1246 v3[/QUOTE]

William, use the Haswell one.

Carlos is correct, if you look at this list and search for 1246 you will find it under the "Haswell based Xeons"-section:
[url]https://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors[/url]

ATH, any chance you'd be willing to compile one optimized for AMD?

Piledriver (i.e. march/mtune = bdver2) would be the most appropriate target. Though Steamroller and Excavator are newer, Excavator is laptops only, Steamroller (desktop Kaveri APUs) is not much different from Piledriver (instruction wise just adds FSGSBASE), and the main FX line (incl. inexpensive 8-core chips) is still stuck on Piledriver.

I'm a little confused as to why you're using each kind of processor to compile its own binary- is that for testing purposes or is there some reason you're tied to -march=native?

I always assumed it was better to compile on the correct hardware instead of cross compiling, and in this case with GMP and GMPECM it seems I was right.

GMP does a lot of checks of the different types of variables which are available on your computer and compiler, so what won't work for cross compiling, and GMPECM has 2 tuning steps for tuning the parameters.

I tried GMP with --build=haswell-w64-mingw32 and --host=piledriver-w64-mingw32 but that failed. It also failed with just --build=piledriver-w64-mingw32. Then I tried using my GMP version and just compiling GMPECM, but that failed as well.

I did consider making a new zip file with MSYS2 and instructions on how to compile both GMP and GMPECM, and if you do not mind, you can try and "beta" test it. I'll send you a pm.

[QUOTE=bsquared;427139][QUOTE=jasonp;427136]
Unfortunately the GMP-ECM library is not technically multithread-safe, I think it uses a sieve of eratosthenes that has some global state. You could actually do the community a great service if you could fix that and Msieve does have a GMP-ECM driver. Alternately, YAFU can call multiple copies of the GMP-ECM demo binary.
[/QUOTE]

Yep :) The unsafeness of the library is why yafu only allows multithreading with the external binary. [/QUOTE]
As an FYI to those who may be interested, recent svn changes to GMP-ECM now include a thread safe prime sieve. You can see this mentioned in the NEWS file in svn:
[QUOTE]Changes between GMP-ECM 6.4.4 and GMP-ECM 7.0:
* GMP-ECM is now thread-safe. In particular the "ecmfactor" binary can be
called with say -t 17 to use 17 threads.[/QUOTE]

Haswell: GMP-ECM7 SVN 2840 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2840-haswell.zip"]gmpecm7-svn2840-haswell.zip[/URL]

Sandy Bridge: GMPECM7 SVN 2840 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2840-sandybridge.zip"]gmpecm7-svn2840-sandybridge.zip[/URL]




I still had to comment out line 191 and 203 in "bench_mulredc.c", same error as described here in post #50+#52: [url]http://www.mersenneforum.org/showthread.php?t=16444[/url]

Also had to comment out line #880+#881 in main.c:
[CODE]/* if (verbose >= 2)
printf ("Tuned for %s\n", ECM_TUNE_CASE); */[/CODE]
as ECM_TUNE_CASE was not defined. I think is not meant to use that variable in those line since there is a check if it is defined in line #166-#170:
[CODE]#ifdef ECM_TUNE_CASE
printf ("Tuning parameters from %s\n", ECM_TUNE_CASE);
#else
printf ("ECM_TUNE_CASE not defined.\n");
#endif[/CODE]

[QUOTE=ATH;427636]I still had to comment out line 191 and 203 in "bench_mulredc.c", same error as described here in post #50+#52: [url]http://www.mersenneforum.org/showthread.php?t=16444[/url]

Also had to comment out line #880+#881 in main.c:[/QUOTE]

Thanks for mentioning this again. This is now fixed in svn 2841.

[QUOTE=ATH;427636]Haswell: GMP-ECM7 SVN 2840 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2840-haswell.zip"]gmpecm7-svn2840-haswell.zip[/URL]

[/QUOTE]

ecm doesn't have the -t parameter and when I run ecmfactor -h it spits out this error

The program can't start because libwinpthread-1.dll is missing....

Sorry I always forget to consider which dll files are needed with the binaries. I added libwinpthread-1.dll to the zip files.

Anyone willing to supply the latest linux binaries please?

[QUOTE=pinhodecarlos;428444]Anyone willing to supply the latest linux binaries please?[/QUOTE]

The release of version 7.0 is nearing completion. Release candidate 2 is now available. See here for details:
[url]http://lists.gforge.inria.fr/pipermail/ecm-discuss/2016-March/004333.html[/url]

[QUOTE=WraithX;428451]The release of version 7.0 is nearing completion. Release candidate 2 is now available. See here for details:
[url]http://lists.gforge.inria.fr/pipermail/ecm-discuss/2016-March/004333.html[/url][/QUOTE]

Had issues while making ecm-params.
The file README.gpu is still missing.
I had to look bk to the configure files to find the -enable_gpu parameter.

Luigi

[QUOTE=ET_;430946]Had issues while making ecm-params.
The file README.gpu is still missing.
I had to look bk to the configure files to find the -enable_gpu parameter.

Luigi[/QUOTE]I recommend that you get the svn version.

Paul

[QUOTE=xilman;430953]I recommend that you get the svn version.

Paul[/QUOTE]

I found the rc1 in the inria forge, and still no README.gpu

I will recheck, maybe I did something wrong...

[QUOTE=ET_;431020]I found the rc1 in the inria forge, and still no README.gpu

I will recheck, maybe I did something wrong...[/QUOTE]I meant to get [c]svn checkout https://scm.gforge.inria.fr/anonscm/svn/ecm/[/c] SVN repository direct from inria. Thereafter [c]svn update[/c] will keep you on the bleeding edge.

Good luck!

Paul

Anyone have a foolproof way of compiling this version of the software? I'm trying to compile it on my i7 5820K with Windows. I have tried Cygwin64, mingw64 and Visual Studio and I receive different errors on each program.

I've even tried the SVN latest version.

I'm open to suggestions since I've never had trouble compiling a program before and I've been working on this for over a week now.

Thanks,


John

[QUOTE=johnadam74;431357]Anyone have a foolproof way of compiling this version of the software? I'm trying to compile it on my i7 5820K with Windows. I have tried Cygwin64, mingw64 and Visual Studio and I receive different errors on each program.

I've even tried the SVN latest version.

I'm open to suggestions since I've never had trouble compiling a program before and I've been working on this for over a week now.

Thanks,


John[/QUOTE]

It is easy to compile once you have your environment set up for it. Since you didn't say what you've tried specifically, or what errors you ran into, I'll give you a run down based on how I compile GMP and GMP-ECM.

First, you'll need MSYS. I get the one from here:
[url]https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/[/url]
The current latest is from 2013-05-15, and is called msys+7za+wget+svn+git+mercurial+cvs-rev13.7z
I then extract that to:
[C]c:\msys\msys-20130515\[/C]

Then you'll need mingw64. You can get that here:
[url]https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/[/url]
Choose which compiler version you want, the latest is 4.8.5, 4.9.3, or 5.3.0. Probably go with 4.9.3, unless you want 5.3.0. Then choose "threads-posix", then choose "seh", then download the latest available. Once I've done that I extract it to:
[C]c:\mingw64\mingw64-4.9.3-20150903\[/C]

Then, go back into the msys folder and edit the following file:
[C]c:\msys\msys-20130515\etc\profile[/C]
to change:
[CODE]if [ $MSYSTEM == MINGW32 ]; then
export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"[/CODE]
to this:
[CODE]if [ $MSYSTEM == MINGW32 ]; then
# export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
export PATH=".:/c/mingw64/mingw64-4.9.3-20150903/bin:/usr/local/bin:/bin:$PATH"[/CODE]

Then, download the latest GMP from [url]https://gmplib.org/[/url] The current latest is 6.1.0.
Open up an msys shell by double clicking the [C]c:\msys\msys-20130515\msys.bat[/C] file. Let's say you extracted GMP to [C]c:\gmp\gmp-6.1.0\[/C], then in the msys shell, you would run the following commands:
[C]cd /c/gmp/gmp-6.1.0/[/C]
[C]./configure[/C]
[C]make[/C]
[C]make check[/C]

If all of that completes successfully, then you need to copy two files:
1) copy [C]gmp.h[/C] from [C]c:\gmp\gmp-6.1.0\[/C] to [C]c:\mingw64\mingw64-4.9.3-20150903\x86_64-w64-mingw32\include\[/C]
2) copy [C]libgmp.a[/C] from [C]c:\gmp\gmp-6.1.0\.libs\[/C] to [C]c:\mingw64\mingw64-4.9.3-20150903\x86_64-w64-mingw32\lib\[/C]

Now you have msys, mingw64, and gmp set up correctly. To get gmp-ecm compiled, download the latest svn, let's say you save those files to:
[C]c:\gmp-ecm\svn_2915\[/C]
Then, in the msys shell, you would:
[C]cd /c/gmp-ecm/svn_2915/[/C]
[C]autoreconf -i[/C]
[C]./configure --enable-asm-redc --build=x86_64-w64-mingw32 --disable-assert[/C]
[C]make[/C]
[C]make check[/C]

This should all complete successfully for you. If you run into any errors, let us know and we can try to help you resolve them. If you don't run into any errors, then you will have a working ecm.exe file that you can use to factor numbers!

[QUOTE=WraithX;431359]
Now you have msys, mingw64, and gmp set up correctly. To get gmp-ecm compiled, download the latest svn, let's say you save those files to:
[C]c:\gmp-ecm\svn_2915\[/C]
Then, in the msys shell, you would:
[C]cd /c/gmp-ecm/svn_2915/[/C]
[C]autoreconf -i[/C]
[C]./configure --enable-asm-redc --build=x86_64-w64-mingw32 --disable-assert[/C]
[C]make[/C]
[C]make check[/C]

This should all complete successfully for you. If you run into any errors, let us know and we can try to help you resolve them. If you don't run into any errors, then you will have a working ecm.exe file that you can use to factor numbers![/QUOTE]
The latest, as of last night, is SVN 2916 and it works well for me. Note that 2914 and below have a serious bug in the GPU portion of GMP-ECM.

I would (and did last night)also run [c]make ecm-params[/c] between [C]make[/C] and [C]make check[/C] for (near) optimal performance.

[QUOTE=johnadam74;431357]Anyone have a foolproof way of compiling this version of the software? I'm trying to compile it on my i7 5820K with Windows. I have tried Cygwin64, mingw64 and Visual Studio and I receive different errors on each program.

I've even tried the SVN latest version.

I'm open to suggestions since I've never had trouble compiling a program before and I've been working on this for over a week now.

Thanks,


John[/QUOTE]

It builds fine for me with Visual Studio 2013 and CUDA 7.5 (for the GPU build). It won't build with Visual Studio 2015 at the moment becasuse NVIDIA has yet to update its CUDA toolkit to work with this compiler.

If you can let me know what issues you ran into in using the Visual Studio build, I might be able to help.

[QUOTE=xilman;431372]The latest, as of last night, is SVN 2916 and it works well for me. Note that 2914 and below have a serious bug in the GPU portion of GMP-ECM.

I would (and did last night)also run [c]make ecm-params[/c] between [C]make[/C] and [C]make check[/C] for (near) optimal performance.[/QUOTE]

What was the serious bug? I looked on the bug reporter on Inria, but didn't see anything.

[QUOTE=wombatman;431390]What was the serious bug? I looked on the bug reporter on Inria, but didn't see anything.[/QUOTE]The save files weren't created properly and so were useless. I wasted about a 970-day before Greg Childers' note to ecm-discuss arrived.

Paul

Ouch! Good to know--looks like I'll be rebuilding GPU-ECM tonight. :smile:

I took a stab at creating a "compile yourself"-package again. I did one a few years ago where I tried to automate it with batch files.

This time I made it simpler with just a readme file explaining the steps and a working compiling environment. This is only for compiling GMP-ECM on Windows 64 bit without gpu support.



Download the compressed Msys2 folder: [URL="http://hoegge.dk/mersenne/gmpecm-compile.zip"]gmpecm-compile.zip[/URL] (234 Mb)

You should do a proper anti virus check and whatever you deem necessary.

First rename the "gmpecm-compile.zip" file to "gmpecm-compile.7z" because my site does not allow the .7z extension, and use 7-zip to extract it to C:\ ([url]http://www.7-zip.org[/url]).
You [I]can[/I] extract the file with 7-zip without renaming it, but it will give a warning that it is not a .zip file.

It will extract one folder "C:\msys64" which takes about 1 Gb. This is the Msys2 program with Mingw64 and other packages installed along with the source for GMP and GMPECM.

[I][B]If you do not want it on the C-drive, you can extract it to another drive or folder for example d:\msys64, but then you need to create a symbolic link on the c-drive. You need to use a command prompt with administrator rights and then type:
c:
cd\
mklink /D c:\msys64 d:\msys64
Replace "d:\msys64" with the full path to where ever you extracted the folder. But you will still have to access the folder through the c:\msys64 symbolic link.[/I][/B]


Start "c:\msys64\mingw64_shell.bat" to start MSYS2. It should open MSYS2 along with instructions "c:\msys64\home\compile-readme.txt" in a Notepad. If the text file does not open, then open it manually to follow the instructions.

Here is the readme file if you already have Msys or Msys2: [URL="http://hoegge.dk/mersenne/compile-readme.txt"]compile-readme.txt[/URL]

Let me know of any errors or missing or unclear instructions.

[QUOTE=Brian Gladman;431378]It builds fine for me with Visual Studio 2013 and CUDA 7.5 (for the GPU build). It won't build with Visual Studio 2015 at the moment becasuse NVIDIA has yet to update its CUDA toolkit to work with this compiler.

If you can let me know what issues you ran into in using the Visual Studio build, I might be able to help.[/QUOTE]

Why does nvidia stay so far behind on this?
Why are they also not very backwards or forwards compatible? Do they continuously rely on new features or something? In general compilers are pretty forwards compatible at least.

[QUOTE=henryzz;431473]Why does nvidia stay so far behind on this?
Why are they also not very backwards or forwards compatible? Do they continuously rely on new features or something? In general compilers are pretty forwards compatible at least.[/QUOTE]Several possible reasons.

1) Almost all serious computational systems use a Unix-like system and Windoze is a relatively small fraction of their customer base;
2) They like to be behind the bleeding edge so that their solid and reliable products don't produce nasty surprises;
3) Although the new features may be supported by older infrastructure, they don't wish to lose customers and/or be sued when they aren't;
4) They would prefer others, who enjoy being at the bleeding edge, to find all the gotchas and their fixes rather than paying their own engineers to do that task;
5) ...
6) Profit!


Other reasons left as an exercise for the reader.

(The lack of support for recent versions of gcc mitigates against 1) but doesn't rule it out.)

[QUOTE=henryzz;431473]Why does nvidia stay so far behind on this?
Why are they also not very backwards or forwards compatible? Do they continuously rely on new features or something? In general compilers are pretty forwards compatible at least.[/QUOTE]
I suspect that the process of building their binary components with their compiler and then getting the various host compilers to integrate and deliver these components onto the target platforms is very host compiler specific and involves quite a lot of engineering and a lot of testing. They have also put a lot of new capabilities into CUDA 8 and I would guess that its taking longer than they expected to get all of this into a release state.

It is certainly a nuisance having to keep old versions of Visual Studio around, especially so given the advances made in VS 2015 in terms of C++ support.

Their current estimate is that CUDA 8 with VS 2015 support will be released in June and I plan to update the msieve and ECM builds then.

[QUOTE=ATH;427636]Haswell: GMP-ECM7 SVN 2840 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2840-haswell.zip"]gmpecm7-svn2840-haswell.zip[/URL]

Sandy Bridge: GMPECM7 SVN 2840 with GMP 6.1.0: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2840-sandybridge.zip"]gmpecm7-svn2840-sandybridge.zip[/URL]

I still had to comment out ... [/QUOTE]

Is this the current haswell version? Must be better
than benchmarking with the old athlon ... Nodes
are dual 10-core or dual 12-core.

[quote]
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
stepping : 2
microcode : 0x36
cpu MHz : 2599.988
cache size : 25600 KB
[/quote]

Here is a newer one: SVN 2968 compiled on Aug 2nd: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2968-haswell.zip"]gmpecm7-svn2968-haswell.zip[/URL]

I can compiled the newest one if needed.

[QUOTE=ATH;440276]Here is a newer one: SVN 2968 compiled on Aug 2nd: [URL="http://hoegge.dk/mersenne/gmpecm7-svn2968-haswell.zip"]gmpecm7-svn2968-haswell.zip[/URL]

I can compiled the newest one if needed.[/QUOTE]

Much difference between that and 2908, in particular the inability to use more than 16gb of memory?

[QUOTE=Gordon;440279]Much difference between that and 2908, in particular the inability to use more than 16gb of memory?[/QUOTE]

No, this is the one I compiled for you to test your problem in the other thread.

linux binary
 

[QUOTE=Dubslow;325614]Okay then.

Attached is a GMP-ECM 7.0-dev, SVN r2345 binary for GNU-Linux (x86-64), compiled with gcc 4.7.2 and statically linked against GMP 5.1.0. Documentation included.[/QUOTE]

Let's try this again. Is this the most recent gmp-ecm linux binary? I see
requests from Carlos on 2015-12-09 and again on 2016-03-08. But everything
since 7.0-dev is windows? -Bruce

(Thanks to ATH for pm reply.)

[QUOTE=bdodson;440328]Let's try this again. Is this the most recent gmp-ecm linux binary? I see
requests from Carlos on 2015-12-09 and again on 2016-03-08. But everything
since 7.0-dev is windows? -Bruce

(Thanks to ATH for pm reply.)[/QUOTE]

Errr... not sure this is of real value to you, but here's an ECM 7.0.1 tag compiled for GNU-Linux x86_64.

Lesse... gcc and gmp are apparently verions... 4.9.2 and... 6.0.0 respectively.

My architecture is the now-old Sandy Bridge, and is probably compiled as such.

Let me know if you want me to attempt 1) a newer dev version of ecm 2) a never version of gmp or 3) compiling for a different architecture than mine own, which will likely result in decent to significant speed bumps on recent Intel hardware if not AMD too.

[code]./ecm -printconfig
Compilation options:
Included GMP header files version 6.0.0
GMP_NUMB_BITS = 64
Tuning parameters from x86_64/k8/params.h
GWNUM_VERSION undefined
HAVE_SSE2 undefined
HAVE___GMPN_ADD_NC undefined
HAVE___GMPN_MOD_34LSUB1 = 1
HAVE___GMPN_REDC_1 = 1
USE_ASM_REDC = 1
WINDOWS64_ABI undefined
WANT_ASSERT undefined
_OPENMP undefined
MPZMOD_THRESHOLD = 21
REDC_THRESHOLD = 512
MUL_NTT_THRESHOLD = 256
NTT_GFP_TWIDDLE_DIF_BREAKOVER = 12
NTT_GFP_TWIDDLE_DIT_BREAKOVER = 17
PREREVERTDIVISION_NTT_THRESHOLD = 16
POLYINVERT_NTT_THRESHOLD = 512
POLYEVALT_NTT_THRESHOLD = 128
MPZSPV_NORMALISE_STRIDE = 128
WITH_GPU undefined
[/code]

Sorry about the wait Carlos. Compiling isn't *quite* my idea of a leisurely afternoon. That said, I suppose I'm taking requests for now at least, let me know if you'd like any of the three options above.

[QUOTE=Dubslow;440421]Errr... not sure this is of real value to you, but here's an ECM 7.0.1 tag compiled for GNU-Linux x86_64.

Lesse... gcc and gmp are apparently verions... 4.9.2 and... 6.0.0 respectively.

My architecture is the now-old Sandy Bridge, and is probably compiled as such.
....

Sorry about the wait Carlos. Compiling isn't *quite* my idea of a leisurely afternoon. That said, I suppose I'm taking requests for now at least, let me know if you'd like any of the three options above.[/QUOTE]

Super! I've already come back to expecting to have to compile gmp and
the gmp-ecm locally to get better tuning, but still hoping not to have to
spend THIS afternoon on that. Production is going to depend on updating
my maui/pbs submit file for "SLURM" or-some-such. One node having
2x10 cores or 2x12 cores. Twenty copies of your binary seem to be
running ok, in an interactive node; question is whether I'll get paging in
step2; in which case I'd cut back. I've been running six jobs on a 16-core
node on the old cluster. SamW reports same issue at Purdue. -bdodson

I have Linux Mint installed on a Virtual Box virtuel machine, and I managed to compile the newest SVN 2975 for Linux on the Haswell:

[URL="http://hoegge.dk/mersenne/gmpecm7-svn2975-haswell.tar.gz"]gmpecm7-svn2975-haswell.tar.gz[/URL]

[QUOTE=ATH;440471]I have Linux Mint installed on a Virtual Box virtuel machine, and I managed to compile the newest SVN 2975 for Linux on the Haswell:

[URL="http://hoegge.dk/mersenne/gmpecm7-svn2975-haswell.tar.gz"]gmpecm7-svn2975-haswell.tar.gz[/URL][/QUOTE]

Thanks, I'll have a look. The new cluster has 128Gb/node, c. 6Gb/ core;
and it looks like I will be able to use all 20 cores. -Bruce

Thank you both for the linux binaries.

[QUOTE=pinhodecarlos;440720]Thank you both for the linux binaries.[/QUOTE]

A snapshot of timings
[code]
b402-12p274.ta-has01-linux-x86:Step 1 took 10795749ms [ATH]
b402-12p274.ta-has01-linux-x86:Step 2 took 4608298ms

b401-12p274.ta01-linux-x86:Step 1 took 13440512ms [Dubslow]
b401-12p274.ta01-linux-x86:Step 2 took 5162233ms

b402-12p274.ta01-athlon:Step 1 took 17729420ms [old athlon]
b402-12p274.ta01-athlon:Step 2 took 5109079ms [/code]
Not sure about Step 2, memory intensive timing; step 1 looks
fairly serious. The old, athlon cluster (Ivy Bridge) got
[code]
Step 1 took 22512143ms
Step 2 took 8342209ms [/code]
all B1=3e9 on a C213. Looks more like a factor of two
than the theory factor of four timing improvement being
advertised. Suppose the next question is whether
I can do any better by tuning gmp here.

A reading from top during step 2 showed 5.36Gb to 6.28Gb
of memory use/job of the 20 jobs; I won't be able to make
too much of an increase in either B1 or the size without
cutting back to fewer jobs/node.
-Bruce

[QUOTE=bdodson;441169]A reading from top during step 2 showed 5.36Gb to 6.28Gb
of memory use/job of the 20 jobs; I won't be able to make
too much of an increase in either B1 or the size without
cutting back to fewer jobs/node.
-Bruce[/QUOTE]

You can always use the -maxmem or -k option.

Nice to see that the binary worked.

The last "sandy-6" from ATH looks also much faster, in this part of the world, compared with what we were using before (some version from 2013). Could you compile a 32bit windoze of it, for an old sandy running here around? (in fact an ivy, i5-3470, win xp 32 bits, for which the actual exe crashes with "this is not a win32 application" - which is normal, hehe). Also, I see a 7.0.3 on the svn there, any benefits in switching?

(edit, no, there in no way I could update this particular machine to a 64-bit os)

I'm not sure why an Ivy Bridge cannot run 64-bit OS, but here it is a 32 bit version:


Ivy Bridge - GMPECM 7.0.4 svn 2988 32bit:

[URL="http://hoegge.dk/mersenne/gmpecm7-svn2988-ivybridge-32bit.zip"]gmpecm7-svn2988-ivybridge-32bit.zip[/URL]


Here is a normal 64bit Ivy Bridge GMPECM 7.0.4 svn 2988:

[URL="http://hoegge.dk/mersenne/gmpecm7-svn2988-ivybridge.zip"]gmpecm7-svn2988-ivybridge.zip[/URL]

[QUOTE=ATH;441992]I'm not sure why an Ivy Bridge cannot run 64-bit OS, but here it is a 32 bit version[/QUOTE]
SWMBO's machine is running 32-bit Windoze because, allegedly, some application and/or device driver doesn't work under the 64-bit version.

I'm trying to move her to a 64-bit Linux installation.

Skylake build GMPECM7.0.4 svn 2988:

[URL="http://hoegge.dk/mersenne/gmpecm7-svn2988-skylake.zip"]gmpecm7-svn2988-skylake.zip[/URL]

Can I request a static linked gmp-ecm version for Core 2 for Linux 64/32?

[URL="https://www.rechenkraft.net/yoyo/download/ecm-svn3013-aarch64"]A gmp-ecm binary (svn3013) for aarch64 (ARM Linux 64 bit)[/URL].

Core2 static binaries for Linux (x86) SVN3013:

64bit: [URL="http://hoegge.dk/mersenne/gmpecm-svn3013-core2-linux.tar.gz"]gmpecm-svn3013-core2-linux.tar.gz[/URL]
32bit: [URL="http://hoegge.dk/mersenne/gmpecm-svn3013-core2-linux32bit.tar.gz"]gmpecm-svn3013-core2-linux32bit.tar.gz[/URL]

Core2 static binaries for Windows SVN3013:

64bit: [URL="hoegge.dk/mersenne/gmpecm-svn3013-core2.zip"]gmpecm-svn3013-core2.zip[/URL]
32bit: [URL="hoegge.dk/mersenne/gmpecm-svn3013-core2-32bit.zip"]gmpecm-svn3013-core2-32bit.zip[/URL]

[QUOTE=yoyo;449984][URL="https://www.rechenkraft.net/yoyo/download/ecm-svn3013-aarch64"]A gmp-ecm binary (svn3013) for aarch64 (ARM Linux 64 bit)[/URL].[/QUOTE]

Does aarch64on ARM8 means that it can be run on a Raspberry PI 3?

Luigi

Try it. It depends on your operating system.
I compiled them on an Odroid with Debian and send them now around with Boinc projekt yoyo@home.

[QUOTE=yoyo;451847]Try it. It depends on your operating system.
I compiled them on an Odroid with Debian and send them now around with Boinc projekt yoyo@home.[/QUOTE]

That's exactly what I needed to know, thanks :smile:

Luigi

[QUOTE=ATH;420862]If anyone is still using Core2 for GMP-ECM:

Core2; GMP-ECM7 SVN 2749 with GMP 6.1.0: [URL="hoegge.dk/mersenne/gmpecm7-svn2749-core2.zip"]gmpecm7-svn2749-core2.zip[/URL] (compiled on a Core2Quad (Yorksfield) Q9450)[/QUOTE]

Yes i am trying it now at my L5420 Xeon box seeing whether with a quick run i can find a bunch of factors.

Many thanks for posting it!

With settings: ecm -base2 2 -one -maxmem 2000 -v 50 < rbh_ecm.txt
Yet it seems to not use more than 277MB according to its own estimate.
Nice using up roughly 13 minutes.

First one it started with is 69 * 2^ 4613751 - 1
No factor found.

How do i get a neat list with factors found printed to disk?
That file i gave it has 1000 lines.

From ECM- read me file
[QUOTE]The P−1 method works well when the input number has a prime factor P such that P−1 is "smooth", i.e., has all its prime factor less or equal the step 1 bound B1, except one which may be less or equal the second step bound B2. For P=67872792749091946529, we have P−1=25*11*17*19*43*149*8467*11004397, so this factor will be found as long as B1>=8467 and B2>=11004397[/QUOTE]Since I still playing with P-1 I try several times to do on Prime95 ( with success) and on GMP-ECM ( last version 7.0.5 is nearly 2x faster then 7.0.4) but without any success. On the first sight it looks like Prime95 and GMP-ECM do the same thing but there is two big differences:
On mega-digit candidate you can run Prime 95 without any problem and he will be done in few minutes with nice B! and B2 ( in my tests was B1=80000 and B2=800000)
Using same values on GMP-ECM do only two things: or program stops ( he is not stop really - but will work many hours/days)or eat so much memory .
I still dont know why GMP-ECM is working on this way, then in same time with same candidate Prime95 work without any problem ,and from time to time find factor.
I contact many people that use GMP-ECM, but only got partially answers, with any true direction. Even giving them times and candidate from Prime95 wont do no good.
They are not caring , or they didn't understand what I ask .
Even with 2milion digits Prime95 do P-1 in 10 -15 minutes and using 1 GB of RAM. I thing that P-1 on GMP-ECM is not possible even running one whole day.
What is difference and why is such big difference it is still mystery for me.
Maybe someone here know the answer?

Pepi-
The two programs use different internal methods; Prime95 is quite fast in stage 1, and works for large inputs, but only works on certain forms; while GMP-ECM works on any input and is much much faster in stage 2 for those inputs that fit into memory, but uses a slower stage 1 and requires an awful lot of memory for stage 2 on large inputs.

Use the program that suits your input, and accept they're each quite good at what they do.

[QUOTE=VBCurtis;456194]Pepi-
The two programs use different internal methods; Prime95 is quite fast in stage 1, and works for large inputs, but only works on certain forms; while GMP-ECM works on any input and is much much faster in stage 2 for those inputs that fit into memory, but uses a slower stage 1 and requires an awful lot of memory for stage 2 on large inputs.

Use the program that suits your input, and accept they're each quite good at what they do.[/QUOTE]
Thanks: so one mystery is over.
Can you solve my next "problem" - every one told next thing: using Pminus1 is same as using one curve to high B1 and B2.
How to setup to use GMP-ECM with same efficiency as Pminus1: to use for example 10 curves but with lower B1 and B2? Using ECM2 mode on Prime95 gives me many times lower factor findings then use P-1. For my purposes it looks like P-1 is winning method, can be ECM2 used for same purpose, similar timings and same number of finding factors?

Mersenne numbers have factors of the form 2kp+1, where p is the exponent. P-1 factoring searches for factors P such that P-1 is smooth; for mersenne factors, P-1 = 2kp+1 -1 = 2kp. So, P-1 gets the "2p" portion of the factor for free, which is why it is about 8 digits better at finding factors of mersenne numbers than regular ECM; this is the same reason that Mersennes are trial-factored very quickly but not sieved in bulk the way CRUS/RPS/etc do their pre-factoring.

Regular ECM cannot leverage that special property of mersenne factors, but can still be useful, albeit at much smaller bounds and finding smaller factors than similar P-1 effort will find.

[QUOTE=pepi37;456195]Thanks: so one mystery is over.
Can you solve my next "problem" - every one told next thing: using Pminus1 is same as using one curve to high B1 and B2.
[/quote]
read alpertron's posts in [url]http://mersenneforum.org/showthread.php?t=19605&page=22[/url]
Don't read mine, they were nonsense :razz: .

[quote]
How to setup to use GMP-ECM with same efficiency as Pminus1: to use for example 10 curves but with lower B1 and B2? Using ECM2 mode on Prime95 gives me many times lower factor findings then use P-1. For my purposes it looks like P-1 is winning method, can be ECM2 used for same purpose, similar timings and same number of finding factors?[/QUOTE]
They're different programs with different strengths:
Prime95: fast stage1, small memory requirement for stage2
GMP-ECM: works on non-mersenne numbers and fast stage2 for small exponents (but with higher memory requirements).

It's been a while since I compiled Windows builds, and I just saw there was a new GCC 7.3.0 with the newest Msys2. Compiled the newest SVN 3027:

[URL="http://hoegge.dk/mersenne/gmpecm-svn3027-sandybridge.zip"]gmpecm-svn3027-sandybridge.zip[/URL]

[URL="http://hoegge.dk/mersenne/gmpecm-svn3027-ivybridge.zip"]gmpecm-svn3027-ivybridge.zip[/URL]

[URL="http://hoegge.dk/mersenne/gmpecm-svn3027-haswell.zip"]gmpecm-svn3027-haswell.zip[/URL]

[URL="http://hoegge.dk/mersenne/gmpecm-svn3027-skylake.zip"]gmpecm-svn3027-skylake.zip[/URL] (Not the newest AVX512 Skylakes).

Is it possible to create fat binaries rather than lots of them?

Anything reasonably current available for any of the following?
Arrandale Win7 64 bit
Gainestown Win7 64 bit
Kaby Lake Win10 or 7 64 bit
Westmere-EP Win7 64-bit

I created another automatic script to compile GMP and GMP-ECM for Windows using MSYS2: [URL="http://hoegge.dk/mersenne/gmpecmcompile.zip"]gmpecmcompile.zip[/URL] (289 MB)

You need to use [url]https://7-zip.org[/url] to unpack it. It is just one folder "msys64" with a size of ~1.4 GB unpacked. You should unpack it to C:\ so the folder becomes C:\msys64 (you should always run virus scan on stuff like this to be safe)

Start MSYS2 with the file: C:\msys64\msys2_shell.cmd

To start compiling GMP and GMP-ECM in MSYS2 type:
./gmpecmcompile

Choose your CPU in the menu or the closest one to it, and it should compile both GMP and GMP-ECM, it will take 40+ minutes.



If you don't trust downloading this folder, I can make a guide to install MSYS2 and install the needed packages, and then just link the script itself. Just let me know if I should do this.

Attached is a binary of svn 3038, compiled for the Skylake architecture (not AVX-512) and Windows 64 bit:

Here's windows versions for Zen/Zen+ (Summit Ridge, Raven Ridge, Pinnacle Ridge) and Steamroller (Kaveri), compiled with mingw gcc 9.2. For some reason the binaries also needed a libgmp-10.dll, which I've included.

[QUOTE=ATH;491307]I created another automatic script to compile GMP and GMP-ECM for Windows using MSYS2[/QUOTE]

Wow, thanks!

I put it exactly in the folder like you instructed, started the file you mentioned and executed the command. But he cannot file the "tar" binary for some reason.

Is it feasible to extend the script such that it also grabs the latest GMP sources?

I guess it could, but new GMP versions comes out pretty rarely, it should be using the newest GMP 6.1.2 ? What exact error are you getting?

There seems to be at least a bit of traffic at [url]https://gmplib.org/repo/gmp/[/url].

It says:
[CODE]./gmpecmcompile: Zeile 210: tar: Kommando nicht gefunden.
./gmpecmcompile: Zeile 212: cd: /c/msys64/home/gmp-6.1.2: No such file or directory[/CODE]
This translates to:
[CODE]./gmpecmcompile: line 210: tar: Command not found.
./gmpecmcompile: line 212: cd: /c/msys64/home/gmp-6.1.2: No such file or directory[/CODE]

Actually, [FONT="Courier New"]/usr/bin[/FONT] does not include a [FONT="Courier New"]tar[/FONT] binary.
It cannot [FONT="Courier New"]cd[/FONT] since the call to [FONT="Courier New"]tar[/FONT] never actually created that folder.

I'm not sure why your error is in German, I'm don't think that MSYS2 follows the Windows language?

Did you extract the file [B]gmpecmcompile.zip[/B] with 7-zip to [B]C:\[/B] so the folder is called [B]c:\msys64[/B] ?

The file to start MSYS2 should be: [B]C:\msys64\msys2_shell.cmd[/B] and when you start it, it should look like the screenshot. If you do a "ls -l" the tar file should be right there.

The tar file is located here: [B]C:\msys64\home\gmp-6.1.2.tar[/B]

Could you please type [FONT="Courier New"]which tar[/FONT] on your end? I have a suspicion...

[QUOTE=ATH;530271]I'm not sure why your error is in German, I'm don't think that MSYS2 follows the Windows language?[/QUOTE]
It seems to do that for some reason... (see also in the screenshots):
[CODE]Oliver Kruse@OLLAPTOP MSYS /c/msys64/home
# echo $LANG
de_DE.UTF-8[/CODE]

[QUOTE=ATH;530271]Did you extract the file [B]gmpecmcompile.zip[/B] with 7-zip to [B]C:\[/B] so the folder is called [B]c:\msys64[/B]?[/QUOTE]
Yes, I am using 7-zip 19.00 x64. See the screenshots, the path is correct (I actually extracted it freshly to make those screenshots).

[QUOTE=ATH;530271]The file to start MSYS2 should be: [B]C:\msys64\msys2_shell.cmd[/B] and when you start it, it should look like the screenshot. If you do a "ls -l" the tar file should be right there.[/QUOTE]
Yes, that's not the problem. But when starting the script, it simply cannot find [FONT="Courier New"]tar[/FONT].

[QUOTE=ATH;530271]The tar file is located here: [B]C:\msys64\home\gmp-6.1.2.tar[/B][/QUOTE]
Indeed, see the screenshots.

Ah it was the tar program itself you were missing, I misunderstood.
I had tar.exe in my windows\system32 folder for some reason, so I did not notice it needed to be installed.

You can install it in MSYS2 with the command:
pacman -S tar

I also updated the zip file, so it is already installed.

Nice! This time, I got a working ecm.exe (if I ignore the problem with the missing libgmp-10.dll as seen previously, which I then fixed manually).
[QUOTE=Belteshazzar;526926]For some reason the binaries also needed a libgmp-10.dll.[/QUOTE]

You can find libgmp-10.dll and any other needed files in the [I]C:\msys64\mingw64\bin[/I] folder. You can add that folder to the PATH variable, or copy just that file to another folder in your PATH variable or to the folder with ecm.exe.



Anyone know why libgmp-10.dll that comes with MSYS2 is needed for MSYS2 programs? Programs still uses the GMP version you compiled yourself, you can check by making a C/C++ program printing the GMP version used:
printf("%i %i %i\n",__GNU_MP_VERSION,__GNU_MP_VERSION_MINOR,__GNU_MP_VERSION_PATCHLEVEL);

and it shows it actually uses the version you compiled yourself.

Here is even an example of a program not using GMP at all that requires libgmp-10.dll:
[url]https://stackoverflow.com/questions/6951938/libgmp-10-dll-is-missing[/url]

JIC, if anyone have 32bit static build for Linux, please share. Can't compile it by myself due to many compiler errors.

There is a 32-bit version compiled for Ivy Bridge in this post:

[url]https://www.mersenneforum.org/showpost.php?p=441992&postcount=439[/url]