GMP-ECM 6 released

[akruppa]

Hi,

we have just released version 6 of GMP-ECM. The announcement and download links are found at

http://www.loria.fr/~zimmerma/records/ecm-6.0.html

Enjoy!

This thread can be used for discussion of the new version, such as questions about compiling, new features, choosing good parameters etc.

Alex

Update (2005-03-13): The page has moved to http://www.komite.net/laurent/soft/ecm/ecm-6.0.html

[R.D. Silverman]

Originally Posted by akruppa

Hi,

we have just released version 6 of GMP-ECM. The announcement and download links are found at

http://www.loria.fr/~zimmerma/records/ecm-6.0.html

Enjoy!

This thread can be used for discussion of the new version, such as questions about compiling, new features, choosing good parameters etc.

Alex

Nice!

If anyone builds a cygwin executable, please let me know. I do not have the
tools to do so.

[akruppa]

I've installed the MinGW compiler as a cross-compiler on my Linux home box, I can make Pentium-3 binaries for Windows with it as soon as I get home. But I'm certainly interested in hearing about success (or failure!) stories compiling GMP-ECM 6 for Windows using various environments such as Cygwin, SFU etc.

Alex

[JHansen]

Originally Posted by akruppa

But I'm certainly interested in hearing about success (or failure!) stories compiling GMP-ECM 6 for Windows using various environments such as Cygwin, SFU etc.

I've just installed MinGW and MSYS, and here GMP-ECM 6 compiled without problems.

Q: Does the binaries made with MinGW/MSYS require a .dll file of some sort, or can I use the binaries on a Windows box that hasn't got MinGW/MSYS installed?

--
Cheers,
Jes

[smh]

Just managed to get a cygwin version to run but don't know anything about different processor options, and haven't done any testing. I'll see tomorrow.

[akruppa]

As far as I know, binaries built with MinGW don't require a special dll to run under Windows.

I've previously built GMP under MinGW with --disable-static --enable-shared which apparantly makes a dll suitable for linking with VC, and the ecm binary linked against that of course wanted the dll around to run.

I've now built GMP again with no special parameters and apparantly have a static library. Building ecm against it seems to work and it runs in Wine without any extra dlls.

Unfortunately the ecm.exe in Wine is about twice as slow as the native Linux build - I hope that's merely because of Wine.

I'm putting the binary (optimized for Pentium 3) online at http://home.in.tum.de/~kruppa/ecm6_p3.zip

Timings of the native Linux version with B1=1M on Kevin Hare's c301 are
Step 1 took 387910ms
Step 2 took 130220ms
Maybe a Windows user with a Pentium-3 could compare these to check if this binary is about as fast as it ought to be?

Alex

[Mystwalker]

If I don't forget it, I can test it tomorrow with a 1 GHz P3. What is the clock rate of your P3?

btw.:
I'd like to have windows versions for P4 and Pentium-M.
If someone can point me to a comprehensible manual for this, I can do it myself the next days...

[akruppa]

My P3 is 500 MHz.

Maybe Jes can give step-by-step instructions how to install MinGW, MSYS and compile gmp-ecm? I can't try as I don't have Windows anywhere.

Alex

[rogue]

I can compile ecm on a PowerPC G5, but tune does not link. I get the following error:

gcc -g -O2 -o tune mpmod.o tune.o mul_lo.o libecm.a -lgmp -lm
ld: Undefined symbols:
___ecm_stderr
___ecm_stdout
make: *** [tune] Error 1

[JHansen]

Originally Posted by akruppa

Maybe Jes can give step-by-step instructions how to install MinGW, MSYS and compile gmp-ecm?

Sure!

1) Download the current Mingw http://prdownloads.sf.net/mingw/MinG...1.exe?download
and MSYS http://prdownloads.sf.net/mingw/MSYS...0.exe?download

1.5) I also downloaded the MinGW Runtime thingy's. Don't know if they are nessesary, but they won't hurt.

2) I made a folder called GNU and installed MinGW in c:\GNU\MinGW

2.5) I extracted the new runtime stuff and just overwrote what has there

3) I installed MSYS in c:\GNU\msys

Now you get an icon on the desktop where you can start the MinSys. Do this, because is creates your home folder. Then exit it again.

4) Download gmp and place it in your newly created home folder. (For me is was called C:\GNU\msys\1.0\home\Jes )

5) Start the MinSys up again from the desktop and type

gunzip gmp-4.1.4.tar.gz
tar -xvf gmp-4.1.4.tar
cd gmp-4.1.4
./configure
make install

Then GMP installs (takes about two or three cups of cofee ).

6) Afterwards, download ECM-GMP 6 from http://home.in.tum.de/~kruppa/ecm-6.0.tar.gz and place the file in your home folder.

7) In the "home" directory (type cd ~ RETURN to get there) type
gunzip ecm-6.0.tar.gz
tar -xvf ecm-6.0.tar
cd ecm-6.0
./configure --with-gmp=/usr/local
make

8) Look and behold! 4 executables have appeared, and the one to look out for is ecm.exe

Have fun

--
Cheers,
Jes

[BotXXX]

If you want to use MinGW/MSYS to compile GMP-ECM for an other processor you will have to compile both GMP 4.1.4 and GMP-ECM 6.0 with the same command.

the compiler should have have extra arguments like
gcc ........ -mcpu=pentiumpro -march=pentiumpro
... == other arguments and such

GCC manual
http://gcc.gnu.org/onlinedocs/

more about processor type and such.
http://gcc.gnu.org/onlinedocs/gcc-3....002d64-Options

[schickel]

Alex,
I don't think it's just Wine....my run was even slower than yours.

Originally Posted by akruppa

Unfortunately the ecm.exe in Wine is about twice as slow as the native Linux build - I hope that's merely because of Wine.

(...snip...)

Timings of the native Linux version with B1=1M on Kevin Hare's c301 are
Step 1 took 387910ms
Step 2 took 130220ms
Maybe a Windows user with a Pentium-3 could compare these to check if this binary is about as fast as it ought to be?

Alex

Here's a log from my system. The only things running in the background that should impact the performance were a downloader (GetRight) and the modem drivers (@#$% winmodems.....).

C:\ECM>ecm6_p3 1e6 <c301.txt
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 3831565799519436303487742350308454794716675157894098584352121252
26351002461180590732059237465443318602051710866546714347193403583939549624335332
12457600196112076644876654207767427267797808629935905445969160204965109807400679
01995154639576852120198067468078357247366647828551141390739467161074462608561 
(301 digits)
Using B1=1000000, B2=839549779, polynomial Dickson(3), sigma=1461611586
Step 1 took 1082272ms
Step 2 took 280112ms

Mon 02-28-2005   17:30
C:\ECM>

How much memory do you have? I'm running a P3-500 w/128MB, but it didn't look like any extra disk activity was going on.

Later,
Frank

[Joe O]

Much slower and the defaults are not the same as ECM503

C:\Program Files\ECM5>ecm6_p3 11000000 0
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Using B1=11000000, B2=0, polynomial x^1, sigma=4129033646
Step 1 took 702108ms

C:\Program Files\ECM5>ecm5_sse 11000000 0
GMP-ECM 5.0.3 [powered by GMP 4.1.2] [ECM]
Using B1=11000000, B2=25577181640, polynomial Dickson(12), sigma=135062192
Step 1 took 506531ms
Step 2 took 257407ms

[Mystwalker]

What happens when you don't enter the last "0"?
And what kind of CPU are you using?

[Joe O]

Yes, definitely much slower in Stage1, slightly faster in Stage2. Although it now has 512MB more than it did before, which might account for the faster times in Stage2. If it won't run well on this machine (1GB 2.4MHz) it won't run well at all.

[Joe O]

Originally Posted by Mystwalker

What happens when you don't enter the last "0"?
And what kind of CPU are you using?

AMD64 XP PRO 1GB 2.4MHz
Before 0 defaulted to 25577181640. Even if it works without the last 0, it is a change from before.

[rogue]

Are you certain that GMP built without any problems? I had a problem where GMP-ECM 6 was half the speed of GMP-ECM 5, until I realized that GMP-ECM 6 was including a version of libgmp that was not built on my PC (it linked with a libgmp that was installed by CygWin, which was not optimized for a P4). It appears that you are in Windows and not Cygwin. Did GMP get statically linked with GMP-ECM 5 and GMP-ECM 6 is using a dll or is it possible that the GMP 4.1.4 dll is not the P4 version?

[Joe O]

I am using Alex Kruppa's binary.

Mystwalker,
Your guess was correct:

C:\Program Files\ECM5>ecm6_p3 -dickson 12 11000000
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Using B1=11000000, B2=25577181640, polynomial Dickson(12), sigma=4206889818
Step 1 took 702494ms
Step 2 took 210873ms

Isn't it awful early in the morning where you are? It's very late at night here.

[Joe O]

Botxxx's P3 binary, is the fastest of 5 ECM503 binaries that I benchmarked on this machine.

C:\Program Files\ECM5>ecm503_P3 11000000 0
GMP-ECM 5.0.3 LucasProject_MinGW [powered by GMP 4.1.4] [ECM]
Using B1=11000000, B2=25577181640, polynomial Dickson(12), sigma=2782766705
Step 1 took 514141ms
Step 2 took 258468ms

Is a run I just completed. The prior times with only 512MB were:

_sse
Step 1 took 506531ms
Step 2 took 257407ms
_SSE2
Step 1 took 618219ms
Step 2 took 330656ms
_K7
Step 1 took 509187ms
Step 2 took 259016ms
_P4
Step 1 took 629781ms
Step 2 took 336766ms
_P3
Step 1 took 506610ms
Step 2 took 257765ms
_PM
Step 1 took 507688ms
Step 2 took 256500ms
_sse new CYGWIN1 DLL
Step 1 took 505094ms
Step 2 took 256562ms
_SSE2 new CYGWIN1 DLL
Step 1 took 619063ms
Step 2 took 330922ms

So stage1 has gone from bad to worse. It was twice the time of Prime95, now it is three times the time of Prime95. Can't I convince someone to incorporate Prime95's stage1 in ECM6 or ECM7? Or incorporate ECM6 stage2 in Prime95?
Running one program for stage 1, extracting the results and feeding them to another program for stage 2 is a KLUGE, at best.

[Mystwalker]

Originally Posted by Joe O

Isn't it awful early in the morning where you are? It's very late at night here.

Almost 6am, yes. I just finished a paper that was due at midnight...
Yesterday, it was 10am before I went to bed - somehow, I'm more productive at these times than during the day (omitting that 10am is already "during the day"...).

Originally Posted by Joe O

Running one program for stage 1, extracting the results and feeding them to another program for stage 2 is a KLUGE, at best.

Assuming the integration is quite easy, I'd also say that it is a bit more comfortable. In addition, the computation can be immediately stopped once a factor is found. Right now, I have already done a lot of stage1 bounds, which are possibly wasted - although the factor would more than compensate.

Originally Posted by rogue

Did GMP get statically linked with GMP-ECM 5 and GMP-ECM 6 is using a dll or is it possible that the GMP 4.1.4 dll is not the P4 version?

I gonna do some testing myself soon. Let's see if we can get this version optimized so that it's wise to use it.

[akruppa]

I screwed up the cross-compilation. I had simply followed the instructions on the MinGW pages to build a cross-compiler which gave me tools called i586-mingw32-gcc etc, and had to use --host=i586-mingw32 for configuring GMP so it would find the cross compiler tools. Kinda obviously that optimized GMP for i586 (plain Pentium), not Pentium-3. After linking the cross-gcc and binutils to pentium3-mingw32-gcc etc, I could build GMP properly optimized for Pentium-3 and the binary is as fast in Wine as the native Linux build is (in fact, slightly faster, oddly enough).

The binary at http://home.in.tum.de/~kruppa/ecm6_p3.zip is updated.

Alex

[Istari]

Hey everyone,

I was just playing around with the new version of gmp-ecm and my results are a little bit wierd...
I am working on a C130 and did already a bunch of work with gmp-ecm-5.0.3, the time it takes for one run is almost constant and an example output is:

GMP-ECM 5.0.3 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462988, polynomial Dickson(30), sigma=530681099
Step 1 took 1253360ms
Step 2 took 859190ms

When I use gmp-ecm-6.0 the time is:

GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462987, polynomial Dickson(12), sigma=700709145
Step 1 took 3596705ms
Step 2 took 993606ms

So version 6.0 is 3 times slower in Step 1 and a little bit slower in step 2 compared to version 5.0.3 on my computer.
I did multiple runs with gmp-ecm-6.0 but got the same results :-(

My computer is a laptop with Gentoo Linux, 1 Gb memory and has a Pentium M 1.6 GHz.
Did I do anything wrong or is the newer version just slower on a Pentium M?

Thanks, keep up the great work,

Joppe Bos

[akruppa]

The new version should not be slower. The slowdown you see looks suspiciously like the one I got from compiling GMP for the wrong cpu type. Can you check with
grep CFLAGS config.log
in the GMP source directory that "-march=pentiumpro" is set, and that the link mpn/addmul_1.asm points at x86/p6/aorsmul_1.asm?

That's what is used when optimizing for Pentium-3, and I think the Pentium-M will use the same settings.

Alex

[trilliwig]

Originally Posted by Istari

My computer is a laptop with Gentoo Linux, 1 Gb memory and has a Pentium M 1.6 GHz.
Did I do anything wrong or is the newer version just slower on a Pentium M?

It shouldn't be... here are my times on a laptop with WinXP-SP2, 1GB memory, and a Pentium M 1.8 GHz:

$ time ./ecm6 -v -sigma 1494226208 43000000 <cp58c133.txt
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 2648620458075372640494115621952835065077601496753193938561477911306072529232744531715396496605088997490602560473145406713491597980337 (133 digits)
Using MODMULN
Using B1=43000000, B2=178426462987, polynomial Dickson(12), sigma=1494226208
Step 1 took 1087133ms
B2'=198673134660 k=2 b2=99324825600 d=1021020 d2=19 dF=92160, i0=24
Expected number of curves to find a factor of n digits:
20      25      30      35      40      45      50      55      60      65
2       5       15      56      252     1321    7771    51303   372940  2933038
Initializing tables of differences for F took 276ms
Computing roots of F took 21261ms
Building F from its roots took 42201ms
Computing 1/F took 24940ms
Initializing table of differences for G took 405ms
Computing roots of G took 16678ms
Building G from its roots took 41725ms
Computing roots of G took 16637ms
Building G from its roots took 41463ms
Computing G * H took 14647ms
Reducing  G * H mod F took 21293ms
Computing polyeval(F,G) took 99372ms
Step 2 took 343201ms
Expected time to find a factor of n digits:
20      25      30      35      40      45      50      55      60      65
47.36m  1.89h   5.86h   22.18h  4.18d   21.87d  128.65d 2.33y   16.91y  133.03y
********** Factor found in step 2: 2461933169125535769713639083639611578977677394990241
Found probable prime factor of 52 digits: 2461933169125535769713639083639611578977677394990241
Probable prime cofactor 1075829551870470595060810398407988637537982828486834255418641410187071177046512657 has 82 digits

real    23m52.881s

The same curve under ECM5 for comparison:

$ time ./ecm -v -sigma 1494226208 43000000 <cp58c133.txt
GMP-ECM 5.0.3 [powered by GMP 4.1.4] [ECM]
Input number is 2648620458075372640494115621952835065077601496753193938561477911306072529232744531715396496605088997490602560473145406713491597980337 (133 digits)
Using MODMULN
Using B1=43000000, B2=178426462988, polynomial Dickson(30), sigma=1494226208
a=2044392238332698121322738486557323681208604686629555405570621086536643642366335599623133015169037983057197716647669450329550513375225
starting point: x=1342711309863495521496567740925717557242596291256037082028227446433306897847705969711253120357239284875120328375378641788469864004116
Step 1 took 1106290ms
x=1276547856758767802462442602964713422150236882996835365391074274093286421894497866078224898174201933610645427339027700297539927882699
B2'=180748618050 k=5 b2=36141276990 d=603330 dF=59904
Initializing table of differences for F took 261ms
Computing roots of F took 38626ms and 18099720 muls
Building F from its roots took 34560ms and 9064745 muls
Computing 1/F took 40558ms and 10925756 muls
Initializing table of differences for G took 1131ms
Computing roots of G took 23103ms and 10782720 muls
Building G from its roots took 33989ms and 9064745 muls
Computing roots of G took 23033ms and 10782720 muls
Building G from its roots took 33859ms and 9064745 muls
Computing G * H took 24355ms and 5471879 muls
Reducing G * H mod F took 46847ms and 10943755 muls
Computing roots of G took 23054ms and 10782720 muls
Building G from its roots took 33848ms and 9064745 muls
Computing G * H took 24055ms and 5471879 muls
Reducing G * H mod F took 46677ms and 10943755 muls
Computing roots of G took 23043ms and 10782720 muls
Building G from its roots took 33869ms and 9064745 muls
Computing G * H took 24054ms and 5471879 muls
Reducing G * H mod F took 46617ms and 10943755 muls
Computing roots of G took 23044ms and 10782720 muls
Building G from its roots took 33858ms and 9064745 muls
Computing G * H took 24065ms and 5471879 muls
Reducing G * H mod F took 46657ms and 10943755 muls
Computing polyeval(F,G) took 185256ms and 54515940 muls
Step 2 took 869450ms for 257506022 muls
********** Factor found in step 2: 2461933169125535769713639083639611578977677394990241
Found probable prime factor of 52 digits: 2461933169125535769713639083639611578977677394990241
Probable prime cofactor 1075829551870470595060810398407988637537982828486834255418641410187071177046512657 has 82 digits
Report your potential champion to Richard Brent <rpb@comlab.ox.ac.uk>
(see ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Richard.Brent/champs.txt)

real    32m55.771s

Both executables were compiled under MinGW-3.2.0-rc-3 and MSYS-1.0.10. I thought the different polynomials might be the culprit but it looks like no.

Also, Step1 seems to be consistently ~20 seconds faster in gmp-ecm 6.0 than gmp-ecm 5.0.3 on a variety of Pentium 3s I have from 450MHz to 1400MHz. What's up with that?

I've also done a successful compile and 'make check' of gmp-ecm 6.0 on Cygwin under WinXP-SP2 on an Athlon-MP 1900+.

[Phil MjX]

Hi !

Thanks for releasing gmp-ecm 6.0 !

I have compiled gmp-ecm 6.0 under cygwin with the standard, downloaded gmp binaries (not optimized for my duron) and following the "install" steps (./configure, make and make check) and I obtain good results :

(gmp-ecm 5.0.3 binary from this forum, compiled for K7)
GMP-ECM 5.0.3 LucasProject_MinGW [powered by GMP 4.1.4] [ECM]
Input number is 1563701566304085255138148773628369632030663508320068005582518155758069482776837373734452501544559509452168893416963 (115 digits)
Using B1=3000000, B2=4016636514, polynomial Dickson(12), Using B1=3000000, B2=4016636514, polynomial Dickson(12), sigma=1229632516
Step 1 took 44828ms
Step 2 took 38281ms

(gmp-ecm 6.0 binary without optimizations i.e. for 686)
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 1563701566304085255138148773628369632030663508320068005582518155758069482776837373734452501544559509452168893416963 (115 digits)
Using B1=3000000, B2=4016636513, polynomial Dickson(6), sigma=2755378239
Step 1 took 43984ms
Step 2 took 26485ms

Very very good !!, 13 seconds gain

I should mention some problems indeed :

When recompiling gnu-mp with athlon optimizations under cygwin then compiling gmp-ecm with the --with-gmp=<gmpdir>
option, make check immediately fails... I have deleted, re-installed cygwin and gmp-ecm from scratch and it works.

I obtain a seg. fault with the tune program under cygwin

I obtain a weird coutput with the -I option after a few steps : looking like only step 1 is done. (using ./ecm -inp <filename> -I 10 -v -c 110 2000 commandline). This is reproductible in my computer (at B1=122005)...

Using MODMULN
Using B1=108335, B2=108335-119805, polynomial x^1, sigma=1169435360
Step 1 took 1578ms
B2'=124560 k=2 b2=8960 d=240 d2=7 dF=32, i0=445
Expected number of curves to find a factor of n digits:
20	25	30	35	40	45	50	55	60	65
80	944	14750	289846	6915141	1.9e+08	1.2e+10	8.5e+11	Inf	Inf
Initializing tables of differences for F took 0ms
Computing roots of F took 0ms
Building F from its roots took 16ms
Computing 1/F took 0ms
Initializing table of differences for G took 0ms
Computing roots of G took 0ms
Building G from its roots took 0ms
Computing roots of G took 0ms
Building G from its roots took 0ms
Computing G * H took 0ms
Reducing  G * H mod F took 0ms
Computing polyeval(F,G) took 0ms
Step 2 took 16ms
Expected time to find a factor of n digits:
20	25	30	35	40	45	50	55	60	65
2.13m	25.08m	6.53h	5.35d	127.58d	9.76y	631.03y	42718y	Inf	Inf
Using MODMULN
Using B1=122005, B2=122004-119805, polynomial x^1, sigma=3629317804
Step 1 took 1781ms
Using MODMULN
Using B1=136280, B2=136280-119805, polynomial x^1, sigma=3851891115
Step 1 took 1985ms
Using MODMULN
Using B1=151189, B2=151188-119805, polynomial x^1, sigma=634600321
Step 1 took 2218ms
Using MODMULN
Using B1=166758, B2=166758-119805, polynomial x^1, sigma=3036624988
Step 1 took 2422ms
Using MODMULN
Using B1=183018, B2=183017-119805, polynomial x^1, sigma=1125996453
Step 1 took 2672ms
Using MODMULN
Using B1=199998, B2=199998-119805, polynomial x^1, sigma=741675635
Step 1 took 2922ms
Using MODMULN
Using B1=217731, B2=217731-119805, polynomial x^1, sigma=151496766
Step 1 took 3172ms

And a last point, which is a request : can you add a curve counter in the output so that, when I look at the program coming back home, I know the amount of work done...This exists in gmp-ecm 5.0 but has disappeared in this version...

Thanks a lot again.
Best regards.

Philippe.

[Istari]

Thnx for the fast replies! I recompiled GMP and everything works fine now (it is still very strange I got these wierd results because I used a self-compiled version of GMP already). Here are my results:

GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462987, polynomial Dickson(12), sigma=1634402947
Step 1 took 1244667ms
Step 2 took 349449ms

MP-ECM 5.0.3 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462988, polynomial Dickson(30), sigma=530681099
Step 1 took 1253360ms
Step 2 took 859190ms

So step 1 is roughly the same but step 2 is know almost 2.5 times faster

Thanks again for the help, this release will certainly speed things up.

Joppe Bos

[Phil MjX]

Hi !

Concerning my last post, I understand what happens :

I obtain a weird coutput with the -I option after a few steps : looking like only step 1 is done. (using ./ecm -inp <filename> -I 10 -v -c 110 2000 commandline). This is reproductible in my computer (at B1=122005)...

In fact, While the B1 bound is increasing at each run, the B2 bound stays at 119805 and doesn't increase with B1 !!! with gmp-ecm 5.1beta, using this option, B2 grows with B1, that's why I didn't think about this for v6.0 problem!

IMHO, the -I function seems very very less usefull if only the B1 bound is increasing....I use this option to test new composites from home primes sequences, with the -t option, starting at low B1 then increasing up to 1e6.

Is it a bug? If not, I can't understand the use of increasing only B1 and not B2.

Thanks.
Philippe.

[akruppa]

Yes, that's a bug. To be fixed...

Phil, there's a patch for a tune-related problem at http://www.loria.fr/%7Ezimmerma/records/ecm-6.0.html, does that fix the segfault?

And I'll ask PaulZ about the loop counter.

Alex

[Joe O]

Using the new binary:

C:\Program Files\ECM5>ecm6_p3 -dickson 12 11000000
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]

Using B1=11000000, B2=25577181640, polynomial Dickson(12), sigma=195951590
Step 1 took 511909ms
Step 2 took 170429ms


Step 1 much closer to 5.03
Step 2 much faster than 5.03

[Phil MjX]

Hi Alex,

Phil, there's a patch for a tune-related problem at http://www.loria.fr/%7Ezimmerma/records/ecm-6.0.html, does that fix the segfault?

No, unfortunately, patching the sources doesn't prevent the segfault :

Exception: STATUS_ACCESS_VIOLATION at eip=10413D4B
eax=10030698 ebx=00000004 ecx=00000004 edx=AEDD179C esi=0022EDE0 edi=00000001
ebp=0022EDF8 esp=0022EDBC program=C:\cygwin\home\Professeur Slump\ecm-6.0\execs\tune.exe, pid 1536, thread main
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EDF8  10413D4B  (10030698, 100305D8, 10030678, 10030638)
0022EE28  00401708  (0022EE90, 0022EEEC, 0022EEF8, 0022EEA0)
0022EE58  00402E52  (0022EE90, 0022EF90, 0022EEA0, 0022EEA0)
0022EF28  00403227  (0022EFA0, 0022EF90, 0022EF80, 00000003)
0022EFC8  004035A6  (00000001, 61792CE4, 100300A8, 0022F020)
0022F008  61006145  (0022F020, 0022F31C, 77F54EAC, 0022F340)
0022FF88  61006350  (00000000, 00000000, 00000000, 00000000)
End of stack trace

Thanks for the answer.
Bye.

Philippe.

[Mystwalker]

I also got it compiled and tested a little bit.

On a 1,7 GHz Pentium-M, I get the following times for the c301:

C:\Programme\primes\gmp-ecm\gmp-ecm 6.0>ecm 1e6 < c301.txt
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 3[...]1 (301 digits)
Using B1=1000000, B2=839549779, polynomial Dickson(3), sigma=850545448
Step 1 took 112669ms
Step 2 took 35404ms

So, clock for clock, Step 1 is about as fast as the 500 MHz P3, Step 2 seems to be ~10% faster.
Compared to gmp-ecm5, Step 1 is 2-3% faster (for B1=11e6), Step 2 is one third faster.

[Mystwalker]

Concerning JHansen's compilation manual (which really helped a lot!):

Originally Posted by JHansen

1.5) I also downloaded the MinGW Runtime thingy's. Don't know if they are nessesary, but they won't hurt.

They aren't needed.

5) Start the MinSys up again from the desktop and type

gunzip gmp-4.1.4.tar.gz
tar -xvf gmp-4.1.4.tar

Just for simplification:

tar -zxvf gmp-4.1.4.tar

does this in one step.

7) In the "home" directory (type cd ~ RETURN to get there) type
[...]
./configure --with-GMP=/usr/local

Note that it has to be --with-gmp (lower case)

[dave_dm]

Originally Posted by Mystwalker

Compared to gmp-ecm5, Step 1 is 2-3% faster (for B1=11e6), Step 2 is one third faster.

The most important thing about the improved stage 2 is that it's now asymptotically faster, i.e. the larger B1 you use, the better the gain. I have a (pretty) graph of this somewhere.

Dave

[Mystwalker]

One strong argument for including prime95's routines for step1:
ECMNet!

Setting up a an ECMNet server is a no-brainer - and when only gmp-ecm is needed, e.g. the Cunningham numbers can be done this way.


I also went through the README file.

It was already quite informative (I possibly understood the technique behind ECM now!), but nevertheless even improved a lot!
Quite interesting are the changed bounds for P-1 and P+1 in the step-by-step checklist.

I found some possible issues, though:

5. "common" arithmetic expressions ( * / + - % ) period . can also be used in

I have to admit that the "period . " confuses me a bit. I know what it should mean, but I can't figure out how it does this...

The ecm program automatically selects what he thinks is the best

he thinks --> it thinks

After all, gmp-ecm doesn't live... does it?

The "tune" program helps you to determine the optimal threshold for
your computer. After compiling it with "make tune", type "./tune"
and it will display timings for each method (mpzmod, modmuln, redc)

I haven't put much time into this so far, only a first testing.

1. It seems like tune is already compiled (at least after the compilation using "make")
2. There was no output at the beginning of the execution. I've let it run maybe 5 minutes and killed it then. When this is typical behaviour, it could be included in the readme - a better way could be to let tune print some lines at the beginning
3. How long can I expect it to run?

But once again:
Very good manual.

[frmky]

I compiled Pentium 4 and Athlon versions using Cygwin. Almost everything seems to work ok. As others have reported, step 1 is slight faster, and step 2 is much faster. The tune program works fine...no segfaults...and I used its results to recompile. Note that tune outputs two lines immediately, the default thresholds, then starts its calculations, so if you see nothing on the screen, there's a problem. I also ran tune2 and tried to add its results as a define, but got a bunch of warnings about things being redefined, so I gave up on that.

The one problem I did have involved errors due to the lack of docbook. I commented out the ecm.1 section at the bottom of Makefile, and these errors went away. Note that although the error did not stop me from compiling all of the programs, it did stop me from running make check.

Greg

[rogue]

Originally Posted by rogue

I can compile ecm on a PowerPC G5, but tune does not link. I get the following error:

gcc -g -O2 -o tune mpmod.o tune.o mul_lo.o libecm.a -lgmp -lm
ld: Undefined symbols:
___ecm_stderr
___ecm_stdout
make: *** [tune] Error 1

One of the available patches fixes this problem.

[akruppa]

A patch for the broken -I option is available at the GMP-ECM 6.0 page now.

Alex

[error404]

Alex,

I installed ecm-6.0 on my Apple Titanium laptop. This
uses a PowerPC-G4.

g4-867:~/ecm-6.0 k5gj$ uname -a
Darwin g4-867.local 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power Macintosh powerpc
g4-867:~/ecm-6.0 k5gj$


g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$ patch -s < ecm60.patch2
g4-867:~/ecm-6.0 k5gj$ patch -s < ecm60.patch3
g4-867:~/ecm-6.0 k5gj$ patch -s < ecm60.patch4
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$ ./configure CC=/usr/local/bin/gcc34 --with-gmp=/usr/local/include
checking for a BSD-compatible install... /usr/bin/install -c
|
|
config.status: creating Makefile
config.status: executing depfiles commands
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$ make
|
|
/usr/bin/ld: Undefined symbols:
___ecm_stderr
___ecm_stdout
collect2: ld returned 1 exit status
make: *** [tune2] Error 1
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$

Obviously,
# make check
will not work.

OTOH,
# ./test.pm1 ./ecm
# ./test.pp1 ./ecm
# ./test.ecm ./ecm
all work correctly.

Times for 5.0.3
pm1 = 01m40s
pp1 = 00m17s
ecm = 14m53s

Times for 6.0
pm1 = 01m29s
pp1 = 00m16s
ecm = 11m01s


Then, using the c130 from the mersenne forum,

g4-867:~/ecm-5.0.3 k5gj$
g4-867:~/ecm-5.0.3 k5gj$ echo 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 | ./ecm 43e6
GMP-ECM 5.0.3 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462988, polynomial Dickson(30), sigma=1052566873
Step 1 took 3405590ms
Step 2 took 2304090ms
g4-867:~/ecm-5.0.3 k5gj$
g4-867:~/ecm-5.0.3 k5gj$

g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$ echo 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 | ./ecm 43e6
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 7386280416375159470194506098113360298863220600336512742717699632402022660340244676943771506127650491975571648037849677129938071271 (130 digits)
Using B1=43000000, B2=178426462987, polynomial Dickson(12), sigma=2612864033
Step 1 took 3402900ms
Step 2 took 904090ms
g4-867:~/ecm-6.0 k5gj$
g4-867:~/ecm-6.0 k5gj$


Tom

[akruppa]

Hmm, patch2 was supposed to fix that. I'll inform PaulZ.

Alex

[Mystwalker]

After some working with gmp-ecm6, I got some more questions (Alex, I hope you still have a life besides post-v6 work):


- Is it possible to display the "expected number of curves" right at the start and not only after stage1?

- Concerning the estimated time to finish "certain digits": When I resume, stage1 is not included in this calculation. Maybe there could be a parameter option specifying this?

- Is there a general acceptance for the changed "ECM_EXTRA_SMOOTHNESS" (12 --> 23.4)? After all, for B1=11e6, B2=100*B1, expected curves were reduced to 8943 instead of 10600.

- Sometimes, "stage 2" is called "step 2". As the k parameter splits stage 2 in k steps, I think there should be a clear distinction between these terms.

- In the following output:

Using B1=1, B2=11000000-30117862320, polynomial Dickson(12), sigma=6481293096446123
Step 1 took 0ms
B2'=36025369380 k=2 b2=18010792800 d=420420 d2=17 dF=40320, i0=10

What is B2'? Is this the B2 bounds that are really taken? Maybe it should be mentioned even when the -v parameter hasn't be issued?

- It seems like now, clock time is measured instead of CPU time. Is there a possibility to get CPU time back, because it eases figuring out optimal bounds?

- When resuming a prime95 stage1, I get the number displayed in hex format. Is there an option to convert it to decimal prior to displaying?

- Just saw on the help screen:

-base2 n force base 2 mode with 2^n+1 (n>0) or 2^n-1 (n<0)

The last should also be n>0, I suppose?

- From the Readme file:

2. Comments can be placed in the file. The C++ "one line comment" //
is used. Everything after the // on a line (including the //) is ignored.
Warning: no input number should appear on such a comment line.

Just for clarification: Even in front of "//", there should be no input number?



P.S.:
I fear that all these postings sound like we (at least I) don't appreciate this version. I bet we all do! Thanks a lot to all contributors!
Most of these suggestions weren't even thought of without gmp-ecm6, so I count them as an expression of appreciation.

[akruppa]

Originally Posted by trilliwig

Also, Step1 seems to be consistently ~20 seconds faster in gmp-ecm 6.0 than gmp-ecm 5.0.3 on a variety of Pentium 3s I have from 450MHz to 1400MHz. What's up with that?

Not sure... afaik Paul Zimmermann improved the modular arithmetic a little since 5.0, so stage 1 is a little faster. But the time saving should depend on both B1 and the size of the input number. Is it really constantly 20s?

Originally Posted by Phil MjX

And a last point, which is a request : can you add a curve counter in the output so that, when I look at the program coming back home, I know the amount of work done...This exists in gmp-ecm 5.0 but has disappeared in this version...

The handling of the looping code has got some massive changes since 5.0, apparantly the curve counter output got lost somewhere. I'm attaching a patch that brings it back.

Originally Posted by Mystwalker

One strong argument for including prime95's routines for step1:
ECMNet!

That's a good point. Support for DWT will eventually come to GMP-ECM, but in order to match Prime95's speed we'll have to make quite a few changes to the stage 1 code. Prime95 ECM is entirely built around the DWT multiplication and heavily optimized for it, the elliptic curve arithmetic there is arranged to reduce the required numbers of transforms as far as possible. In GMP-ECM, we only optimized for the number of multiplies so far. Adding the DWT to the mpres layer would not be hard, but making stage 1 as fast as in Prime95 will not be easy.
It'll happen eventually.

And thanks for your comments on the README file! The period "." is synonymous to "*", it does multiplication. Some tables of known factors seperate the factors by periods, this makes it easier to copy-and-paste known factors into expressions. We'll fix "he" to "it", though gmp-ecm sometimes seems to have a life of it's own! :)
My cross-compiled tune program seems to run fine in Wine, maybe Windows buffers the output. Can you try running it for a little longer? Tune can take quite a while to finish.

Originally Posted by frmky

The one problem I did have involved errors due to the lack of docbook.

The man page is packaged with GMP-ECM 6, converting it from the XML source should not be neccessary. Maybe un-taring did not preserve the time stamps of the files, so ecm.xml and ecm.1 might have the same modification time and make tries to convert again. If that's the case, a "touch ecm.1" should help.

Alex

[Mystwalker]

Originally Posted by akruppa

My cross-compiled tune program seems to run fine in Wine, maybe Windows buffers the output. Can you try running it for a little longer? Tune can take quite a while to finish.

Oops, my bad. I started it under Msys, not Windows...
It works now.

[frmky]

Hi,

I successfully compiled a x86-64 version using Linux for my Opteron, and it works great. Much faster than the 32-bit version. Has anyone been able to compile one for Windows x64? Is there even a version of the GMP library compiled for Win x64? I keep one of my Athlon64 computers in Windows, and that'd certainly speed up the processing! :-)

Greg

[rogue]

Originally Posted by akruppa

Hmm, patch2 was supposed to fix that. I'll inform PaulZ.

Alex

patch2 is for tune. For tune2, he needs to add the line

FILE *ECM_STDOUT, *ECM_STDERR;

to tune2.c.

[trilliwig]

Originally Posted by akruppa

Not sure... afaik Paul Zimmermann improved the modular arithmetic a little since 5.0, so stage 1 is a little faster. But the time saving should depend on both B1 and the size of the input number. Is it really constantly 20s?

Well, no, just for one particular C169 with B1=11e6. I've since moved on to a different number, a C158, and it seems to be exhibiting a better spread across my machines now (25s difference on a P3-450, 14s on a P3-1133, 12s on a P3-1400, but these numbers can vary quite a bit). I guess I got a run of weird numbers before. Sorry for the false alarm.

Anyway, ECM6.0 has been running great for me, and the expected time calculations are a great feature addition. Thanks!

--
Sam

[error404]

Rogue,

patch2 is for tune. For tune2, he needs to add the line

FILE *ECM_STDOUT, *ECM_STDERR;

to tune2.c.

Thanks for the above.

ecm-6.0 compiles correctly, with no errors, and make check works correctly also.

Tom

[akruppa]

Originally Posted by Mystwalker

After some working with gmp-ecm6, I got some more questions (Alex, I hope you still have a life besides post-v6 work):


- Is it possible to display the "expected number of curves" right at the start and not only after stage1?

Some parameters (in particular, d, d2, dF and, derived from those, B2') are only computed when stage 2 starts but are needed to compute the expected curves correctly. We plan to do all the parameter selection before ecm stage 1 so the expected curves can be printed immediately, but it will take a bit of rearranging code. You can get the expected curves quickly by doing a stage 1 of zero length, i.e. "ecm -v 44e6-44e6" or "ecm -v 1 44e6-198e9" - both calculate the expected curves for B1=44M, B2=198G.

Originally Posted by Mystwalker

- Concerning the estimated time to finish "certain digits": When I resume, stage1 is not included in this calculation. Maybe there could be a parameter option specifying this?

Yes, there should be. We probably should save the stage 1 time along with the residues in the save file, and have an option to scale the saved time to account for different cpu speeds. Maybe also an option to add a certain value to the stage 1 time for the purpose of calulcating expected time to find factors. Something like this will happen when we move the probability computation out of stage 2.

Originally Posted by Mystwalker

- Is there a general acceptance for the changed "ECM_EXTRA_SMOOTHNESS" (12 --> 23.4)? After all, for B1=11e6, B2=100*B1, expected curves were reduced to 8943 instead of 10600.

Montgomery examined this in his dissertation and I think he calculated his success probabilities assuming the 23.4 value. We calculate the probabilities a little different yet, we added some correction terms to the Dickman rho function. I've done some tests to see how often small factors are actually being found by gmp-ecm and the results match the computed values remarkably well. I'll test some more and post my findings, but the results are looking extremely good so far (except rounding up to 24 apparantly wasn't such a bright idea, though the difference in the computed probabilities is small).

Originally Posted by Mystwalker

- Sometimes, "stage 2" is called "step 2". As the k parameter splits stage 2 in k steps, I think there should be a clear distinction between these terms.

That has historic reasons. Both refer to the same thing. The more common term is "stage" but gmp-ecm up to version 4 called them "step". We wanted to change it to "stage" for 5.0 but didn't as it would have broken the ECMNET client. Btw, we call the k pieces of stage 2 "blocks".

Originally Posted by Mystwalker

- In the following output:

Using B1=1, B2=11000000-30117862320, polynomial Dickson(12), sigma=6481293096446123
Step 1 took 0ms
B2'=36025369380 k=2 b2=18010792800 d=420420 d2=17 dF=40320, i0=10

What is B2'? Is this the B2 bounds that are really taken? Maybe it should be mentioned even when the -v parameter hasn't be issued?

Again the problem that we don't determine the neccessary parameters until stage 2 starts.

Originally Posted by Mystwalker

- It seems like now, clock time is measured instead of CPU time. Is there a possibility to get CPU time back, because it eases figuring out optimal bounds?

Really? I have to check this...

Originally Posted by Mystwalker

- When resuming a prime95 stage1, I get the number displayed in hex format. Is there an option to convert it to decimal prior to displaying?

I don't think there is yet... there's an option to print cofactors in decimal, but not input numbers. We should add that.

Originally Posted by Mystwalker

- Just saw on the help screen:


The last should also be n>0, I suppose?

No, it should be 2^|n|-1 for n<0, I forgot the abs bars. To be fixed...

Originally Posted by Mystwalker

- From the Readme file:


Just for clarification: Even in front of "//", there should be no input number?

That's how I understand it. I'm not really familiar with the expression/input parsing code

Originally Posted by Mystwalker

P.S.:
I fear that all these postings sound like we (at least I) don't appreciate this version. I bet we all do! Thanks a lot to all contributors!
Most of these suggestions weren't even thought of without gmp-ecm6, so I count them as an expression of appreciation.

Quite the contrary! I'm rather flattered by how closely you examine the program and by how much time you must take doing so. And all the suggestions help us improve gmp-ecm, so keep them coming!

Alex

[Citrix]

Is there a windows version compiled for p4 available some where?

Thanks,
Citrix

[PBMcL]

Apple users should be aware that ECM-6.0 has a bug which occurs on multiple line input files and also makes the -c n option fail: 6.0 doesn't recognize '\r' as a newline character. I've emailed the patches to Paul Zimmerman. Basically all that you need to do is search the code for '\n' (including the single quotes) and add '\r' to the various conditionals you'll find.

[rogue]

Originally Posted by PBMcL

Apple users should be aware that ECM-6.0 has a bug which occurs on multiple line input files and also makes the -c n option fail: 6.0 doesn't recognize '\r' as a newline character. I've emailed the patches to Paul Zimmerman. Basically all that you need to do is search the code for '\n' (including the single quotes) and add '\r' to the various conditionals you'll find.

That's odd. How did you create your input file? I use the Terminal app and it defaults to Unix line encodings (CRLF), not Mac line encodings (CR). You can verify that with Xcode which will tell you which is used for a file.