Links to Precompiled GMP-ECM versions

[Jeff Gilchrist]

Originally Posted by bdodson

Thanks, but these are windows7 machines. Regards, Bruce

The link he posted was for a Core2 Windows 64bit binary that should work fine on your Windows 7 machines unless they are 32bit Windows 7.

Jeff.

[bdodson]

Originally Posted by Jeff Gilchrist

The link he posted was for a Core2 Windows 64bit binary that should work fine on your Windows 7 machines unless they are 32bit Windows 7.

Jeff.

Thanks, I got distracted by [Yamato]'s comment about MPIR. Not that
I'm easily distracted, or anything. Fortunately, it's a weekend, so many
of the [older, non-avx] i7 sites are closed (to the public), so available for
benchmarking. I'm trying both i2 binaries; except that I switched ATH's
so as not to use asmredc; mostly the numbers below c234 are running on
the 8-core/AMD cluster, and the i7's at/above c234. (If I have that division
correctly stated, asm -vs- non-asm.)

Bruce

[bdodson]

Originally Posted by bdodson

Thanks, ...
I'm trying both i2 binaries; except that I switched ATH's
so as not to use asmredc; mostly the numbers ... at/above c234. ...
Bruce

For 3m701, C261 with B1=400M, default B2, I get

outcor2b3m701ai7_noavx.2:Step 1 took 6790879ms
outcor2b3m701ai7_noavx.2:Step 2 took 2451868ms

outcor2b3m701ai2.2:Step 1 took 7025255ms
outcor2b3m701ai2.2:Step 2 took 2310484ms

outcor2b3m701bwin.2:Step 1 took 5933108ms
outcor2b3m701bwin.2:Step 2 took 2069353ms

where the i7 is with asmredc and the i2 is without. Looks like
a clear win for Yamato's binary. Of course, with 8 curves running
at the same time on these older i7's, there's some prospect of
interference, but the win64 timings are consistent. A recent 3am
status shows 168 of these corei7's, so 8*168 = 1344 curves at once.

Regards, Bruce
--------------------------------

Here's a 2nd opinion, on 3L/M, 1599, C226/C212:

outcor2b3L1599ai2.1:Step 1 took 5394046ms
outcor2b3L1599ai2.1:Step 2 took 1777257ms
outcor2b3L1599bwin.1:Step 1 took 5164225ms
outcor2b3L1599bwin.1:Step 2 took 1975004ms
outcor2b3L1599a_noavx.1:Step 1 took 5047677ms
outcor2b3L1599a_noavx.1:Step 2 took 2000307ms
---

outcor2b3M1599ewin.1:Step 1 took 4423158ms
outcor2b3M1599ewin.1:Step 2 took 1564955ms
outcor2b3M1599fi2.1:Step 1 took 4755784ms
outcor2b3M1599fi2.1:Step 2 took 1721050ms
outcor2b3M1599a_noavx.1:Step 1 took 4411209ms
outcor2b3M1599a_noavx.1:Step 2 took 1688539ms

More margin-of-error, but these numbers are in the range mostly
running on the 8-core/linux/AMD's, aside from these numbers
reserved B+D snfs.

[ATH]

Originally Posted by Yamato

I only have a core2, but the timings for stage 2 differ from the timings posted here.

Originally Posted by bdodson

For 3m701, C261 with B1=400M, default B2, I get

I noticed that different binaries choose slightly different default B2 values, so for testing stage2 "fairly" I fixed the B2 value to a value near the default B2.



I tested my old 6.3 and 6.3.1 binaries versus the new 6.4 and the new version is 2-6% slower above 200 digits in stage1 but about the same speed for stage2, though I'm only testing for the lower B1/B2 values.

core2-64bittests.html
corei7-64bittests.html

I briefly tested 6.3.1 compiled with MPIR 2.5.0 and 6.4 compiled with MPIR 2.4.0 and 6.3.1 matches the old 6.3.1 faster times while 6.4 matches the other 6.4 times, so it's gmp-ecm that is a bit slower not mpir.

[lorgix]

Originally Posted by ATH

I noticed that different binaries choose slightly different default B2 values, so for testing stage2 "fairly" I fixed the B2 value to a value near the default B2.



I tested my old 6.3 and 6.3.1 binaries versus the new 6.4 and the new version is 2-6% slower above 200 digits in stage1 but about the same speed for stage2, though I'm only testing for the lower B1/B2 values.

core2-64bittests.html
corei7-64bittests.html

I briefly tested 6.3.1 compiled with MPIR 2.5.0 and 6.4 compiled with MPIR 2.4.0 and 6.3.1 matches the old 6.3.1 faster times while 6.4 matches the other 6.4 times, so it's gmp-ecm that is a bit slower not mpir.

So there's no reason to use ecm64-1681mpir250core2-64-asmredc?

Btw; Does anyone know why this happens?

[schickel]

Originally Posted by lorgix

So there's no reason to use ecm64-1681mpir250core2-64-asmredc?

Btw; Does anyone know why this happens?

Raymond Chen had a post on that last month. It's because of the assertion failure.....

[lorgix]

Originally Posted by schickel

Raymond Chen had a post on that last month. It's because of the assertion failure.....

OK, do you know why there is an assertion failure?

This happens when I try to use pp1 & pm1. I get this message if [bounds]*[input] is too big.

[schickel]

Originally Posted by lorgix

OK, do you know why there is an assertion failure?

This happens when I try to use pp1 & pm1. I get this message if [bounds]*[input] is too big.

You're right -- after I posted that I realized it was obvious (but only after it was too late to get my foot out of my mouth...)

I would venture to guess that some internal limit is still being hit (or the limit check is left over.) What B1 bounds are you trying to use?

[lorgix]

Originally Posted by schickel

You're right -- after I posted that I realized it was obvious (but only after it was too late to get my foot out of my mouth...)

I would venture to guess that some internal limit is still being hit (or the limit check is left over.) What B1 bounds are you trying to use?

I just did a quick test with a ~10k-digit number. Trying '-pp1'

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

It prints the stage1 time before it fails.

Higher bounds work for smaller inputs.

[bdodson]

Originally Posted by bdodson

For 3m701, C261 with B1=400M, default B2, I get

outcor2b3m701ai7_noavx.2:Step 1 took 6790879ms
outcor2b3m701ai7_noavx.2:Step 2 took 2451868ms

outcor2b3m701ai2.2:Step 1 took 7025255ms
outcor2b3m701ai2.2:Step 2 took 2310484ms

outcor2b3m701bwin.2:Step 1 took 5933108ms
outcor2b3m701bwin.2:Step 2 took 2069353ms

where the i7 is with asmredc and the i2 is without. Looks like
a clear win for Yamato's binary [=the win64] ...

Here's a 2nd opinion, on 3L/M, 1599, C226/C212:
...
More margin-of-error, ..

Looks like the comparison depends rather close on the size
of the numbers; here's C271, B1=400M, all with B2=15892277350966.

3m671dwin.1:Step 1 took 7939328ms
3m671dwin.1:Step 2 took 3640892ms

3m671e_63.1:Step 1 took 7673189ms
3m671e_63.1:Step 2 took 3556761ms

3m671fi2.1:Step 1 took 6386322ms
3m671fi2.1:Step 2 took 2944457ms

where the 63-binary was from ecm63mpircore2-64-asmredc.zip but
reports using gmp, win is Yamato's (which won in c261), and the i2
is the core2 binary with MPIR, but without redc. Actually, win reports
using redc, so maybe this is up in the range where without asm-redc
is better. Anyway, I'll be using ATH's i2 binary from here, up.

I still have the largest range to check, c290-c3xx, using B1=600M,
a 63-binary vs the winner here. -Bruce

[ATH]

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

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

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

Edit:
Forgot to mention this is for 64 bit Windows only. I could make one for 32 bit later if needed.