Links to Precompiled GMP-ECM versions

[wombatman]

Originally Posted by xilman

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 make ecm-params between make and make check for (near) optimal performance.

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

[xilman]

Originally Posted by wombatman

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

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

[wombatman]

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

[ATH]

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: gmpecm-compile.zip (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:\ (http://www.7-zip.org).
You can 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.

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.


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: compile-readme.txt

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

[henryzz]

Originally Posted by Brian Gladman

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.

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.

[xilman]

Originally Posted by henryzz

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.

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.)

[Brian Gladman]

Originally Posted by henryzz

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.

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.

[bdodson]

Originally Posted by ATH

Haswell: GMP-ECM7 SVN 2840 with GMP 6.1.0: gmpecm7-svn2840-haswell.zip

Sandy Bridge: GMPECM7 SVN 2840 with GMP 6.1.0: gmpecm7-svn2840-sandybridge.zip

I still had to comment out ...

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

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

[ATH]

Here is a newer one: SVN 2968 compiled on Aug 2nd: gmpecm7-svn2968-haswell.zip

I can compiled the newest one if needed.

[Gordon]

Originally Posted by ATH

Here is a newer one: SVN 2968 compiled on Aug 2nd: gmpecm7-svn2968-haswell.zip

I can compiled the newest one if needed.

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

[ATH]

Originally Posted by Gordon

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

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