GMP-ECM 6 released

[geoff]

I have noticed that using the -nobase2 comand line parameter improves the times for some numbers by 10-15% or more, e.g. the c208 of 2,821- and the c166 of 2,719+. Is there a way to raise the threshold for using base2 code?

[frmky]

I've compiled Windows executables optimized for the Athlon, Athlon64, Pentium4, and Pentium3. They are compiled using MinGW, and each uses the appropriate GMP. They include all 8 patches. They are currently hosted at http://www.pa.uky.edu/~childers/ecm6.zip but cannot stay there long. Could someone please give these a permanent home. Also, please time each of these on your available machines to make sure they perform as expected.

Thanks,
Greg

[geoff]

Originally Posted by frmky

Also, please time each of these on your available machines to make sure they perform as expected.

Thank you for these. I can confirm that the ecm6-p4.exe executable runs at the same speed as a Linux compiled one.

[xilman]

Originally Posted by frmky

I've compiled Windows executables optimized for the Athlon, Athlon64, Pentium4, and Pentium3. They are compiled using MinGW, and each uses the appropriate GMP. They include all 8 patches. They are currently hosted at http://www.pa.uky.edu/~childers/ecm6.zip but cannot stay there long. Could someone please give these a permanent home. Also, please time each of these on your available machines to make sure they perform as expected.

Thanks,
Greg

I've downloaded the ZIP file to ensure a copy gets kept for posterity. If a better offer doesn't come along I'll find space for it on my web site.

Thanks for doing this. You saved me a lot of hassle.


Paul

[Xyzzy]

Originally Posted by frmky

I've compiled Windows executables optimized for the Athlon, Athlon64, Pentium4, and Pentium3. They are compiled using MinGW, and each uses the appropriate GMP. They include all 8 patches. They are currently hosted at http://www.pa.uky.edu/~childers/ecm6.zip but cannot stay there long. Could someone please give these a permanent home.

I've attached the individual files here...

[frmky]

Originally Posted by xilman

Thanks for doing this. You saved me a lot of hassle.

No problem. Compiling GMP is REALLY slow in MinGW, so creating these gave me a reason to take periodic breaks while grading a stack of student homework and exams. Grading is by far the worst part of the job...we need more graduate students.

Greg

[smh]

One thing i'm missing is a curve counter. Now it's really hard to keep track on how many curves i've ran.

[akruppa]

Originally Posted by geoff

I have noticed that using the -nobase2 comand line parameter improves the times for some numbers by 10-15% or more, e.g. the c208 of 2,821- and the c166 of 2,719+. Is there a way to raise the threshold for using base2 code?

The macro BASE2_THRESHOLD is defined in ecm-impl.h. Lowering it will cause larger numbers to use mpzmod instead of base 2 reduction. Which value is optimal depends on all kinds of things, i.e. the size of the input number and the architecture. In most tests we did, 1.4 was about right, but the default may not be optimal in every case. Playing with the parameter can pay off!

Alex

[akruppa]

Originally Posted by smh

One thing i'm missing is a curve counter. Now it's really hard to keep track on how many curves i've ran.

Patchlevel release 6.0.1 is due soon, I suppose we can put the counter back in there. There also is a patch earlier in the thread.

Alex

[akruppa]

Originally Posted by Lfousse

Hi Alexander,

Cross-compiling worked like a charm for me. We have the mingw32 binutils and cross-compiler available in debian, and I could easily produce a static ecm-athlon.exe just by playing with the --host parameter.

Well, I couldn't test my binary yet, but I'm confident it works

Hi Laurent! Welcome on board!

Do you plan to make binaries for all future releases? For which platforms/architectures?

Alex

[smh]

Originally Posted by akruppa

Patchlevel release 6.0.1 is due soon, I suppose we can put the counter back in there. There also is a patch earlier in the thread.

Alex

I checked the ECM-NET site and didn't see a patch there. I guess i can wait till 6.0.1

[akruppa]

The patch isn't on the official web page as it is technically not a bug, but an absent feature.
The patch was attached to posting https://www.mersenneforum.org/showthread.php?p=50803 in this thread.

Alex

[Joe O]

Previously I ran all 8 binaries provided by BotXXX on an Athlon64 at 2.4MHz, as well as Alex's P3 binary and Mystwalker's Pentium M binary. So I ran these four as well under the same conditions

I'll only report on the Step2 times here:

K7		161133
K8		161429
P3		166797
Alex's_P3	168635
Athlon		169079
Prescot		169112
Pentium_M	169271
Athlon_XP	169358
Mystwalker's_PM	169362
Pentium_3	169481
Athlon_K8	169627
Nocona		169666
Pentium_4	169779
P4		212660

Three of these are now the fastest on this AMD64 and the fourth is the slowest. I would really like to see what Mystwalker's time is for this P4 binary on the 3.2 GHz P4 machine that he ran the previous binaries on.

Excluding the P4, all these times are within 5% of each other.

[Zeta-Flux]

I was following the installation instructions on the first page, and got to step 7 (where one installs ecm-6.0). When I try to do the ./configure command I get the error: "configure: error: gmp.h may be missing " What am I doing wrong?

Thanks,
Pace Nielsen

[Zeta-Flux]

(By the way, my machine is a P4)

[rogue]

You need to install and build GMP from http://www.swox.com/gmp

[Zeta-Flux]

I did that already. I built and installed gmp-4.1.4. However, from the error message, I think that when I try to build ecm-6.0 it can't find it.

[Zeta-Flux]

btw, in the gmp-4.1.4 folder there is no file called gmp.h. However, there is a file called gmp-h.in.

[Zeta-Flux]

I finally figured it out.

When I typed "./configure --with-GMP=/usr/local" I had an error. When I didn't capitalize GMP it worked fine. *shrug*

Thanks for trying to help rogue.

Now let's see if I can get this program working.

Best,
Pace Nielsen

[smh]

Originally Posted by Zeta-Flux

I finally figured it out.

When I typed "./configure --with-GMP=/usr/local" I had an error. When I didn't capitalize GMP it worked fine. *shrug*

Thanks for trying to help rogue.

Now let's see if I can get this program working.

Best,
Pace Nielsen

On request of Jes, i corrected that post.

[Phil MjX]

Hi Sander!

I also miss the curve counter. I currently use a freeware that counts every occurence of, for example "step 2", expression in a selection of files or folders...

The patch isn't on the official web page as it is technically not a bug, but an absent feature.
The patch was attached to posting http://www.mersenneforum.org/showthread.php?p=50803 in this thread.

Following Alex hints, you should apply this patch with the -R option since the + lines are written as - in the patch...

Unfortunately I wasn't able to correctly patch the sources because this doesn't seems to re-enable curve counter with the cygwin compilation....
Could you please try the patch under cygwin? if you are successfull, I would like to know what mistake I have done since al the other patches worked fine for me....

Maybe a little help from Alex ???

Thanks.

Philippe.

[akruppa]

Strange, I just tried the patch again and it works for me. I unpacked an original ecm-6.0.tar.gz file, applied the patch, did ./configure and make and now get this output:

alex@lily:~/gmp/ecm-6.0> ./ecm -c 5 1000 <~/Hare_c301.txt
GMP-ECM 6.0 [powered by GMP 4.1.4] [ECM]
Input number is 3831565799519436303487742350308454794716675157894098584352121252263510024611805907320592374654433186020517108665467143471934035839395496243353321245760019611207664487665420776742726779780862993590544596916020496510980740067901995154639576852120198067468078357247366647828551141390739467161074462608561 (301 digits)
Using B1=1000, B2=44623, polynomial x^1, sigma=2329651220
Step 1 took 380ms
Step 2 took 270ms
Run 2 out of 5:
Using B1=1000, B2=44623, polynomial x^1, sigma=4152249975
Step 1 took 390ms
Step 2 took 280ms
Run 3 out of 5:
Using B1=1000, B2=44623, polynomial x^1, sigma=759884127
Step 1 took 380ms
Step 2 took 280ms
Run 4 out of 5:
Using B1=1000, B2=44623, polynomial x^1, sigma=3719534954
Step 1 took 390ms
Step 2 took 270ms
Run 5 out of 5:
Using B1=1000, B2=44623, polynomial x^1, sigma=1966720922
Step 1 took 390ms
Step 2 took 270ms

You can check that the patch is applied by looking at lines 932ff in main.c, they should read

          if (cnt) /* nothing to read: reuse old number */
            {
              if (verbose >= OUTPUT_NORMAL)
                printf ("Run %u out of %u:\n", count - cnt + 1, count);
            }

Also, remember to run make again after patching.
Oh, and the patch in my posting was reverse, but I corrected it. It should not require the -R option anymore. In fact, if you use -R with the corrected patch, it will undo a previously applied patch - maybe that was the problem.

Alex

[smh]

I also miss the curve counter. I currently use a freeware that counts every occurence of, for example "step 2", expression in a selection of files or folders...

You can just use the 'find' command. find /c "step 2" will give you the number of curves.

BTW, i didn't compile the binary myself, i'm using the ones Greg compiled

[Mystwalker]

Originally Posted by Joe O

I would really like to see what Mystwalker's time is for this P4 binary on the 3.2 GHz P4 machine that he ran the previous binaries on.

I think I can test it Thursday.

[Mystwalker]

Ok, it seems like Monday will be the day.

Btw.:
I found a slight problem with 6.0 that has (more or less) vanished in 6.0.1:

I made a small mistake when calling gmp-ecm:

ecm.exe -n -one -k 4 -resume -treefile treefile results.txt 1 11e7-18e10 >> M1061result.txt

That line made 6.0 crash, 6.0.1 does not. I neither generates an error message, though...

[akruppa]

What happens is that ecm takes "-treefile" as the name of the file to read saved lines from, the next argument on the command line is "treefile" which does not start with a '-' so it tries to parse that as the B1 value. The error checking on that is pretty weak (read: non-existant), when there are no digits B1 will simply be set to zero. It next tries to parse "results.txt" as B2 where the error checking is a little stricter (but was buggy in 6.0) so it aborts with

GMP-ECM 6.0.1 [powered by GMP 4.1.4] [ECM]
Error: expected positive integer(s) B2 or B2min-B2

We should improve the error checking on the B1 parameter and print something like

Error: expected positive integer B1 instead of: treefile

to give a hint at what went wrong.

Alex

[error404]

Alex,

ecm-6 works correctly under Slackware and Fedora Core 3,
I get the following error when I try to run under Cygwin.

Administrator@gateway2000 /home/k5gj/ecm-6.0.1
$ make check
./test.pp1 ./ecm
GMP-ECM 6.0.1 [powered by GMP 4.1.4] [P+1]
Input number is 328006342451 (12 digits)
Using B1=120, B2=7043, polynomial x^1, x0=5
Signal 11
############### ERROR ###############
make: *** [check] Error 1

Administrator@gateway2000 /home/k5gj/ecm-6.0.1
$ uname -a
CYGWIN_NT-5.0 gateway2000 1.5.13(0.122/4/2)2005-03-01 11:01 in Cygwin

Administrator@gateway2000 /home/k5gj/ecm-6.0.1
$


Tom

[akruppa]

Hard to tell from the output why it segfaults... which patched did you have installed with the 6.0 version that worked? Does the binary crash if you run it yourself with different parameters (using ecm, p-1, p+1, no B2 parameter...)?

Alex

[error404]

Hi Alex,

I just installed and ran ecm-6.0.1 under Darwin
on my Mac and make check works correctly.


ecm-6.0 gives the same error as ecm-6.0.1.

FWIW, QS08 and ggnfs-0.75.1 both work correctly
on this system.

Administrator@gateway2000 /home/k5gj/ecm-6.0.1
$ ./test.pm1 ./ecm
GMP-ECM 6.0.1 [powered by GMP 4.1.4] [P-1]
Input number is 441995541378330835457 (21 digits)
Using B1=157080, B2=7000000000-7200000000, polynomial x^24, x0=3271198529
Signal 11
############### ERROR ###############

Administrator@gateway2000 /home/k5gj/ecm-6.0.1
$ echo 10000286586958753753 | ./ecm -sigma 3956738175 1000000
GMP-ECM 6.0.1 [powered by GMP 4.1.4] [ECM]
Input number is 100000286586958753753 (20 digits)
Using B1=1000000, B2=839549779, polynomial Dickson(3), sigma=3956738175
Segmentation fault (core dumped)




Administrator@gateway2000 /home/k5gj/ecm-5.0.3
$ echo 10000286586958753753 | ./ecm -sigma 3956738175 1000000
GMP-ECM 5.0.3 [powered by GMP 4.1.4] [ECM]
Input number is 100000286586958753753 (20 digits)
Using B1=1000000, B2=839549780, polynomial Dickson(3), sigma=3956738175
Step 1 took 2610ms
Step 2 took 4453ms
********** Factor found in step 2: 10000286586958753753
Found input number N

Administrator@gateway2000 /home/k5gj/ecm-5.0.3
$ ./test.pp1 ./ecm
bash: ./test.pp1: /bin/csh: bad interpreter: No such file or directory

Administrator@gateway2000 /home/k5gj/ecm-5.0.3
$ ./test.pm1 ./ecm
bash: ./test.pm1: /bin/csh: bad interpreter: No such file or directory

Administrator@gateway2000 /home/k5gj/ecm-5.0.3
$ ./test.ecm ./ecm
bash: ./test.ecm: /bin/csh: bad interpreter: No such file or directory

Administrator@gateway2000 /home/k5gj/ecm-5.0.3


Tom

[geoff]

Originally Posted by akruppa

The macro BASE2_THRESHOLD is defined in ecm-impl.h. Lowering it will cause larger numbers to use mpzmod instead of base 2 reduction. Which value is optimal depends on all kinds of things, i.e. the size of the input number and the architecture. In most tests we did, 1.4 was about right, but the default may not be optimal in every case. Playing with the parameter can pay off!

I see why the default appears wrong for me, I was only looking at the stage 2 time. I did two full curves on the c172 of 2,736+, one with the -nobase2 parameter and one without. The times are (2.9GHz P4):

parameters           method used        stage 1   stage 2   total
ecm 43e6             special division    813.7     354.2    1167.9
ecm -nobase2 43e6    modmuln            1049.6     317.6    1367.2

so the default threshold is OK for the overall curve, but it would be even better if there were seperate thresholds for each stage.

[akruppa]

Thanks for pointing this out. I think the problem is the mpz_mod() call in mpres_get_z() which we use to convert the computed roots from modular representation to plain integers. Unfortunately mpz_mod() is pretty slow as it does not know about the invariant modulus. We've been planning to rewrite stage 2 to use efficient mod reduction all the way through (right now all the poly arithmetic uses mpz_mod()!) which will give a significant boost. It's also quite a lot of work. :(

As an awkward first workaround, you could do stage 1 with base 2 reduction, save the residues and resume them with -nobase2.

Alex

[Mystwalker]

Core		Time for stage2 [ms]

AMD athlon	340372
AMD athlon XP	340452
AMD K8		339826
Nocona		339799
P3		339919
P4		340865
PM		339600
Prescott	340628

newK7		350700
newK8		350291
newP3		331422
newP4		193239

So, everything less than a fully optimized P4 version plainly sucks on a P4...

[smh]

Which are the 'new' binaries? Those compiled by Greg?

[Mystwalker]

That's right.
I'm going to test my self-compiled version later this day...

[Lfousse]

Originally Posted by akruppa

Hi Laurent! Welcome on board!

Do you plan to make binaries for all future releases? For which platforms/architectures?

Alex

Hi Alex,

I think I can produce ecm binaries for the whole i386 processor familly for windows using a MinGW cross-compiler, but I can only test the one for athlon. If there's interest I can link the binaries from the ecm webpage but I'll need help in testing them, obviously.

[Mystwalker]

I can test for Pentium4 and Pentium-M...

[Lfousse]

Originally Posted by Mystwalker

I can test for Pentium4 and Pentium-M...

Thanks! Then could you tell me if the following binary:

http://www.komite.net/laurent/soft/e...m4-mingw32.exe

works? For lack of a windows machine here I can't even tell if it runs at all. I'll put a link from ecm webpage if the answer is yes.

[Mystwalker]

All I can say at the moment that I can run it on the Pentium M. I haven't done a speed testing, though.
I'll try it on the P4 later this day.

---------------------------------------------------

Concerning the speed testing of my own binary, I get 194,477 ms, which is very close to Greg's binary - too close to say one is faster. I hope I can do some more testing (esp. on the Pentium M) today.

----------------------------------------------

Alex:

Any news on the CPU time vs. runtime issue? Measuring CPU time would greatly ease speed testing and lessens differences caused by OS and other programs (which I already try to keep at a minimum during testing).

[akruppa]

Oops, sorry, I had forgotten about that

I think the problem is QueryPerformanceCounter() in auxlib.c cputime(). If I understand correctly it reads the cpu time stamp counter (rdtscll) and that one of course keeps ticking away while other processes are running. Try commenting out the line 122:

/* if (!QueryPerformanceFrequency (&PF)) */

Does that make it work?

Alex

[akruppa]

error404's segfault turned out to be caused by an old gmp.h file on his system. Corrupted GMP installations apparantly are one of the more frequent causes of problems.
If you compiled GMP yourself (as is recommended) giving the "--with-gmp=/usr/local/" (or wherever GMP was installed) parameter to GMP-ECM's ./configure should help avoid problems.

Alex

[Mystwalker]

Originally Posted by akruppa

Oops, sorry, I had forgotten about that

I think the problem is QueryPerformanceCounter() in auxlib.c cputime(). If I understand correctly it reads the cpu time stamp counter (rdtscll) and that one of course keeps ticking away while other processes are running. Try commenting out the line 122:

/* if (!QueryPerformanceFrequency (&PF)) */

Does that make it work?

Alex

I've tried this the other day - the discrepancy between CPU time and clock time is still there.

[akruppa]

Pierrick Gaudry released AMD64 assembler optimizations for the most important functions of GMP. They seem to about double the speed of GMP-ECM on an Opteron 150. They can be downloaded at http://www.lix.polytechnique.fr/Labo...dry/mpn_AMD64/

If you install them, please do "make check" for both GMP and GMP-ECM.

Alex

[ATH]

I keep getting:
"checking if gmp.h version and libgmp version are the same... no
configure: error: 'gmp.h' and 'libgmp' have different versions! you have to properly reinstall GMP."
when trying to GMP-ECM 6.0.1 with MinGW/MSYS even with the --with-gmp=/usr/local switch.

I even tried starting over from scratch following JHansens guide exactly reinstalling MinGW and MSYS and recompiling GMP 4.1.4.

I compile GMP with:
./configure --disable-static --enable-shared --enable-mpfr --build=pentium4-pc-mingw32
make
make install

and to make the lib files:

cd mpfr
lib /out:libmpfr.lib *.o
cd .libs
lib /out:libgmp.lib /def:libgmp-3.dll-def

My GMP works fine in visual c++ 6.0.

[akruppa]

GMP-ECM wants the static library. Can you try compiling GMP without the --disable-static --enable-shared flags and installing the static library to /usr/local ?

Alex

[ATH]

Thanks that worked :)

Here is some compiled versions:
Pentium4 Prescott 3.4Ghz: ecmp4p.rar
Athlon M4 (Thunderbird) 950 Mhz: ecmathlon.rar

I can compile for a P4 Northwood 2.4Ghz in a few days if anyone need.


How do you use the parameters found by tune.exe and tune2.exe?

[ATH]

Thats version 6.0.1 I compiled.

[ewmayer]

I'm just trying a build of GMP 4.1.4 and GMP-ECM 6.0.1 on an Alpha running TruUnix. I notice that the configuration utility defaults to gcc on this platform. Has anyone tried building using the native C compiler? (I want to finish all the install and self-tests using the defaults before plunging into those unknown waters.) What would be needed to change the config/make environment to use cc rather than gcc?

[Update:]

...and 'make check' of the (apparently successful) build fails:

make check-TESTS
524660:/house/ewm/ecmnet/gmp-4.1.4/tests/.libs/lt-t-bswap: /sbin/loader: Fatal Error: Cannot map library libgcc_s.so.1
FAIL: t-bswap
524744:/house/ewm/ecmnet/gmp-4.1.4/tests/.libs/lt-t-constants: /sbin/loader: Fatal Error: Cannot map library libgcc_s.so.1
FAIL: t-constants
524366:/house/ewm/ecmnet/gmp-4.1.4/tests/.libs/lt-t-count_zeros: /sbin/loader: Fatal Error: Cannot map library libgcc_s.so.1
FAIL: t-count_zeros
524726:/house/ewm/ecmnet/gmp-4.1.4/tests/.libs/lt-t-gmpmax: /sbin/loader: Fatal Error: Cannot map library libgcc_s.so.1
FAIL: t-gmpmax
970411:/house/ewm/ecmnet/gmp-4.1.4/tests/.libs/lt-t-modlinv: /sbin/loader: Fatal Error: Cannot map library libgcc_s.so.1
FAIL: t-modlinv
===================
5 of 5 tests failed
===================
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.


Has anyone besides me tried a build on Alpha/Unix?

[akruppa]

As I understand from the output, it is the GMP make check that fails, so you didn't even get to compile GMP-ECM. I'm not really familiar with the intricacies of compiling GMP on different platforms.

Under SunOS, GMP autodectect the Sun cc compiler and uses it. For GMP-ECM, you have to pass "CC=cc -xarch=v9 ..." to make it use the Sun compiler and produce a 64 bit binary that works with the GMP library. I've never used Tru64, though.

A failure to make a binary via "configure; make" sounds like a bug. Maybe ask Trobjorn? But be sure to read http://www.swox.com/gmp/manual/Repor...porting%20Bugs first or he'll eat your soul.

Alex

[wblipp]

Is there a compiled executable that will run on a Pentium Pro?

[xilman]

Originally Posted by wblipp

Is there a compiled executable that will run on a Pentium Pro?

A PPro running what OS?

My PPro is a RedHat 8 machine. Not sure which version of ECM is running on it but I can easily build another if required.

That machine can be rebooted into Win98 if strictly necessary and it may be possible to build a PPro Windows binary on my PII-2k3S if it's important enough, but I really don't want to have to try to build a PPro GMP on that machine. GMP is absolutely dreadful to get working on anything that doesn't look like a Unix box.



Paul