[QUOTE=akruppa;171390]Hmm. Try inserting

in mpmod.c, line 393 (after the variable definitions)[/QUOTE]

That doesn't seem to be completely working.

I have:

[CODE]#ifndef NATIVE_REDC
mpz_mul (modulus->temp1, S1, S2);
ecm_redc_basecase(R, modulus->temp1, modulus);
#else
mp_ptr rp;
mp_ptr s1p, s2p;
mp_srcptr np;
mp_limb_t cy;
mp_size_t j, nn = modulus->bits / __GMP_BITS_PER_MP_LIMB;
if (nn > 20)
{
mpz_mul (modulus->temp1, S1, S2);
ecm_redc_basecase (R, modulus->temp1, modulus);
return;
}
#ifdef WANT_ASSERT_EXPENSIVE
mpz_mul (modulus->temp1, S1, S2);
ecm_redc_basecase (modulus->temp2, modulus->temp1, modulus);
#endif[/CODE]

But when I run it with a C241 the timing is faster than the muldrec code but not as fast as the non-muldrec.

muldrec:
Step 1 took 463572ms
Step 2 took 88967ms
real 9m26.480s

non-muldrec:
Step 1 took 394542ms
Step 2 took 84678ms
real 8m11.034s

modified code as above:
Step 1 took 440906ms
Step 2 took 88327ms
real 9m6.176s

Jeff.

I just doubled checked on Core2 and Opteron 64bit that the muldrec code is always faster than GMP 4.3.0 alone and that is true even with big numbers so whatever hack we make for GMP-ECM make sure you only apply it to your 32bit binaries and not the 64bit ones.

[QUOTE=Jeff Gilchrist;171012]GMP-ECM [B]6.2.3[/B] with MPIR 1.1.1 compiled for Windows 32bit & 64bit using Visual Studio 2008:
[url]http://gilchrist.ca/jeff/factoring/[/url][/QUOTE]I downloaded MPIR and GMP-ECM to a MacOS box.

MPIR installed correctly, afaik. Certainly "make check" did the right thing.

I couldn't make progress. ECM doesn't understand about MPIR out of the box. A build of MPIR to create the gmp.h and libraries failed to help much. This time, the linker complained about incorrect library types.

Anyone here have any ideas about how I might build stuff to use MPIR on MacOS?

(Yes, I know this should be sent to the MPIR list but as there are folk here who have already built GMP-ECM with MPIR, albeit on a different platform, it seemed to be a good idea to ask those with experience first, rather than last.)

Thanks,

Paul

[QUOTE=xilman;171499]I downloaded MPIR and GMP-ECM to a MacOS box.

MPIR installed correctly, afaik. Certainly "make check" did the right thing.

I couldn't make progress. ECM doesn't understand about MPIR out of the box. A build of MPIR to create the gmp.h and libraries failed to help much. This time, the linker complained about incorrect library types.

Anyone here have any ideas about how I might build stuff to use MPIR on MacOS?[/QUOTE]

I have never tried to compile ECM on a Mac after installing the shared libraries. I think there is an option in MPIR something like --gmp-compat that will name the libraries to be the same as GMP but I'm not 100% sure.

The easiest way to do it and ensure it works is go into your MPIR directory and create a directory "include" and "lib". Then copy mpir.h to include/gmp.h and .libs/libmpir.a to lib/libgmp.a

ECM needs you to use the --with-gmp= command to point it to the right spot and expects things to be in include/ and lib/ so use something like this with ECM.

configure --with-gmp=/home/paul/mpir-1.1.1/

That will tell ecm to grab the MPIR static library (which is now named gmp for which ECM is expecting) and then you should be able to compile it properly.

Jeff.

Yamato,

Both of your 6.2.3 Win32 binaries crash on my Win32 P4 @ 1.7GHz. After about a second, I get "ecm.exe has encountered a problem and needs to close". My computer is running Windows XP and is nearly 7 years old. Could this be anything to do with it?

[QUOTE=10metreh;172932]Both of your 6.2.3 Win32 binaries crash on my Win32 P4 @ 1.7GHz.[/QUOTE]

They are optimised for Core2 and won't run on Pentium4. It seems that gmp 4.3.0 uses some new cpu instructions which come along with Core2 (maybe sse4?). You could try [URL="http://www.kay-schoenberger.de/eng/math/ecm/binaries/ecm623_win32_pentiumm.zip"]this Pentium M binary[/URL] (the Pentium M is very close to Pentium 4) instead.

I have a pentium4 binary. GMP-ECM 6.2.3 with GMP 4.3.0 compiled with Mingw on a Pentium4 Prescott:

[B]Without[/B] --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm623-p4p.zip"]ecm623-p4p.zip[/URL]

[B]With[/B] --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm623-p4p-asmredc.zip"]ecm623-p4p-asmredc.zip[/URL]

asm-redc is faster up to 190-200 digit numbers for 32bit version.

[QUOTE=Brian Gladman;133524]Hi to All,

SNIP
I much appreciate the help that Alex and Paul have provided in building a robust 64-bit Windows build of GMP-ECM. This is harder on Windows than it might seem because long types are 32-bits on Windows and this makes it necessary to use long long types to obtain 64-bit limbs. It is a tribute to both the GMP team and the LORIA/INRIA team that this all now works.

I also thank Alex and Paul for motivating me to find out why my Windows port of GMP has previosuly had relatively poor perfromance on division. I have now sorted this out and I get a gmpbench score of 8950 on a 2.4GHz Athlon X2.

SNIP
with regards to all

Brian Gladman[/QUOTE]

All runs under Windows 7 64bit on an AMD620
Brian Gladman's Win64-AMD64
[CODE]GMP-ECM 6.2.3 [powered by GMP 4.2.1_MPIR_1.1.1] [ECM]
Input number is (303 digits)
Using B1=11000000, B2=35133391030, polynomial Dickson(12), sigma=30748183
Step 1 took 103288ms
Step 2 took 51699ms
GMP-ECM 6.2.3 [powered by GMP 4.2.1_MPIR_1.1.1] [ECM]
Input number is (303 digits)
Using B1=43000000, B2=240490660426, polynomial Dickson(12), sigma=867940428
Step 1 took 406008ms
Step 2 took 160557ms[/CODE]
Brian Gladman's Win64-Core2
[CODE]GMP-ECM 6.2.3 [powered by GMP 4.2.1_MPIR_1.1.1] [ECM]
Input number is (303 digits)
Using B1=11000000, B2=35133391030, polynomial Dickson(12), sigma=4047765977
Step 1 took 104005ms
Step 2 took 51496ms
GMP-ECM 6.2.3 [powered by GMP 4.2.1_MPIR_1.1.1] [ECM]
Input number is (303 digits)
Using B1=43000000, B2=240490660426, polynomial Dickson(12), sigma=2393316774
Step 1 took 405181ms
Step 2 took 160276ms
[/CODE]
The best 32 bit version from Yamato. (This was indeed the best of all 32 bit versions on all the 32 bit machines that I have tried, both AMD and Intel) Kudos!
[CODE]GMP-ECM 6.2.3 [powered by GMP 4.3.0] [ECM]
Input number is (303 digits)
Using MODMULN
Using B1=11000000, B2=30114149530, polynomial Dickson(30), sigma=3111830617
dF=36864, k=2, d=371280, d2=11, i0=19
Step 1 took 441452ms
Step 2 took 142600ms
GMP-ECM 6.2.3 [powered by GMP 4.3.0] [ECM]
Input number is (303 digits)
Using MODMULN
Using B1=43000000, B2=198654756318, polynomial Dickson(30), sigma=1316417087
dF=92160, k=2, d=1021020, d2=19, i0=24
Step 1 took 1729349ms
Step 2 took 369317ms[/CODE]
Kudos to Brian Gladman!

[QUOTE=Greenbank;82565]MacOS X, ECM 6.0.1 with GMP 4.2 [B]64-bit G5 only[/B]: [URL="http://www.greenbank.org/misc/ecm_6.0.1_gmp_4.2_MacOSX_64bit.zip"]ecm_6.0.1_gmp_4.2_MacOSX_64bit.zip[/URL][/QUOTE]

Do you have anything later?
Like ECM 6.3 & GMP 5.0.1

A binary optimised for Intel Core i7/i5/i3 processors: [URL="http://www.kay-schoenberger.de/eng/math/ecm/binaries/ecm63_win64_corei.zip"]ecm63_win64_corei[/URL].
There is no real difference to the core2-builds.

I tried Jeff's Win64 Core2 version and Yamato's corei binary posted above. This is on a Win7 64-bit machine. There has to be something wrong because it takes way too long. I ran both overnight and not even stage1 completed for a 1.7 million digit Mersenne number using B1=50,000 and B2=6,778,500. What gives?:confused:

[QUOTE=garo;232033]I tried Jeff's Win64 Core2 version and Yamato's corei binary posted above. This is on a Win7 64-bit machine. There has to be something wrong because it takes way too long. I ran both overnight and not even stage1 completed for a 1.7 million digit Mersenne number using B1=50,000 and B2=6,778,500. What gives?:confused:[/QUOTE]

A single run with a 1.7 million digit number should take at least 40-50 hours, even on fast computers.

Then how does Prime95 finish the run in a few hours? Is your binary not compiled with gwnum?

I'm not sure, but I think GMP-ECM is not suited for numbers of this size like Prime95 is.

Stage1 in Prime95 on M5647219 (1.7 million digits) takes under 1 hour with 2 cores on a "Core2 Duo (Conroe) E6750 2.66Ghz".

I guess Prime95 uses FFTs whereas GMP_ECM uses some other general big number library which is much slower.

[QUOTE=garo;232603]I guess Prime95 uses FFTs whereas GMP_ECM uses some other general big number library which is much slower.[/QUOTE]

I think that both use FFTs. But Prime95 uses a very specialized version of the FFT, the IBDWT, which takes advantage of the specialized form of the number, whereas GMP-ECM uses a more general FFT: the Schönhage–Strassen algorithm (or some variant).

[QUOTE=garo;232603]I guess Prime95 uses FFTs whereas GMP_ECM uses some other general big number library which is much slower.[/QUOTE]

GMP-ECM uses GMP, which is all integer. You can link GMP-ECM with gwnum, thus it will use gwnum to do the multiplies. I don't recall what the speedup is though.

[QUOTE=garo;232603]I guess Prime95 uses FFTs whereas GMP_ECM uses some other general big number library which is much slower.[/QUOTE]

Prime95 could make errors when multiplying/taking modulo because of round off errors in floating point that could backtrack; in integers this is less likely, basically hardware errors could cause them. So for really big numbers, you can only use integer transforms with the current implementations.

For integer transform interesting one is from Yap. When we used it, it seemed similar to what newer version of GMP was using, probably with CRT enhancements we didn't do. Theoretical spoken, integer transforms can be very fast; it's just the hardware that is having in SIMD a multiplication possibility for 2 doubles times 2 doubles == 2 doubles.

So {a,b} * {x,y} == {ax,by}

For integers this doesn't exist, only a lousy 32 bits multiplication in SIMD, giving 2 results of 64 bits in a single 128 bits vector.
What would be interesting is having 2 instructions which allow 64 bits multiplication.

In itself integer transforms are more efficient than floating point transforms. So per limb you can store more bits and you can store it lossless with integers and in floating point it is lossy.

Yet if you have something in floating point, thanks to the limited amount of instructions available there, or better, missing instructions as those are not getting used in testsets that get used to benchmark processors, floating point is faster and a lot.

I doubt that will change any soon in x64 cpu's.

vector cpu's and gpu's is yet another discussion.

GMP-ECM 6.3 32-bit with GMP 5.0.1 optimized for Core2 compiled with Msys+Mingw32 on WinXP on a "Core2Duo (Conroe) E6750 2.66 Ghz", with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm63core2-32.zip"]ecm63core2-32.zip[/URL]
[URL="http://www.hoegge.dk/mersenne/ecm63core2-32-asmredc.zip"]ecm63core2-32-asmredc.zip[/URL]

GMP-ECM 6.3 64-bit with GMP 5.0.1 optimized for Core2 compiled with Msys+Mingw64 on Windows7 64bit on a "Core2Quad (Yorksfield) Q9450 2.66 Ghz", with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm63core2-64.zip"]ecm63core2-64.zip[/URL]
[URL="http://www.hoegge.dk/mersenne/ecm63core2-64-asmredc.zip"]ecm63core2-64-asmredc.zip[/URL]

I have a x64 Windows 7 and a Core2Quad Q6600 CPU @ 3.0 Ghz.
The most recent core2 64 bit asmredc version is the fastest of them all, and 0.5s faster than Yamato's binary for ix CPUs.
Benching was done using 8 curves, B1=2.5e06 B2=B1*400 on a 186 digit long composite number.

I found out GMP-ECM 64bit compiled with MPIR 2.1.1 (with --enable-gmpcompat) is faster than the one with GMP, see timings here: [URL="http://www.hoegge.dk/mersenne/GMPECMtests.html"]GMPECMtests.html[/URL]

GMP-ECM 6.3 64-bit with MPIR 2.1.1 optimized for Core2 compiled with Msys+Mingw64 on Windows7 64bit on a "Core2Quad (Yorksfield) Q9450 2.66 Ghz", with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm63mpircore2-64.zip"]ecm63mpircore2-64.zip[/URL]
[URL="http://www.hoegge.dk/mersenne/ecm63mpircore2-64-asmredc.zip"]ecm63mpircore2-64-asmredc.zip[/URL]

It seems asm redc version benefits only relatively small composites.
Maybe up to 125 digits.

Added all the binary and testdata to a table to make it easier to overview. Also added binaries for Pentium 4 32bit:

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

p58x2, p59
 

[QUOTE=ATH;248574]I found out GMP-ECM 64bit compiled with MPIR 2.1.1 (with --enable-gmpcompat) is faster than the one with GMP, see timings here: [URL="http://www.hoegge.dk/mersenne/GMPECMtests.html"]GMPECMtests.html[/URL]

GMP-ECM 6.3 64-bit with MPIR 2.1.1 optimized for Core2 compiled with Msys+Mingw64 on Windows7 64bit on a "Core2Quad (Yorksfield) Q9450 2.66 Ghz", with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm63mpircore2-64.zip"]ecm63mpircore2-64.zip[/URL]
[URL="http://www.hoegge.dk/mersenne/ecm63mpircore2-64-asmredc.zip"]ecm63mpircore2-64-asmredc.zip[/URL][/QUOTE]

I was under the impression that I'd picked up the MPIR versions from
these links --- is that consistent with the GMP 5.0.1 report in the outfiles?

[code]
GMP-ECM 6.3 [configured with GMP 5.0.1 and --enable-asm-redc] [ECM]
Input number is 43265615947474401302990347049063407684773678412822100498476523085921557803685800274
918031069556705208723784346917856379145580514889543711359775534394569831043455173944903564127398077
124844329287057903468390755633 (212 digits)
Using B1=400000000, B2=15892277350966, polynomial Dickson(30), sigma=1184101835
Step 1 took 4491689ms
Step 2 took 1062383ms
********** Factor found in step 2: 4645115103442161869804915570014378786825822382803505847361
Found probable prime factor of 58 digits: 4645115103442161869804915570014378786825822382803505847361
Probable prime cofactor 931421826671493120552896087656519610085716480194353581267118177854991447790
1926533057530661037456181010071091367006891345356014589664056746236174666765553 has 154 digits [/code]
Our pc/grid has at long last completed switching from xp to WINNT6,
including a six month or so delay while the pc people decided whether
to let the labs compute overnight. These binaries (whichever they are)
are 3-4 times quicker than the old 32-bit ones (with no improvement
from 32-bit "core2" versions that I could find). Here's the first of the new
factors --- there are four independent curves running at once, mostly on i3's
and a few of the core2duos. The rest of the core2duos running two curves,
but with more memory available; and using B1 = 600M. That gets me
past 260M, with enough compute power to keep the curve counts up.

I'd be unambiguously cheering the arrival of the 64-bit windows7, which
found this p58 twice overnight, from 2p988; except that the old 32-bit
xeons reported being "not dead yet" in the form of an overnight p59 from
5m439. Both first five holes, and _NOT_ from an extension.

Thanks very much to ATH for the upgrade. Regards, Bruce

[QUOTE=bdodson;251169]I was under the impression that I'd picked up the MPIR versions from
these links --- is that consistent with the GMP 5.0.1 report in the outfiles?[/QUOTE]

As I understand it MPIR is built upon GMP: [URL="http://www.mpir.org/#about"]http://www.mpir.org/#about[/URL]
I have to compile MPIR with "--enable-gmpcompat" so it builds a gmp.h which will work with GMP-ECM, so GMP-ECM still reports it as "configured with GMP 5.0.1". I don't know why it's faster than GMP 5.0.1 for 64bit, since one of my own homemade programs using GMP was about the same speed, but I haven't done extensive testing. MPIR isn't faster for 32bit core2 and pentium4.

I'm thrilled to hear about the speed increase you get, it means it was worthwhile, and it means I can contribute to factoring in a very small way without running a big farm of machines on this expensive danish electricity :)

[QUOTE=ATH;251197]As I understand it MPIR is built upon GMP: [URL="http://www.mpir.org/#about"]http://www.mpir.org/#about[/URL]
I have to compile MPIR with "--enable-gmpcompat" so it builds a gmp.h which will work with GMP-ECM, so GMP-ECM still reports it as "configured with GMP 5.0.1". I don't know why it's faster than GMP 5.0.1 for 64bit, since one of my own homemade programs using GMP was about the same speed, but I haven't done extensive testing. MPIR isn't faster for 32bit core2 and pentium4.

I'm thrilled to hear about the speed increase you get, it means it was worthwhile, and it means I can contribute to factoring in a very small way without running a big farm of machines on this expensive danish electricity :)[/QUOTE]

MPIR _forked_ from GMP several years ago and now has substantially different code in several areas (including bug fixes for GMP code).

Much of the 64-bit assembler code is new and has been developed with an analyser and optimiser that can often produce the best possible results (thanks to Jason Moxham). Bill Hart has added better FFT code and has said that he plans another FFT update shortly. And, of course, I maintain the Visual Studio builds for Windows.

MPIR is typically faster than GMP in multiplication but behind in division (where we have still got things to do). We are planning our next release at the moment so if you want any new features, now is the time to speak up.

Brian

[QUOTE=Brian Gladman;251223]We are planning our next release at the moment so if you want any new features, now is the time to speak up.[/QUOTE]

I don't know how hard this is to implement, but my idea for a new feature is the Baillie-PSW Primality Test:
[URL]http://mathworld.wolfram.com/Baillie-PSWPrimalityTest.html[/URL]
[URL]http://www.trnicely.net/misc/bpsw.html[/URL]

or maybe just the Lucas-Selfridge primality test which including the Miller-Rabin test in mpz_probab_prime_p would be a BPSW test. Although the Miller-Rabin test has to be in base 2? Not sure which base mpz_probab_prime_p uses if rep is 1.

[QUOTE=Brian Gladman;251223]MPIR _forked_ from GMP several years ago and now has substantially different code in several areas (including bug fixes for GMP code).

Much of the 64-bit assembler code is new and has been developed with an analyser and optimiser that can often produce the best possible results (thanks to Jason Moxham). Bill Hart has added better FFT code and has said that he plans another FFT update shortly. And, of course, I maintain the Visual Studio builds for Windows.

MPIR is typically faster than GMP in multiplication but behind in division (where we have still got things to do). We are planning our next release at the moment so if you want any new features, now is the time to speak up.[/QUOTE]

Fix it so that 64-bit builds work correctly. GMP (and MPIR) use unsigned long for inputs/outputs, but on Windows (both Win32 and Win64), an unsigned long is 32-bits, so precision is lost on many of the mpz_*_ui functions. I ran into this problem in PFGW with the mpz_get_ui function.

But what is the 'correct' behaviour? I keep thinking about what we should do about this without coming to any conclusion.

Brian

[QUOTE=Brian Gladman;251253]But what is the 'correct' behaviour? I keep thinking about what we should do about this without coming to any conclusion.[/QUOTE]

With GMP, the mpz_*_ui functions either accept or return an "unsigned long int". An unsigned int is always 32 bits regardless of 32-bit or 64-bit builds. I had to modify the gmp.h header to change the return type of mpz_get_ui to "unsigned long long" otherwise I would only get the lower 32 bits of the limb. I added a workaround when calling mpz_set_ui to set a mpz_t varaible to a 64-bit value. The other option was to modify GMP source, which would open a different can of worms. Since mpz_get_ui is inlined, only the gmp.h header was affected.

I suggested over on one of the GMP mailing lists that these functions should accept/return mp_limb_t instead of unsigned long int. That didn't seem to go anywhere with Torbjorn. I actually thought it was the best solution to the LP64 vs LLP64 issue.

The problem here is that everyone wants a solution but there is very little consensus on the best solution. Making the length of integers equal to the length of limbs is my favoured solution as well but there are quite a few who would prefer to remain with the native types. Maybe we could make it a build option - it would make sense to raise this again on the MPIR development list.

Brian

PS I have just raised this on the MPIR development list ([url]http://groups.google.com/group/mpir-devel[/url]) so if you have a view on the issue, please make a contribution.

[QUOTE=ATH;251197]
I'm thrilled to hear about the speed increase you get, it means it was worthwhile, and it means I can contribute to factoring in a very small way without running a big farm of machines on this expensive danish electricity :)[/QUOTE]

Another windows7/ATH factor, a Most Wanted first hole, 2p932
[code]
GMP-ECM 6.3 [configured with GMP 5.0.1 and --enable-asm-redc] [ECM]
Input number is 1356739987966904953632721972576078403163956516417810587829380945180425096663134055329485121363
1217798863488003630719265738790199930320569367914288147142843163611824593631207573695685889693715814543777 (200 digits)
Using B1=400000000, B2=15892277350966, polynomial Dickson(30), sigma=1660347379
Step 1 took 4432144ms
********** Factor found in step 1: 27586063883404498899786561888961349767475299128626440337
Found probable prime factor of 56 digits: 27586063883404498899786561888961349767475299128626440337 [/code]
The cofactor is a C144, reserved for Batalov+Dodson, gnfs. -Bruce

(The C200 was an earlier cofactor of a p59, also Dodson/ECMNET.)

I recompiled the MPIR builds with MPIR 2.3.0: [URL="http://www.hoegge.dk/GMP-ECM.html"]http://www.hoegge.dk/GMP-ECM.html[/URL]

There was no speed difference from the 2.1.1 builds (except abit faster on the pentium4 at 2000 digits). I still have the 2.1.1 files if someone has problems with the 2.3.0 version.

I don't know how to compile, so this thread looked good to me.

But I don't know how to use the program.

(I've been using YAFU.)

I downloaded [URL="http://www.hoegge.dk/mersenne/ecm63mpir230core2-64.zip"]ecm63mpir230core2-64.zip[/URL]. What now?

Put the number you want to factor in a file, for example number.txt .

In a command prompt type:
ecm.exe -h
for a list of options.

If you want to run ECM curves you type:
ecm.exe -c <curves> <B1> <B2> < number.txt

where <curves> is number of curves you want to run and B2 is optional, if left blank it chooses default B2 value corresponding to your chosen B1. For example 100 curves with B1=11000 and default B2:
ecm.exe -c 100 11000 < number.txt

If you want to run P-1 its:
ecm.exe -pm1 <B1> <B2> < number.txt
where B2 again is optional, and P+1:
ecm.exe -pp1 <B1> <B2> < number.txt

Here is the documentation which I didn't include with the binary, but which is available in the source files:
[URL="http://www.hoegge.dk/mersenne/README.txt"]README.txt[/URL] [URL="http://www.hoegge.dk/mersenne/INSTALL.txt"]INSTALL.txt[/URL] [URL="http://www.hoegge.dk/mersenne/NEWS.txt"]NEWS.txt[/URL]

Thanks for responding!

-h works. But when I try to factor a number the file can't be found.

You need to put the file "number.txt", or whatever you called it, in the same directory as ecm.exe

...Desktop\ecm63mpir230core2-64\ecm.exe -c 1000 1000000 <file.txt

It just says the file cannot be found.

I hardly ever use cmd...

Any help would be very much appreciated.

1.Create file called factor.bat in ecm63mpir230core2-64 folder, which is on your desktop.
2. Open it with notepad and paste the following in it:
[CODE]ecm.exe -c 25 2000000 800000000 <factorme.txt
pause[/CODE] and then save it.
3. Create a file called factorme.txt in the same folder, and paste numbers, which you want to factor, a number per line, and save it.
4. Launch the batch file to try to factor the number(s) with those parameters. Of course, you can always modify them as you wish.

This way you will loose the ouput if the cmd window is closed!!

You'd better use something like [CODE]ecm.exe -c 25 2000000 800000000 -inp number.txt > logfile.txt[/CODE]

As it turns out I don't know how to run a batch file either. But that would be good to learn too.

I'm probably missing something that is assumed to be obvious.

Select it and press enter:smile:

But [B]smh[/B] suggests a neat method - though I personally use something like
[code]ecm.exe -c 25 2000000 800000000 <factorme.txt >> log.txt
pause[/code]
This way, the new information is just appended, instead of replaced(when > is used).

However, this batch file can only be launched once, to launch N batches, where N is the number of cores you have, you'd need something more sophisticated(or easy?).

That just opens it in notepad again.

Maybe there's a better thread for me?

I think you have the real file extension hidden, so the factor.bat is actually a factor.bat.txt, which wont work.

I've made that batch file for you - it reads composites from factorme.txt, which must be in the same folder as ecm.exe, and prints anything found in log.txt. Now that you have the batch file, you can tweak B1 and B2 values using Notepad:smile:

I've factored dozens of numbers between 100 and 200 digits using over
10000 curves of
32bit Intel 6.3 (SVN 1566 with MPIR 2.3.0) 386 KB ecm63_svn1566_win32_intel.zip 03/20/2011
and earlier versions .
I'm not using anything fancy like -base2 or -B2scale .
I just invoke ecm from a cmd box with a B1 , and let B2 default .
I find that step 1 ( which I take to be the same as stage 1 ) takes
roughly about 3 times as long as step 2 , yet step 2 produces
roughly about 3 times as many factors as step 1 .
The -v option says that ( using a larger B1 will require fewer curves
and also ) using a -B2scale of 2 or 3 will require fewer curves .
But will the # of factors per week increase ?
The machine is a Pentium 4 3.33 GHz with MMX and SSE1,2,3 .

[QUOTE=Walter Nissen;262723]The -v option says that ( using a larger B1 will require fewer curves and also ) using a -B2scale of 2 or 3 will require fewer curves . But will the # of factors per week increase ?[/QUOTE]

Doesn't -v also give some "time to run the curves" values after the curve finishes?

[QUOTE=wblipp;262827]Doesn't -v also give some "time to run the curves" values after the curve finishes?[/QUOTE]

Excellent suggestion . Indeed , it does .
I'm collecting some estimates .

Thank you .

That reminds me.

Rule of thumb says 'spend as much time in stg2 as in stg1'.

But if I minimize the expected time to find a factor of a given size by adjusting the B2/B1-ratio, the result is far from that.

Did I misinterpret?

I have put SVN1582 Windows 32bit and 64bit binaries on my web site now:
[url]http://gilchrist.ca/jeff/factoring/[/url]

Among other things, this fixes the ability to use B1 values larger than 2^32.

It works with B1>2^32 ! Thanks alot for your work.

You build requires "Microsoft Visual C++ 2010 Redistributable Package" to work, it was complaining about missing "vcomp100.dll" before I installed it. People can get it here:
32bit: [URL="http://www.microsoft.com/download/en/details.aspx?id=5555"]http://www.microsoft.com/download/en/details.aspx?id=5555[/URL]
64bit: [URL="http://www.microsoft.com/download/en/details.aspx?id=14632"]http://www.microsoft.com/download/en/details.aspx?id=14632[/URL]

Is this B1 fix in the latest svn version, so it should work if I compiled it with msys+mingw64?

Anyone mind posting a link to a zip of the lastest svn, I'm not so good with those svn programs for windows.

[QUOTE=ATH;264068]It works with B1>2^32 ! Thanks alot for your work.

Is this B1 fix in the latest svn version, so it should work if I compiled it with msys+mingw64?

Anyone mind posting a link to a zip of the lastest svn, I'm not so good with those svn programs for windows.[/QUOTE]

I wrote the fix, so yes indeed, it does work with msys + mingw64! :smile: I have found an svn command line client that doesn't need installing (ie, doesn't need an msi, just unzip a zip file) and you can use it in msys or in a windows command prompt. I'm going to try to attach the zip file below. Once you have it, you can put it anywhere (I put it in c:\program files(x86)\svn\) and then put the bin directory (c:\program files(x86)\svn\bin) into your system path. Then you can use it in msys or cmd.exe. Then the command to check gmp-ecm out would be:

svn checkout svn://scm.gforge.inria.fr/svn/ecm/trunk svn

Which will download the trunk repository and put it in a folder called svn. Hmmm, the svn zip file I have is too big. I found the site I got it from, it's the Win32svn project on sourceforge here:
[url]http://sourceforge.net/projects/win32svn/files/[/url]
You can get the latest version and then download the zip folder instead of the msi. Let me know how it goes for you.

Great program, worked perfect. It was just something like this I wanted.

There is a problem though. The files "configure" and "install-sh" is missing, and I tried to use those from the "ecm-6.3.tar.gz" but it doesn't work. This is the first time I'm trying to compile the latest svn, so what am I missing?

In order to create configure and install-sh, you probably need to run an autogen.sh, bootstrap.sh or similar script, which is probably distributed alongside the configure.ac. Otherwise, maybe `autoreconf -i -f` would do the job.

[QUOTE=ATH;264068]It works with B1>2^32 ! Thanks alot for your work.

You build requires "Microsoft Visual C++ 2010 Redistributable Package" to work, it was complaining about missing "vcomp100.dll" before I installed it. [/QUOTE]

Thanks, I will update my web page. Although the latest SP1 version might be better.

32bit: [url]http://www.microsoft.com/download/en/details.aspx?id=8328[/url]
64bit: [url]http://www.microsoft.com/download/en/details.aspx?id=13523[/url]

Jeff.

[QUOTE=ATH;264080]Great program, worked perfect. It was just something like this I wanted.

There is a problem though. The files "configure" and "install-sh" is missing, and I tried to use those from the "ecm-6.3.tar.gz" but it doesn't work. This is the first time I'm trying to compile the latest svn, so what am I missing?[/QUOTE]

Oh yeah, I almost forgot, I had to use 'autoreconf -i' to generate those. You can get what you need from the mingw/msys directory on sourceforge here:
[url]http://sourceforge.net/projects/mingw/files/MSYS/[/url]

I can't remember specifically, but you might need the first two and maybe all three of the following:
autoconf (current latest on SF is 2.67-1-msys-1.0.15-bin)
automake (current latest on SF is 1.11.1-1-msys-1.0.13-bin)
libtool (current latest on SF is 2.4-1-msys-1.0.15-bin)

I think by the file names, you'll need at least Msys 1.0.15 to use these, and you can use the latest version of 7-zip (9.20) to extract those .tar.lzma files.

Also, if you have problems with --enable-asm-redc, make sure you have a unix find.exe in your msys bin directory. There's some sort of problem during 'make' if the windows find command is used, but the unix find command works just fine in this situation.

Hopefully that covers all the bases. Let me know how it goes. I'll talk with you later.

[QUOTE=WraithX;264119]There's some sort of problem during 'make' if the windows find command is used, but the unix find command works just fine in this situation.[/QUOTE]
The problem being that the Windows 'find' command is the equivalent of what is called 'fgrep' on sane operating systems...

Latest GMP 6.3.1 SVN 1582 compiled with MPIR 2.4.0 and GMP 5.0.2: [URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

Many credits to WraithX for helping me with several problems compiling this, and for coding the fix to GMP-ECM so we can use B1>2[sup]32[/sup] for P+1 and ECM.

[QUOTE=ATH;264585]Latest GMP 6.3.1 SVN 1582 compiled with MPIR 2.4.0 and GMP 5.0.2: [URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

Many credits to WraithX for helping me with several problems compiling this, and for coding the fix to GMP-ECM so we can use B1>2[sup]32[/sup] for P+1 and ECM.[/QUOTE]

WOW, your MPIR 2.4.0 binary was able to finish a B1=3e9 curve in 9.5 hours that normally takes me 10.5 hours. Can I ask, how did you compile MPIR 2.4.0? Did you need --enable-gmpcompat, or could gmp-ecm use the mpir.h file? Did you use the same './configure --host... --build...' that we used with gmp? I have a couple of Clovertown Xeon's and so I want to try a couple of different cpu versions in the build to see if I can get any more speed.

I use:
./configure --build=penryn-w64-mingw32 --host=penryn-w64-mingw32 --enable-gmpcompat
it doesn't work for me without --enable-gmpcompat.

./config.guess in MPIR always gives the best cpu it seems, but I noticed if I didn't use --build and --host it uses i686-pc-mingw32 further down:

[CODE]$ ./config.guess
penryn-w64-mingw32

$ ./configure --enable-gmpcompat
checking build system type... penryn-w64-mingw32
checking host system type... penryn-w64-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
.
.
checking for msgmerge... no
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for ld used by GCC... c:/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (c:/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... y
es[/CODE]

Indeed, currently the mpir240 for core2 for win64 with asm-reduction is the fastest binary I've ever seen! No icc needed:smile:

I switched from 'ecm[B]63[/B]mpir[B]230[/B]core2-64' to 'ecm[B]631[/B]mpir[B]240[/B]core2-64-[B]asmredc[/B]'.

The speedup seems to be several percent. I tried a few curves with B1=1e6 on a c207, using -B2scale 2.0. Seems to be >10% faster!

edit: More testing; conservative estimate of speedup when running 43e6 on c264 would be 5%. May very well be >10.

I just got a new Sandy Bridge laptop, and added a Core i7 Sandy Bridge build:

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

The new build is SVN 1588. I wasn't able to compile GMP 5.0.2, so there is only a MPIR 2.4.0, but that is way faster on 64bit hardware anyway, at least for core2.

It doesn't seem like MPIR or GMP-ECM has any AVX instructions yet because a build with "--march=corei7-avx --mtune=corei7-avx" was not faster, so this build is with "--march=corei7 --mtune=corei7".

I couldn't find any new "--build=" for corei7 so still using "--build=x86_64-w64-mingw32".

Curious, but ATH's Core2 binaries are actually faster than amd64 binaries from Jeff's website, for Phenom II x6 CPU.

[QUOTE=Karl M Johnson;266962]Curious, but ATH's Core2 binaries are actually faster than amd64 binaries from Jeff's website, for Phenom II x6 CPU.[/QUOTE]
If the amd64 binaries were optimised for athlon 64 or to some degree phenom I then they will have been optimised to not use SSE2 which was slow on those architectures. Intel never had the problem and phenom II fixed it for amd(phenom I was better but not sorted).

GMP-ECM 6.4 has been released.

Maybe we'll see some new precompiled binaries soon...

[QUOTE=lorgix;284916]GMP-ECM 6.4 has been released.[/QUOTE]

Thanks for the heads up. MPIR 2.5.0 was also just released with some speedups ([url]http://www.mpir.org/[/url]), not sure if they are used by GMP-ECM but when I get a chance I will start updating the binaries on my site.

[QUOTE=Jeff Gilchrist;285124]Thanks for the heads up. MPIR 2.5.0 was also just released with some speedups ([URL]http://www.mpir.org/[/URL]), not sure if they are used by GMP-ECM but when I get a chance I will start updating the binaries on my site.[/QUOTE]
Nice. Hopefully ATH will update his too, or maybe I'll try yours this time.
[QUOTE=ATH;264585]Latest GMP 6.3.1 SVN 1582 compiled with MPIR 2.4.0 and GMP 5.0.2: [URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

Many credits to WraithX for helping me with several problems compiling this, and for coding the fix to GMP-ECM so we can use B1>2[sup]32[/sup] for P+1 and ECM.[/QUOTE]

[QUOTE=lorgix;264677]I switched from 'ecm[B]63[/B]mpir[B]230[/B]core2-64' to 'ecm[B]631[/B]mpir[B]240[/B]core2-64-[B]asmredc[/B]'.

The speedup seems to be several percent. I tried a few curves with B1=1e6 on a c207, using -B2scale 2.0. Seems to be >10% faster!

edit: More testing; conservative estimate of speedup when running 43e6 on c264 would be 5%. May very well be >10.[/QUOTE]

Compiled the latest SVN 1681 (The official 6.4 is SVN 1672):

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

Didn't have a chance to do the speedtests yet. I will add them tomorrow or monday.


I skipped the core2 32bit and pentium4 versions. I'll add them if someone requests them, but I don't have access to the Core2 Conroe anymore, so the 32bit version will be on the Core2 Yorksfield.

thanks ATH

Can someone please compile ECM with/for AMD Bulldozer ? With xop flag ?

[QUOTE=ATH;285313]Compiled the latest SVN 1681 (The official 6.4 is SVN 1672):

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

Didn't have a chance to do the speedtests yet. I will add them tomorrow or monday.


I skipped the core2 32bit and pentium4 versions. I'll add them if someone requests them, but I don't have access to the Core2 Conroe anymore, so the 32bit version will be on the Core2 Yorksfield.[/QUOTE]
I get "signal -1073741795" from the i7 mpir w asmredc version. Google
seems to have seen this, but isn't very informative. Not sure which i7's we
have, maybe older ones missing avx? -Bruce

I can confirm that "ecm64-1681mpir250corei7-64-asmredc" works on Bulldozer.

[QUOTE=bdodson;286026]I get "signal -1073741795" from the i7 mpir w asmredc version. Google
seems to have seen this, but isn't very informative. Not sure which i7's we
have, maybe older ones missing avx? -Bruce[/QUOTE]

I added a new corei7 binary built with -march=corei7 -mtune=corei7 instead of core7-avx, maybe that helps.

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL]

[QUOTE=ATH;286034]I added a new corei7 binary built with -march=corei7 -mtune=corei7 instead of core7-avx, maybe that helps.

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL][/QUOTE]
Thanks, but looks like I'll need another link on the page to get a 5th
corei7 binary. Also, I won't be able to test the new binary until there's
a site that closes for the day. -Bruce

[QUOTE=bdodson;286041]Thanks, but looks like I'll need another link on the page to get a 5th
corei7 binary.[/QUOTE]

Did you try to hit F5 to refresh the page? Otherwise here is the direct links with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm64svn1681/ecm64-1681mpir250corei7noavx-64-asmredc.zip"]ecm64-1681mpir250corei7noavx-64-asmredc.zip[/URL]

[URL="http://www.hoegge.dk/mersenne/ecm64svn1681/ecm64-1681mpir250corei7noavx-64.zip"]ecm64-1681mpir250corei7noavx-64.zip[/URL]

[QUOTE=ATH;286066]Did you try to hit F5 to refresh the page? Otherwise here is the direct links with and without --enable-asm-redc:
[URL="http://www.hoegge.dk/mersenne/ecm64svn1681/ecm64-1681mpir250corei7noavx-64-asmredc.zip"]ecm64-1681mpir250corei7noavx-64-asmredc.zip[/URL]

[URL="http://www.hoegge.dk/mersenne/ecm64svn1681/ecm64-1681mpir250corei7noavx-64.zip"]ecm64-1681mpir250corei7noavx-64.zip[/URL][/QUOTE]
Thanks, I see the two new binaries now. Our i7's turn out to be
"i7 quad core 870"'s, not the i7-2700k 2nd generation chips. Typical
purchasing for us, commodity chips for public pc's, library. More than
sufficient for word processing and web surfing. I have
[code]
341602 Jan 24 2011 ecm63mpircore2-64-asmredc.zip
999345 Jan 12 13:44 ecm64-1681mpir250corei7noavx-64-asmredc.zip
[/code]
and on
[code]
Input number is 18497627458323369222497070876046723999931638433141649181124615832553914429217118808483686055543196404160468420183749785716365582925168760774103407003448171479049297661884597054335772234218906543053621
(200 digits)
[/code]
the new binary appears just slightly slower
[code]
< GMP-ECM 6.3 [configured with GMP 5.0.1 and --enable-asm-redc] [ECM]
---
> GMP-ECM 6.4 [configured with MPIR 2.5.0, --enable-asm-redc] [ECM]
3,5c3,5
< Using B1=400000000, B2=5821851770290, polynomial Dickson(30), sigma=62857100
< Step 1 took 4328684ms
< Step 2 took 1681738ms
---
> Using B1=400000000, B2=5821851770290, polynomial Dickson(30), sigma=637635111
> Step 1 took 4481549ms
> Step 2 took 1691316ms [/code]
Suppose it's good to switch anyway. Regards, Bruce

I'm surprised the GMP build is faster than MPIR. Maybe you should try the Core2 build instead of Corei7 one? It might be closer to your Corei7 870, or maybe the Corei7 old 6.3.1 build with MPIR?

MPIR has been faster for 64bit in both 6.3, 6.3.1 and now 6.4. Maybe it is a 32 bit Windows? If it is I can build a 32 bit binary if needed.

[QUOTE=bdodson;286100]
...
the new binary appears just slightly slower
[/QUOTE]

Could you please compare that with my core2-binary ([URL="http://www.kay-schoenberger.de/eng/math/ecm/binaries/ecm64_win64_core2.zip"]link[/URL]) on your i7, I only have a core2, but the timings for stage 2 differ from the timings posted here. As I see it, MPIR is faster on Win64 but not on Linux64 (there is no real difference to gmp).
By the way, has anybody successfully run the 'tuneup' command for building MPIR, according to /doc/mpir.info-1 ? I got an error message here.

[QUOTE=ATH;286034]I added a new corei7 binary built with -march=corei7 -mtune=corei7 instead of core7-avx, maybe that helps.

[URL="http://www.hoegge.dk/GMP-ECM.html"]GMP-ECM.html[/URL][/QUOTE]
I switched from [B]ecm631mpir240core2-64-asmredc[/B] to [B]ecm64-1681mpir250core2-64-asmredc[/B].

I did a little testing, and it seems the new version is slower (at least for small inputs).

[QUOTE=Yamato;286149]Could you please compare that with my core2-binary ([URL="http://www.kay-schoenberger.de/eng/math/ecm/binaries/ecm64_win64_core2.zip"]link[/URL]) on your i7, I only have a core2, but the timings for stage 2 differ from the timings posted here. As I see it, MPIR is faster on Win64 but not on Linux64 (there is no real difference to gmp).
By the way, has anybody successfully run the 'tuneup' command for building MPIR, according to /doc/mpir.info-1 ? I got an error message here.[/QUOTE]
Thanks, but these are windows7 machines. Regards, Bruce

[QUOTE=ATH;286106]I'm surprised the GMP build is faster than MPIR. Maybe you should try the Core2 build instead of Corei7 one? It might be closer to your Corei7 870, or maybe the Corei7 old 6.3.1 build with MPIR?

MPIR has been faster for 64bit in both 6.3, 6.3.1 and now 6.4. Maybe it is a 32 bit Windows? If it is I can build a 32 bit binary if needed.[/QUOTE]
I've assumed that I have the MPIR build and

GMP-ECM 6.3 [configured with GMP 5.0.1 and --enable-asm-redc] [ECM]

is a reporting error? I'm double checking, and get
[code]
unzip -v ecm63mpircore2-64-asmredc.zip

Archive: ecm63mpircore2-64-asmredc.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
887156 Defl:N 341454 62% 01-22-11 21:43 95f18f0f ecm.exe
-------- ------- --- -------
887156 341454 62% 1 file
-----------
-rwxr-xr-x+ 1 bad0 faculty 887156 Jan 22 2011 ecm63core2-64asm

and

diff ecm63core2-64asm /tmp/bdtmp/ecm.exe

[binary files are the same] [/code]
This is surely the binary that was in the MPIR tarfile last January.

As I was reporting back then, these pcs run windows7, an upgrade for
our public sites from xp, and the 64-bit performance was way-up from
any of the 32-bit binaries. -Bruce

[QUOTE=bdodson;286160]Thanks, but these are windows7 machines. Regards, Bruce[/QUOTE]

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.

[QUOTE=Jeff Gilchrist;286192]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.[/QUOTE]
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

[QUOTE=bdodson;286289]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[/QUOTE]
For 3m701, C261 with B1=400M, default B2, I get
[code]
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 [/code]
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:
[code]
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 [/code]
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.

[QUOTE=Yamato;286149]I only have a core2, but the timings for stage 2 differ from the timings posted here.[/QUOTE]

[QUOTE=bdodson;286362]For 3m701, C261 with B1=400M, default B2, I get[/QUOTE]

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.

[URL="http://www.hoegge.dk/mersenne/GMPECMtests/core2-64bittests.html"]core2-64bittests.html[/URL]
[URL="http://www.hoegge.dk/mersenne/GMPECMtests/corei7-64bittests.html"]corei7-64bittests.html[/URL]

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.

[QUOTE=ATH;286378]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.

[URL="http://www.hoegge.dk/mersenne/GMPECMtests/core2-64bittests.html"]core2-64bittests.html[/URL]
[URL="http://www.hoegge.dk/mersenne/GMPECMtests/corei7-64bittests.html"]corei7-64bittests.html[/URL]

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.[/QUOTE]
So there's no reason to use ecm64-1681mpir250core2-64-asmredc?

Btw; Does anyone know why this happens?

[QUOTE=lorgix;286385]So there's no reason to use ecm64-1681mpir250core2-64-asmredc?

Btw; Does anyone know why this happens?[/QUOTE]Raymond Chen had a [URL="http://blogs.msdn.com/b/oldnewthing/archive/2011/12/08/10245330.aspx"]post[/URL] on that last month. It's because of the assertion failure.....

[QUOTE=schickel;286428]Raymond Chen had a [URL="http://blogs.msdn.com/b/oldnewthing/archive/2011/12/08/10245330.aspx"]post[/URL] on that last month. It's because of the assertion failure.....[/QUOTE]
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.

[QUOTE=lorgix;286587]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.[/QUOTE]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?

[QUOTE=schickel;286588]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?[/QUOTE]
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.

[QUOTE=bdodson;286362]For 3m701, C261 with B1=400M, default B2, I get
[code]
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 [/code]
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, .. [/QUOTE]
Looks like the comparison depends rather close on the size
of the numbers; here's C271, B1=400M, all with B2=15892277350966.
[code]
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 [/code]
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

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.

YES!
Grand idea.
I have a Traktor cpu and wanna find out whether gcc will produce faster code for native binaries(along with a xop flag), so I am more than willing to test it.
I have win7 x64 OS.

[QUOTE=ATH;287086]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.[/QUOTE]
If I could be guided through the process, I'd like to try it.

win7 x64 at the moment.

If anyone else want to try compile gmpecm on your own machine (64 bit windows only), you need at least 650 Mb free on your c-drive. Thanks to Karl M Johnson for testing this. Thanks to WraithX for teaching me how to compile 64bit gmpecm.

1) Get the 82 Mb zip-file: [URL="http://www.hoegge.dk/mersenne/gmpecmcompile.zip"]gmpecmcompile.zip[/URL]
2) Extract gmpecmcompile.zip with 7-zip ([url]http://www.7-zip.org/[/url]) to the root of your c-drive: c:\ This will extract 3 folders: Msys, Mingw64, Python27 and a batch file: msys.bat
3) Run the c:\msys.bat (or the C:\msys\1.0\msys.bat). This will open the msys command window.
4) type: "mpircompile.bat" to compile MPIR. Choose in the menu which processor you have by typing A,B,C,D,E,F,G,H,I or J.
5) type: "gmpecm-compile.bat" to compile GMP-ECM. It will tune parameters for your computer so it will be best to turn off other programs during this.
6) get your ecm.exe in "C:\msys\1.0\home\gmpecm64" or in "C:\msys\1.0\local\bin"




More detailed explanation of the batch files:
mpircompile.bat will run config.guess to get the suggested build, which MPIR does very well. Then it will run:
configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -std=gnu99 -march=<processor> -mtune=<processor>" --enable-gmpcompat --build=<build> --host=<build>
where <processor> can be: corei7-avx, corei7, core2, atom, bdver1 (bulldozer), barcelona, opteron-sse3, opteron, athlon64-sse3, athlon64 and where <build> is the build from config.guess. For corei7-avx it adds the -mavx flag and for bulldozer it adds -mavx -mxop flags.
Then it will do:
make
make install
make check

gmpecm-compile.bat will first update the gmpecm64 folder to the latest svn, then it will run:
autoreconf -i
configure ABI=64 CC=gcc CFLAGS="-O3 -m64 -std=gnu99 -march=<processor> -mtune=<processor>" LDFLAGS="-Wl,--stack,16777216" --enable-asm-redc --build=x86_64-w64-mingw32 --disable-assert --with-gmp=/usr/local
make
make check
make ecm-params; make
make install
where <processor> is the same as in MPIR compiling, and again -mavx added for core7-avx and -mavx -mxop for bulldozer.

[QUOTE=bdodson;286948]Looks like the comparison depends rather close on the size
of the numbers; ...
where the 63-binary was from ecm63mpircore2-64-asmredc.zip but
reports using gmp, ... 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[/QUOTE]
Well, just for completeness, and before the outfiles get cat'ed away,
3m653, C289 with B1 = 600M gives a third different timing outcome
[code]
c3m653a.1:Step 1 took 6391657ms
c3m653a.1:Step 2 took 991745ms

c3m653b.1:Step 1 took 6389941ms
c3m653b.1:Step 2 took 987174ms

c3m653ci2.1:Step 1 took 6672147ms
c3m653ci2.1:Step 2 took 1002322ms

c3m653di2.1:Step 1 took 6915727ms
c3m653di2.1:Step 2 took 1011776ms [/code]
both with default B2 = 9535594068016. That's 63 winning in step1 ...

-Bruce

[QUOTE=bdodson;287917]Well, just for completeness, and before the outfiles get cat'ed away,
3m653, C289 with B1 = 600M gives a third different timing outcome
both with default B2 = 9535594068016. That's 63 winning in step1 ...

-Bruce[/QUOTE]

Maybe you should try and compile them yourself? I assume all you computers are the same processor, so just compile on one machine and delete folders afterwards, no installation needed.



Added an option to compile the old GMP-ECM 6.3 since it seems a few percent faster.