[QUOTE=wombatman;355816]Here's a post that might have a fix for the B1=1 bug:

[url]http://mersenneforum.org/showpost.php?p=350034&postcount=174[/url]

Also, my version is 32-bit. Are you using a 32 or 64 bit build? I went ahead and ran 480 curves of your C192 at 4e4--no factors found.[/QUOTE]

Thanks for the link. That workaround seems to fix it. I'm using the 64-bit version.

[QUOTE=frmky;355811]Has anyone gotten save/resume to work? Here's what I get:

[CODE]./ecm -gpu -save c192.ecm 4e4 0 < C192
GMP-ECM 7.0-dev [configured with GMP 5.1.3, --enable-asm-redc, --enable-gpu, --enable-assert, --enable-openmp] [ECM]
Input number is 361867761627749619574674677769104106609222942556126375131641520128131226876942053491915389383216114202550615939995196059592933366284139274937165773815556682024285008268664983092158298987980517 (192 digits)
Using B1=40000, B2=0, sigma=3:3642364246-3:3642365077 (832 curves)
Computing 832 Step 1 took 472ms of CPU time / 21426ms of GPU time
[/CODE]
This gives a save file like
[CODE]
METHOD=ECM; PARAM=3; SIGMA=3642365077; B1=1; N=361867761627749619574674677769104106609222942556126375131641520128131226876942053491915389383216114202550615939995196059592933366284139274937165773815556682024285008268664983092158298987980517; X=0x7cb7309ea2ec4ee5d88962fa7516f43385ad69f16e28b04b8beee48d15091cf009cd4119d57a505d6c062036b1d8a784d11d4d87873df12d62bc03b9f10e7a1671e666030d895d55d22d5da9743992e; CHECKSUM=3136759905; PROGRAM=GMP-ECM 7.0-dev; X0=0x0; Y0=0x0; WHO=cluster@compute-0-1.local; TIME=Wed Oct 9 17:49:08 2013;
[/CODE]
Then on resume:
[CODE]./ecm -resume c192.ecm 4e4
GMP-ECM 7.0-dev [configured with GMP 5.1.3, --enable-asm-redc, --enable-gpu, --enable-assert, --enable-openmp] [ECM]
Resuming ECM residue saved by cluster@compute-0-1.local with GMP-ECM 7.0-dev on Wed Oct 9 17:49:08 2013
Input number is 361867761627749619574674677769104106609222942556126375131641520128131226876942053491915389383216114202550615939995196059592933366284139274937165773815556682024285008268664983092158298987980517 (192 digits)
Error, x0 should be equal to 2 with this parametrization
Please report internal errors at <ecm-discuss@lists.gforge.inria.fr>.
[/CODE]
Does this work for anyone? Thanks![/QUOTE]Bizarre! I've never seen the B1 bug which is why I've been plugging the workaround.

Has this been reported to the dev team?

No idea. I think the save/resume bug is known to at least one developer (Cyril?), but I don't know about the B1=1 bug.

[QUOTE=wombatman;355836]No idea. I think the save/resume bug is known to at least one developer (Cyril?), but I don't know about the B1=1 bug.[/QUOTE]Ho hum. Some times my style is just too oblique and a hint has to be hammered in with a length of two by four.

To state the bleedin' obvious: the bug should be reported to the GMP-ECM team, whether or not they've already heard of it.

[QUOTE=wombatman;355618]I imagine it would work fine by directing yafu to it, but you wouldn't be using the GPU to actually run the curves. As such, it would be simpler to use the standard GMP-ECM. In addition, there's a bug (at least in the versions I've compiled) where factors that should be found in Stage 2 are not found by the GPU version. So you'd likely miss factors if you tried to use the GPU-enabled version.[/QUOTE]

Why wouldn't the GPU be used? If you point yafu to the gpu-ecm executable (no need to rename it even), then it simply runs that executable using system() calls. So if gpu-ecm.exe uses the GPU then so would yafu.

The only catch is whether or not the output file looks the same as the normal gmp-ecm, since yafu looks for a specific format in the output file (namely, something like: ********** Factor found in step 1: 1406933576204831). If this format hasn't changed with gpu-ecm then you should be good to go using it with yafu.

The only reason I wasn't sure is that you have to pass a "-gpu" flag to enable GPU running. Otherwise, it just uses the normal CPU-based Stage 1. The other issue is the save/resume bug that hasn't been resolved, as far as I know. I think the output file is the same. Maybe I'll play around with the GPU-based one and see what happens. It also has a minimum number of curves it will run (32, I think), so it can be a bit harder to control. Not sure how it would effect the multi-threading aspect either, since you don't need to multi-thread the Stage 1 part, but you would want to multi-thread the Stage 2.

I've not done a bug report before, but I can certainly take a whack at it.

[QUOTE=xilman;355841]Ho hum. Some times my style is just too oblique and a hint has to be hammered in with a length of two by four.

To state the bleedin' obvious: the bug should be reported to the GMP-ECM team, whether or not they've already heard of it.[/QUOTE]

Edit: Bug report about B1=1 bug submitted.

[QUOTE=wombatman;355849] The only reason I wasn't sure is that you have to pass a "-gpu" flag to enable GPU running. Otherwise, it just uses the normal CPU-based Stage 1. [/QUOTE]

Ah, wasn't aware of that. The system command string is hardcoded, so there's no way to add that flag without changing the code. Bummer.

[QUOTE=wombatman;355849]
It also has a minimum number of curves it will run (32, I think), so it can be a bit harder to control. Not sure how it would effect the multi-threading aspect either, since you don't need to multi-thread the Stage 1 part, but you would want to multi-thread the Stage 2. [/QUOTE]

More good points - I guess I should have learned how the program works before posting. With these complications it would not really work to run gpu-ecm in yafu, whether or not the -gpu flag thing gets fixed.

It's not a huge deal. I guess in theory you could have it do the save/resume within Yafu, but it doesn't seem worth it.

These things are easy to fix with a combination of batch file running ecm and yafu running with -noecm or with a "very lite" plan. I don't think that BB need to invest time into it for now. There are few more important things on the list... (no, I am not talking about "loop and screws" this time :razz:). Just my two cents...

[QUOTE=wombatman;355850]
Edit: Bug report about B1=1 bug submitted.
[/QUOTE]

The bug should be fixed by today's commit (cf the email to the mailing list). Once again, thanks for reporting this bug.

And thank you for fixing it so quickly!

[QUOTE=Cyril;356177]The bug should be fixed by today's commit (cf the email to the mailing list). Once again, thanks for reporting this bug.[/QUOTE]

Where can I download the source for the GPU version from. I've searched [url]https://gforge.inria.fr/projects/ecm/[/url] but can't find it.

I've just got a second hand GTX 560 Ti and want to start using it for factoring on Linux.

Chris

[QUOTE=chris2be8;364005]Where can I download the source for the GPU version from. I've searched [url]https://gforge.inria.fr/projects/ecm/[/url] but can't find it.

I've just got a second hand GTX 560 Ti and want to start using it for factoring on Linux.

Chris[/QUOTE]You need to use the SVN version. If that isn't enough of a clue, mail me for details. However, Google is your friend ...

As is often the case, compiling from svn gives some rather unclear error messages unless you know what you're doing with automake; I don't but I know a man who does.

[code]
sudo apt-get install automake libtool
svn checkout --username anonsvn https://scm.gforge.inria.fr/svn/ecm/trunk
autoreconf -si
./configure --enable-gpu=sm20 --enable-sse2 --enable-openmp
make
make check
[/code]

appears to have built something for me. 512 curves at 1e4 take about two seconds on the GTX-580, so I'm running a few thousand at 1e8 overnight.

This is likely to be an "interesting" exercise. openSUSE uses zypper instead of apt-get. But:
[code] linux-5hwg:~ # zypper install subversion
* Reading repository 'Main Repository (OSS)' cache
* Reading repository 'Packman Repository' cache
* Reading repository 'openSUSE-10.3-DVD 10.3' cache
* Reading repository 'Main Repository (NON-OSS)' cache
* Reading repository 'VideoLan Repository' cache
* Reading installed packages [100%]


The following NEW packages are going to be installed:
libapr-util1 libapr1 subversion

Overall download size: 1.5 M. After the operation, additional 5.1 M will be used.
Continue? [yes/no]: yes
Downloading package libapr1-1.2.9-9.x86_64, 112.1 K (271.2 K unpacked)
Downloading: media
* Downloading [0%]
Problem downloading the package file from the repository:
Media source http://download.opensuse.org/repositories/openSUSE:10.3/standard/ does not contain the desired media
Please, see the above error message to for a hint.
[/code]

This comes from sticking with an old version with a GUI I can run from the keyboard, instead of one that insists you use the mouse all the time. I'll probably end up installing subversion on another system to get round this.

But first I have to get round the sockets on the 560 not fitting the monitor leads from my KVM switch. So I need a motherboard I can plug two cards into. Then start trying to use it.

I may be back with more questions later. Or asking about msieve poly selection.

Chris

Doing 512 curves with b1=1e8 on the GTX580 takes 21.2 kiloseconds clock time: 41.4 seconds per curve.

Doing the second stage on a single residue takes 150 seconds on one thread of an i7-4930; the machine has twelve threads so that's 12.5 further seconds of real time per curve.

Trying various b2 values and seeing how the expected time to find a 50-digit factor using the GPU to run curves in blocks of 512 and the 12 threads to run stage 2 changes, it seems that the default B2 value is still pretty much right.

[QUOTE=fivemack;364112]Doing 512 curves with b1=1e8 on the GTX580 takes 21.2 kiloseconds clock time: 41.4 seconds per curve.

Doing the second stage on a single residue takes 150 seconds on one thread of an i7-4930; the machine has twelve threads so that's 12.5 further seconds of real time per curve.

Trying various b2 values and seeing how the expected time to find a 50-digit factor using the GPU to run curves in blocks of 512 and the 12 threads to run stage 2 changes, it seems that the default B2 value is still pretty much right.[/QUOTE]

Tell us the ratio of number of curves per watt-hour on that GPU vs CPU? Is it worth?

The GPU flat-out is about 200 watts - I don't particularly want to go out to the shed in the cold to read the wattometer for an exact value - and does 512 curves in 4.2 megajoules: 8.2 kilojoules per curve.

The CPU flat-out is about 160 watts (that's for the whole computer, whilst the 200 watts were differential - but it's reasonable to assume that I turn the computer off in the unfortunate event that it's doing nothing) and does 12 stage-1 curves in 497 seconds: 6.6 kilojoules per curve. stage-2 is 142 seconds, 2kJ per curve.

This is on a C156, so the GPU is running at a bit of a disadvantage - it would be exactly the same speed on a C300 - but I happened to be interested in a C156 this evening.

On the other hand the GPU cost £90 and the computer was £1250; and I can run stage-one on the GPU without slowing down other jobs on the machine (which doesn't seem to be so much the case for msieve polynomial select)

[QUOTE=fivemack;364112]Doing 512 curves with b1=1e8 on the GTX580 takes 21.2 kiloseconds clock time: 41.4 seconds per curve.

Doing the second stage on a single residue takes 150 seconds on one thread of an i7-4930; the machine has twelve threads so that's 12.5 further seconds of real time per curve.

Trying various b2 values and seeing how the expected time to find a 50-digit factor using the GPU to run curves in blocks of 512 and the 12 threads to run stage 2 changes, it seems that the default B2 value is still pretty much right.[/QUOTE]

How big was the composite?

This is truly awesome performance. Kudos to the people who wrote this
code!

How is the GPU able to do step 2? Is it doing the "classic" step 2? (i.e.
one prime at a time) My instinct tells me that a convolution based
step-2 would require too much memory per curve for a GPU to handle
it. It would thrash its guts out.

[QUOTE=R.D. Silverman;364312]How big was the composite?

This is truly awesome performance. Kudos to the people who wrote this
code!

How is the GPU able to do step 2? Is it doing the "classic" step 2? (i.e.
one prime at a time) My instinct tells me that a convolution based
step-2 would require too much memory per curve for a GPU to handle
it. It would thrash its guts out.[/QUOTE]


I have a request. Kleinjung, Franke, et.al. have grabbed that last
of the Cunningham 2- numbers that were left from the first modern
edition (1987) of the book. These numbers were subjected to extensive
ECM effort with first limit 3 x 10^9 by EPFL.

Let's use this GPU ECM implementation to perform a similar effort
on the Cunningham 2+ tables: 2+ odd, 2+ divisible by 4, and 2LM.
EPFL applied some effort to these numbers, as has Bruce.

Maybe we can find enough ECM factors to have some hope of finishing
off the remainder with NFS???

I'd like to see 100K curves run with B1 = 3 x 10^9.

I promised Dick Lehmer that I would push to finish off the 1987
edition of the book.

I'd like to see these tables finished while I am still alive as well. :smile:

[QUOTE=R.D. Silverman;364314]I have a request. Kleinjung, Franke, et.al. have grabbed that last
of the Cunningham 2- numbers that were left from the first modern
edition (1987) of the book. These numbers were subjected to extensive
ECM effort with first limit 3 x 10^9 by EPFL.

Let's use this GPU ECM implementation to perform a similar effort
on the Cunningham 2+ tables: 2+ odd, 2+ divisible by 4, and 2LM.
EPFL applied some effort to these numbers, as has Bruce.

Maybe we can find enough ECM factors to have some hope of finishing
off the remainder with NFS???

I'd like to see 100K curves run with B1 = 3 x 10^9.

I promised Dick Lehmer that I would push to finish off the 1987
edition of the book.

I'd like to see these tables finished while I am still alive as well. :smile:[/QUOTE]

The GPU version of ECM runs stage 1 in parallel on the GPU, and stage 2 on the CPU.
IIRC, it is limited to candidates of about 1018 bits.

[STRIKE]Is the list reported [URL="http://www.mersenneforum.org/showthread.php?t=4427"]here[/URL] updated? If not, where can we find out the updatesd list, and [/STRIKE]where should we report our effort? I think this project is doable with some help.

Luigi

[QUOTE=ET_;364316]The GPU version of ECM runs stage 1 in parallel on the GPU, and stage 2 on the CPU.
IIRC, it is limited to candidates of about 1018 bits.

[STRIKE]Is the list reported [URL="http://www.mersenneforum.org/showthread.php?t=4427"]here[/URL] updated? If not, where can we find out the updatesd list, and [/STRIKE]where should we report our effort? I think this project is doable with some help.

Luigi[/QUOTE]

Report [i]results[/i] to Sam Wagstaff. I believe that GIMPS has an
ECM page where one can report curve counts.

BTW, It would not be hard to implement a classic "stage 2" for ECM on
a GPU. Memory requirements would be small and the code can be easily
built from Stage 1 code.

Read Peter Montgomery's (superb) paper: Speeding the
Pollard and Elliptic Curve Methods of Factorization.

[QUOTE=ET_;364316]The GPU version of ECM runs stage 1 in parallel on the GPU, and stage 2 on the CPU.
IIRC, it is limited to candidates of about 1018 bits.

Luigi[/QUOTE]

For what it's worth, I was able to increase that limit by changing (I think) ECM_GPU_NB_DIGITS from 32 to 64 in ecm-gpu.h. An executable compiled as such was able to find the example factor posted earlier in this thread. This was done using the "-save"/"-resume" method, though. I haven't tried simply letting it complete everything in one round.

Edit: I should also note that I haven't tried it out on numbers greater than that 1018 limit--perhaps I can try it today at some point.

[QUOTE=wombatman;364324]For what it's worth, I was able to increase that limit by changing (I think) ECM_GPU_NB_DIGITS from 32 to 64 in ecm-gpu.h. An executable compiled as such was able to find the example factor posted earlier in this thread. This was done using the "-save"/"-resume" method, though. I haven't tried simply letting it complete everything in one round.

Edit: I should also note that I haven't tried it out on numbers greater than that 1018 limit--perhaps I can try it today at some point.[/QUOTE]
I have not gotten the 2048-version you posted earlier in this thread to work. And the 512 didn't have the expected speed-up.

Does anyone have working binaries for larger or smaller numbers?

If you want to try the latest version (which is 32-bit) I put together, take a whack with this one. It should be the one that successfully found the factor from here: [url]http://www.mersenneforum.org/showpost.php?p=349403&postcount=168[/url]

Again, I did the "-save" followed by "-resume".

I'm currently running a C331 that I know has a 33 digit factor to see if this exe finds it with the save/resume stuff. If it doesn't, I'll try save/resume and see if that works.


Edit: Also just confirmed that my other version of the file, which does not have the 32 to 64 change I mentioned, won't even attempt the same C331 I'm currently running.

[QUOTE=R.D. Silverman;364312]How big was the composite?

This is truly awesome performance. Kudos to the people who wrote this
code!

How is the GPU able to do step 2? Is it doing the "classic" step 2? (i.e.
one prime at a time) My instinct tells me that a convolution based
step-2 would require too much memory per curve for a GPU to handle
it. It would thrash its guts out.[/QUOTE]

The GPU isn't doing step 2. I'm collecting step-1 results and running through them in twelve threads on a pretty fast CPU. As I calculated, the GPU gives about the same step-1 performance as using just the fast CPU (it has forty times as many cores of about a fortieth the speed), but I can run step-1 on GPU while the CPU is doing something else entirely without slowing down the CPU.

Convolution-based step 2 is using about half a gigabyte per curve, so wouldn't fit plausibly on the GPU.

[QUOTE=wombatman;364330]If you want to try the latest version (which is 32-bit) I put together, take a whack with this one. It should be the one that successfully found the factor from here: [URL]http://www.mersenneforum.org/showpost.php?p=349403&postcount=168[/URL]

Again, I did the "-save" followed by "-resume".

I'm currently running a C331 that I know has a 33 digit factor to see if this exe finds it with the save/resume stuff. If it doesn't, I'll try save/resume and see if that works.


Edit: Also just confirmed that my other version of the file, which does not have the 32 to 64 change I mentioned, won't even attempt the same C331 I'm currently running.[/QUOTE]
Thanks!

It seems to be working, but it doesn't write to the save file.
I use a batch file like this:
[CODE]ecm_gpu_32bit_2048_ITER.exe -n -v -gpu -gpucurves 960 -B2scale 0 -one -savea save.txt -c 960 50000 <factorme.txt >> log.txt
pause[/CODE]Also, it doesn't seem to finish (cmd does not tell me it is done).

[QUOTE=lorgix;364391]Thanks!

It seems to be working, but it doesn't write to the save file.
I use a batch file like this:
[CODE]ecm_gpu_32bit_2048_ITER.exe -n -v -gpu -gpucurves 960 -B2scale 0 -one -savea save.txt -c 960 50000 <factorme.txt >> log.txt
pause[/CODE]Also, it doesn't seem to finish (cmd does not tell me it is done).[/QUOTE]

I wouldn't waste any time on it...I did some more work with it yesterday, and it doesn't seem to pick up some of the factors. I tried it with a simple 18 digit factor, and it didn't get it. I'd like to try and build a 64-bit version of it and see if that does the trick or not.

I didn't have any issues with getting it to save curves though. One thing you have to do is set B2 to 0 for the "-save" part. Then, when you do resume, you have to not use "-gpu" or it will run the Stage 1 part for every single curve. Kind of a pain. I'm going to recheck it on my 32-bit system and see if it works there or not.

Also, here is a file that was sent to me at some point (though, embarrassingly, I don't remember by whom!) that you can use to quick-check the GPU-ECM. I wouldn't rely on it solely, but it's a good 1st check.

Usage is:

[CODE]test.gpuecm Name_of_GPU_ECM_exe[/CODE]



Edit: And yeah, both the 2048 and 512 bit ones fail the test. Back to the drawing board, I guess.

[QUOTE=fivemack;364023]As is often the case, compiling from svn gives some rather unclear error messages unless you know what you're doing with automake; I don't but I know a man who does.

[code]
sudo apt-get install automake libtool
svn checkout --username anonsvn https://scm.gforge.inria.fr/svn/ecm/trunk
autoreconf -si
./configure --enable-gpu=sm20 --enable-sse2 --enable-openmp
make
make check
[/code]appears to have built something for me. 512 curves at 1e4 take about two seconds on the GTX-580, so I'm running a few thousand at 1e8 overnight.[/QUOTE]

When I tried that I got:
[code] chris@4core ~ $ svn checkout --username anonsvn https://scm.gforge.inria.fr/svn/ecm/trunk
Authentication realm: INRIAGForge User Authentication
Password for 'anonsvn':
Authentication realm: INRIAGForge User Authentication
Username:
[/code]
I tried an email address for the password. Any ideas?

Chris

Try:
[code]
svn checkout svn://scm.gforge.inria.fr/svn/ecm/trunk
[/code]That worked for me and it is referenced on this GMP-ECM page:

[URL="https://gforge.inria.fr/scm/?group_id=135"]SCM Repository[/URL]

[QUOTE=chris2be8;364453]When I tried that I got:
[code] chris@4core ~ $ svn checkout --username anonsvn https://scm.gforge.inria.fr/svn/ecm/trunk
Authentication realm: INRIAGForge User Authentication
Password for 'anonsvn':
Authentication realm: INRIAGForge User Authentication
Username:
[/code]
I tried an email address for the password. Any ideas?

Chris[/QUOTE]

The password is also anonsvn

Thanks, downloaded successfully.

From the Monday morning guide to Computer terminology:
Interface: (n) The place the solution to a problem often stares.

Chris

I though installing this would be "interesting". After fixing several issues I found that the CUDA 5.5 toolkit only works on some Linux versions and the PC I want to install it on runs too *high* a level (Ubuntu 13.04, though packaged as Linux Mint). And I can't downgrade Linux or the NIC won't work.

The Nvidia web site says the CUDA 6.0 toolkit will soon be available. Does anyone know when it will be released and if it would support Ubuntu 13.04.

I have got a PC running openSUSE 12.2 which I could install the CUDA toolkit on. But it already has cooling problems so adding a 200 watt GPU to it would not be ideal.

Chris

Ubuntu 12.04 has an earlier version of the CUDA toolkit in its repository. Just out of curiosity, does 13.04 also have a CUDA toolkit? If so, which one?

Thanks.

[SIZE=1]Disappointment has plagued my CUDA endeavours - I installed CUDA 5.5 successfully onto my 12.04 system and discovered that I needed at least arch 1.3 for GMP-ECM - mine is arch 1.2. I then found that although it compiles, msieve wouldn't run CUDA on this machine, either (but, that's another topic)...[/SIZE]

I got this when I tried to install cuda on my Ubuntu 13.04 system:
[code] 4core ~ # apt-get install cuda
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package cuda
[/code]So it doesn't have a CUDA toolkit available to install.

I have got another system I can probably upgrade to openSUSE 12.2 and fit the GPU into the case. But that's not guaranteed to work.

I'm keeping notes. When/if I get it working I'll post anything I think likely to help other people.

Chris

Edit. Forget that, I'd shut the PC down to put the GPU into it, and forgot to run "route add default gw 192.168.1.1" so it could connect to the internet (is that the first thing to spring to mind?) Now after "apt-get update" "apt-get install cuda" is running now.

Try looking for package nvidia-cuda-dev

I certainly have that installed on 13.10 on the machine that's currently running gpu-ecm; packages.ubuntu.com suggests it exists on 13.04

I've installed packages nvidia-cuda-dev and cuda and all their pre-requisites and rebooted, but it still won't work because the nvidia driver module isn't loaded:
[code] chris@4core ~/ecm-gpu/trunk $ ./test.gpuecm ./ecm
GMP-ECM 7.0-dev [configured with GMP 5.1.3, --enable-asm-redc, --enable-gpu, --enable-assert] [ECM]
Input number is 458903930815802071188998938170281707063809443792768383215233 (60 digits)
FATAL: Module nvidia not found.
GPU: Error: no active device.
GPU: Error msg: no CUDA-capable device is detected
Segmentation fault
############### ERROR ###############
Expected return code 14 but got 139

chris@4core ~/ecm-gpu/trunk $ sudo modprobe nvidia
FATAL: Module nvidia not found.
[/code]
It could be because I'm still using the built in graphics (which has a D-Sub port that fits my monitor) instead of the GPU (which only has DVI-D ports). I could buy a monitor with a DVI-D connector, but would like to know if that will fix it before I spend money. Fivemack, are you using the GPU for graphics as well as computations? And does anyone have advice on setting up the GPU when it's not used for graphics output?

This has passed from "interesting" to "educational" and is approaching "frustrating".

Chris

Solved!
 

I've finally got it working. The last problem was that Linux had loaded the nouveau driver (an open source driver for Nvidia cards) so the nvidia driver could not be used to access them. "lspci -v" shows which kernel driver is in use for a card.

To make the system use the nvidia driver I had to blacklist the nouveau driver by adding it to /etc/modprobe.d/blacklist.conf (this step may not be needed) and then run "update-initramfs -u" (this almost certainly is needed on Ubuntu based systems). After a reboot lspci -v showed the card was using the nvidia driver. Then ./test.gpuecm ./ecm succeeded.

Running "make ecm-params; make" caused problems though. I backed out ecm-params.h and they went away.

Other points that might help someone else installing it on Linux:
Start with post 209. The password is also anonsvn.
If you need a newer version of GMP get it from [url]http://gmplib.org/[/url].
To compile with a newer version of GMP than the one installed on the system:
[code] ./configure --enable-gpu=sm_21 --with-cuda=/usr/local/cuda --with-gmp-lib=home/chris/gmp-5.1.3/.libs --with-gmp-include=home/chris/gmp-5.1.3 | tee -a configure.out
[/code] Where --with-gmp-include is the dir containing gmp.h and --with-gmp-lib is the dir containing libgmp.a.
Get CUDA etc from [url]https://developer.nvidia.com/cuda-downloads[/url] if you need it. Follow the getting started guide for Linux (especially to set PATH and LD_LIBRARY_PATH).

This was definitely an "educational" experience.

Chris

[QUOTE=chris2be8;364978]Running "make ecm-params; make" caused problems though. I backed out ecm-params.h and they went away.[/QUOTE]

Try this:

[CODE]make ecm-params
./bench_mulredc >> ecm-params.h
make[/CODE]

Thanks, that did it. Presumably the Makefile should be updated to do that when making ecm-params.

Chris

Would setting the GPU into persistence mode have any effect? The man page for nvidia=smi says:
[code] Persistence Mode
A flag that indicates whether persistence mode is enabled for the GPU. Value is either "Enabled" or "Disabled". When persis‐
tence mode is enabled the NVIDIA driver remains loaded even when no active clients, such as X11 or nvidia-smi, exist. This min‐
imizes the driver load latency associated with running dependent apps, such as CUDA programs. For all CUDA-capable products.
Linux only.
[/code]
Which sounds interesting.

Chris

PS. Would it affect msieve polynomial selection either?

Nothing significant. By default, Linux unloads the driver if nothing is using the card. When you then start a CUDA program, that program has to wait a short amount of time, probably about 0.5 seconds on one of my older machines, for the driver to load. This has a big effect only if you run a CUDA program many times and it has a short runtime. Otherwise, it doesn't really matter.

Hi,

I'm currently investigating new applications for yoyo@home. We want to update the server code of yoyo@home in the future and this would give us the possibility to run optimized applications and also GPU applications. I already set up a test project for this with the yoyo@home ecm application.

With my next step I would like to update ecm to a current version and also support a cuda enabled version. As I had trouble with my local cuda build system I would like to test with a working precompiled binary. Could someone provide me with one? Especially a windows one would be nice as I don't have a windows build system.

[QUOTE=ChristianB;375185]Hi,

I'm currently investigating new applications for yoyo@home. We want to update the server code of yoyo@home in the future and this would give us the possibility to run optimized applications and also GPU applications. I already set up a test project for this with the yoyo@home ecm application.

With my next step I would like to update ecm to a current version and also support a cuda enabled version. As I had trouble with my local cuda build system I would like to test with a working precompiled binary. Could someone provide me with one? Especially a windows one would be nice as I don't have a windows build system.[/QUOTE]
It is still an experimental version and only runs stage 1. Stage 2 needs to be done on a CPU. Also a 200W GPU has about the same performance as an 160W CPU. I would not recommend it at this time.

If somebody can help me figure out why I get the following errors, I can provide one:

[CODE]Error 202 error LNK2001: unresolved external symbol __gmpn_mul_fft

Error 204 error LNK2001: unresolved external symbol __gmpn_fft_best_k[/CODE]

libecm_gpu.lib builds without any issue.

[QUOTE=VictordeHolland;375191]It is still an experimental version and only runs stage 1. Stage 2 needs to be done on a CPU. Also a 200W GPU has about the same performance as an 160W CPU. I would not recommend it at this time.[/QUOTE]
That doesn't sound right to me, but I might be mistaken.

I was under the impression that ECM on GPU was quite a bit more efficient than that.

ChristianB, if you'd like to try things out, here's a 64-bit version compiled with CC 2.0 and MPIR 2.7.0. If you want different compilation parameters, let me know and I'll try to help out.

Included in the zip is a test file that I was given a while ago--to make sure everything works run:

[CODE]./test.gpuecm ecm_gpu.exe[/CODE]

It should pass the 3 or so tests in the file (did on my computer under MinGW-64).

Thanks wombatman,
I just read that ecm-cuda needs a compute capability of at least 2.0 for which I have to switch my GPU again. If I get ecm to build a binary on my Debian I will switch the cards and try it locally. I also have to adjust our BOINC-wrapper in order to deal with the extra options.
Thanks to the explanations by Chris I' m currently setting up the nvidia build environment, which looks promising.

Just an off topic thought.

Perhaps it would be easier to BOINCify a simple GPU project such as one of the mfaktX apps. The learning experience acquired could be used for bigger and more complex projects. :smile:

Doing a real BOINCification is hard you're right. But using the wrapper is easier. The problem is that the stock BOINC wrapper needs some modifications for ecm (like accepting non-zero success exit codes) and also needs some modifications to support legacy GPU apps. Checkpointing with ecm is also difficult from a BOINC point of view.

I investigated a little further into the ecm source code and found out that even for the gpu-ecm with wrapper solution I need to modify the ecm code (ecm has to terminate by itself after stage 1).

I also took a look into mfaktc code and it seems that this could be easily BOINCified but I have to build a whole new pipeline on the server to support this new subproject but we already have the ecm pipeline that just needs to be modified. Also ecm is used for a variety of subprojects mfaktc only for one. So I will think more about ecm code changes than mfaktc for the moment.

I don't know who programmed it, but there's the ecmclient server programs that do individual curves (up to a few tens) for various numbers. Maybe something like that would work?

[QUOTE=wombatman;375193]If somebody can help me figure out why I get the following errors, I can provide one:

[CODE]Error 202 error LNK2001: unresolved external symbol __gmpn_mul_fft

Error 204 error LNK2001: unresolved external symbol __gmpn_fft_best_k[/CODE]

libecm_gpu.lib builds without any issue.[/QUOTE]

This is most likely caused because you are building GMP-ECM out of its repository but you are trying to link to an older version of MPIR.

To build GMP-ECM from its repository you need to link with the repository version of MPIR because I keep the two repositories in sync.

The incompatibility arises because the _internal_ FFT interface in MPIR (which GMP-ECM actually uses) has changed with Bill Hart's faster FFT implementation.

I think you are correct. I updated the MPIR library (mpir.lib) and the accompanying files (.pdb) and it compiled without issue.

Quick question about the iteration counter:

When I run with B1=43M, the 1st iteration printout that shows up is [CODE]60000000 iterations to go[/CODE]

Is the count just off?

I've been continuing to play with expanding the GMP-ECM GPU to higher than 1018 bits. Can someone help out by pointing me to a number larger than, say, 350 digits that has a small factor that would be found in stage 1 of ECM?

[QUOTE=wombatman;375664]I've been continuing to play with expanding the GMP-ECM GPU to higher than 1018 bits. Can someone help out by pointing me to a number larger than, say, 350 digits that has a small factor that would be found in stage 1 of ECM?[/QUOTE]
(2^1327+1)/3

Ok. I'm not sure what to make of this. Using the test.gpuecm file, the compiled GMP-ECM passes both of the stage 1 factor checks but fails the "stage 2 on CPU" check. However, it passes the check from earlier in this thread on resume, so the stage 2 part would seem to work fine.

In addition, if I save the stage 1 curves for (2^1327-1)/3 and then do "-resume", it finds the small factor fine but it won't find it in Stage 1, even with the sigma given.

In short, I'm going to go ahead and provide what I'm compiled for everyone to test out and see if it's really working like it seems to be. The test.gpuecm file and xaa.txt file are also included. This exe is 64-bit, compiled with MPIR 2.7.0 with VS 2012. It takes numbers greater than (2^1018-1) without issue.

To check the xaa.txt file, run:
[CODE]ecm_gpu.exe -v -one -resume xaa.txt 3e6 5706890290[/CODE]

It should find the factor on the 2nd curve.

As another test, I used:
[CODE]2164055665608607740612407885850964992308600790456484211778583267500488594259697867055939683405523563952275457830655867366860891 = 1079990819 x 2434978091641012135177 x P96 [/CODE]

With the following command:
[CODE]$ echo "2164055665608607740612407885850964992308600790456484211778583267500488594259697867055939683405523563952275457830655867366860891" | ecm_gpu.exe -v -gpu -gpucurves 214 -one -savea test.txt 50000 0[/CODE]

And get:
[CODE]Computing 224 Step 1 took 624ms of CPU time / 9409ms of GPU time
Throughput: 23.807 curves by second (on average 42.00ms by Step 1)
********** Factor found in step 1: 1079990819
Found probable prime factor of 10 digits: 1079990819
Composite cofactor 2003772279853619515456647493825560930355094796835012920400190242265835960092266179770126067530508853290794000565162089 has 118 digits
********** Factor found in step 1: 2434978091641012135177
Found probable prime factor of 22 digits: 2434978091641012135177
Probable prime cofactor 822911831006746846988611407569612756481494741933492587627928501694906928664977226688442425641057 has 96 digits[/CODE]

So I'm feeling pretty good that it works! If anybody encounters any errors, please let me know!

To push towards an upper limit, I used 2^4000-1 (which is fully factored). And I'm pleased to report that it worked perfectly!

Using B1=50000, I found a mess of the small factors in both stage 1 and 2.

[QUOTE=wombatman;375673]So I'm feeling pretty good that it works! If anybody encounters any errors, please let me know![/QUOTE]

Hello wombatman, I am very interested in the gmp-ecm with CUDA Windows binary that you have provided. However, since I am using Windows XP x64, your binary does not work on my system. I have been informed that programs compiled with Visual Studio 2012 and 2013 will normally only be compatible with Windows 7/8. I hear that if you use a "different compiler" or maybe "different compiling options" you could create a Windows XP compatible binary. Would you be willing to try to create an XP specific binary? If so, do you need any additional information to do this? If not, then... I look forward to the day I have a Windows 7 computer! :smile:

I would certainly be happy to try! If you know what settings I need to use, please feel free to tell me. In the meantime, I'll look around and see if I can figure out something! :smile:

Edit: Quick google search found this: [url]http://stackoverflow.com/questions/13130713/how-to-compile-for-win-xp-with-visual-studio-2012[/url]. I'll try it out and if it works, I'll post a binary here.

Edit #2: Looks like it did ok. This was compiled with v110_xp as the target, which is supposed to be good for Windows XP. The zip file includes the test.gpuecm file and the xaa.txt file so you can test both of them for Stage 1 and Stage 2, respectively. The max value for this compilation should be 2^8186-1 (actually 2^8192-1, but 6 bits are reserved for space or something).

I assume the XP version is working alright?

[QUOTE=wombatman;376082]I assume the XP version is working alright?[/QUOTE]

Unfortunately, no. When I tried to run $./test.gpuecm ecm_gpu_winxp.exe the program starts to run, but then I get a windows pop-up error message. This is on the first test in that file in an msys shell. The strange thing is that when I run the first, and second, test manually in msys or in a command prompt it completes successfully. When I manually run the 3rd or 4th test, both in msys or cmd, the program starts but then I get a windows pop-up error message.

I notice in the -printconfig that your version is compiled with MPIR 2.7.0 and with OpenMP. I'm sure MPIR 2.7.0, while not finalized yet, should be good for VS builds. However, I'm wondering if OpenMP might be causing problems on my system. Can you create a version with OpenMP turned off?

If you only get the error running the script, it seems like it might be the script itself. What is the pop-up error? And are you using MinGW? I assume so since you mention MSYS, but I just wanted to be sure.

Attached is the WinXP version, compiled with MPIR 2.7.0 and CC 2.0 with OpenMP disabled.

[QUOTE=wombatman;376111]If you only get the error running the script, it seems like it might be the script itself. What is the pop-up error? And are you using MinGW? I assume so since you mention MSYS, but I just wanted to be sure.

Attached is the WinXP version, compiled with MPIR 2.7.0 and CC 2.0 with OpenMP disabled.[/QUOTE]

It's not just with the script. It happens when I run the program manually, too. For me, MinGW is just a compiler. It's not used to run this ecm program or the test script. The only way I can run the test script is in an MSYS shell. Running the script (in MSYS), I get a crash on the first test. However, when I run all of the tests manually in an MSYS shell: test1 and test2 work fine, test3 and test4 will each start, but then produce a pop-up error message and crash. I run into the same thing when running these commands manually in a command prompt (cmd). When I run test1 and test2 in a cmd prompt, they both work fine. When I run test3 and test4 in a cmd prompt, they both crash, the same way they do in MSYS.

Here is test 4 from the test script:
#test for when stage 2 on CPU is needed
#echo "2^349-1" | $ECM -sigma 3:13 587 1261

Here is the result when I run it from MSYS or a cmd prompt:

[CODE]
$ echo "2^349-1" | ecm_gpu_winxp -sigma 3:13 587 1261
GMP-ECM 7.0-dev [configured with MPIR 2.7.0, --enable-gpu] [ECM]
Input number is 2^349-1 (106 digits)
Using B1=587, B2=1261, polynomial x^1, sigma=3:13
Step 1 took 0ms
<crash>
[/CODE]

I've included a screenshot of the error, it's not very informative. Here are the error messages that show up in the windows event log:
[CODE]
A couple of these:
Faulting application ecm_gpu_winxp.exe, version 0.0.0.0, faulting module nvcuda.dll, version 6.14.13.3165, fault address 0x0000000000094446.

A bunch of these:
Faulting application ecm_gpu_winxp.exe, version 0.0.0.0, faulting module ecm_gpu_winxp.exe, version 0.0.0.0, fault address 0x000000000001de4a.
[/CODE]

At this point, I can only think of a couple of possibilities:
1) Something on my computer is preventing me from successfully running test3 and test4.
2) Something in the code base or in Visual Studio isn't creating a binary that will run successfully on WinXP.

Do these binaries work for you? If so, then I'm at a loss. If not, then it could either be that WinXP binaries won't run on Win7, or that you have run into the same problem I'm seeing. In any event, if you don't want to do any more testing, we can just call WinXP a non-supported OS and move on. I was hoping to have a cuda enabled gmp-ecm, but I guess I can probably live without it. :wink: Thanks again for trying to create these for me.

I just ran the test.gpuecm file on my computer (windows 7), and the winxp exe file I posted passes tests 1 through 3 without issue. It doesn't work on test 4 within the script, and I'm not sure why (hence why it was commented out). Test 4 does work, if memory serves, when run manually.

What graphics card and CUDA version are you using? This was compiled for Compute Capability 2.0 (I have a GTX 570) with CUDA 6.0.

What do you get when you click the "To see what data this error report contains, click here" link?

Chris

[QUOTE=wombatman;376114]I just ran the test.gpuecm file on my computer (windows 7), and the winxp exe file I posted passes tests 1 through 3 without issue. It doesn't work on test 4 within the script, and I'm not sure why (hence why it was commented out). Test 4 does work, if memory serves, when run manually.

What graphics card and CUDA version are you using? This was compiled for Compute Capability 2.0 (I have a GTX 570) with CUDA 6.0.[/QUOTE]

I have a PNY GeForce GTX 650 with 1GB of GDDR5. I am running nVidia driver 331.65 for my Windows XP x64 system. I downloaded the CUDA 6.0.37 installer for Windows XP, but did not install it. I extracted the necessary cudart64_60.dll from the installer and put it in the same directory as your executable. This is what I believe allows test1 and test2 to successfully complete. As a quick test, I renamed that file and test1 now complains that cudart64_60.dll is missing. One other thing to mention, I am able to run the CUDA version of msieve in this setup without problem.

[QUOTE=chris2be8;376147]What do you get when you click the "To see what data this error report contains, click here" link?

Chris[/QUOTE]

I get another pop-up window that gives one of the above error messages, like:
[CODE]Faulting application ecm_gpu_winxp.exe, version 0.0.0.0, faulting module ecm_gpu_winxp.exe, version 0.0.0.0, fault address 0x000000000001de4a.[/CODE]
Then it says, "To view technical information about the error report, 'click here'." When you click on that it brings up another window that lists all of the loaded dll's related to the program (apparently 22 of them), and a stack dump of the running thread and the whole program. That pop-up also says, "The following files will be included in this error report". It lists one file, which I am attaching below. Unfortunately, these error messages don't seem to point to a definitive problem. :no:

I'm at a loss. Is it possible that the RAM on your card is insufficient? Mine has 1.2GB (1280 MB).

I have attached a file with the binary compiled with CUDA 5.5 (labelled as such).

Have you ever run the ECM-GPU with the standard 2^1018-1 limit before? I'm just trying to figure out if it might be an issue with the size of the arrays or something.

The only other thing I can think of is to try update the driver as well.

Any updates with the newest CUDA 5.5 one? I'd definitely like to get this sorted out.

[QUOTE=wombatman;376334]Any updates with the newest CUDA 5.5 one? I'd definitely like to get this sorted out.[/QUOTE]

It seems like both the CUDA 5.5 and CUDA 6.0 are behaving the same. I might even guess the crash is happening after the CUDA code, somewhere in stage 2 in the cpu code. I have updated my nVidia driver to 337.88 and am still getting the same results, test1 and test2 pass, and test3 and test4 crash. However, one piece of good news is that when I now run the test script with "./test.gpuecm ecm.exe" it no longer crashes right away, it gets through the first two tests and crashes on the third. Progress!

I've done a little testing and narrowed down where the code crashes for me. test4 looks like:
echo "2^349-1" | ecm_gpu_winxp -sigma 3:13 587 1261

Where that last 1261 is the B2 bound for ecm. This test crashes for me. I can decrease that all the way down to 709 and the program will still crash. But, when I set it to 708, the program will then run to completion without any errors.
echo "2^349-1" | ecm_gpu_winxp -sigma 3:13 587 708 (passes)
echo "2^349-1" | ecm_gpu_winxp -sigma 3:13 587 709 (crashes)

With the -v (verbose) command line option, I can track down the crash to somewhere in the stage2.c file. If you would still like to help me track down this problem, I have created a modified version of this file that prints out some extra info to help narrow down where the crash is occurring. If you could compile a new test version with this new stage2.c file and post* it, I can test it out to try to better narrow down where this crash is happening.

*Actually, if you do still want to help, let me know and I can PM you details to log in to my ftp server so you can put the test version there. This way we won't clutter up the forum with extra files. Actually, speaking of clutter, perhaps we should ask a mod to move these troubleshooting posts to their own thread so regular users of gmp-ecm w/cuda don't have to see all this?

Again, let me know if you'd like to continue to troubleshoot for this old OS, or if we should just say this is a Win7+ only program.

I'll PM you.

Another question for those smarter than me. For the GPU Stage 1, the actual B1 (appears to) start well above the set value. For example, I set B1=110e6, but by putting in a print statement that uses the same starting counter for the PRINT_REMAINING_ITER variable, I find that the counter starts at B1=158,705,535. This amounts to about 33% more iterations than expected, which for a large number, makes a pretty significant difference in terms of time.

Can anybody help me confirm whether the GPU-based Stage 1 is actually running this many iterations?

I believe that ecm-7.0 starts by multiplying together all the primes and then does a single elliptic-curve multiply-by-bignum operation; the 158-million-ish figure that you mention is very close to the number of bits in the product of the primes less than 110 million (by the Prime Number Theorem, this product is essentially exp(110 million))

Indeed. With the exception that the primes are taken at their largest power less than B1. Same as cudaPM1 program, if you check it, when you select B1=600000, it will do 2^19*3^12*5^8*.... which has [B]865771[/B] bits. This is the "lcm" of all numbers (including non-primes) less than B1, which is [URL="http://www.mersennewiki.org/index.php/P-1_Factorization_Method"]referred here[/URL] as "E" (see step 1), and that is the number of "iterations" that have to be done (each iteration is "square, if the bit is 1, multiply by 2", to compute b^E, "normal" modular exponentiation). You can see P-1 as a "single ECM curve" with some special properties.

edit2:

[code]
gp > b1=110000000; m=0.0; cnt=0; forprime(p=2,b1,i=1; while(p^i<b1,m+=log(p); i++); if(cnt++%10000==0, cnt=0; printf("...%d...%c",p,13))); ceil(m/log(2))
...109938667...
%2 = 158705536
gp >
[/code]

Awesome! Thanks for the answers. I still have a ton to learn about ECM.

I'm starting to play with the GPU-ecm program.

In post #253, there is a zip file which I downloaded.

If I use the exe in normal gmp-ecm format on (2^541-1) which has been factored, I do get some of the factors (used small B1).

If I use the exe in GPU-ecm format, I do not get any factors, even if I use the same B1 as in normal mode, with 10000+ curves. I even used the same sigma as for the normal mode.

Am I missing something? :question:

Or is this not the correct exe to use?

[QUOTE=houding;378127]I'm starting to play with the GPU-ecm program.

In post #253, there is a zip file which I downloaded.

If I use the exe in normal gmp-ecm format on (2^541-1) which has been factored, I do get some of the factors (used small B1).

If I use the exe in GPU-ecm format, I do not get any factors, even if I use the same B1 as in normal mode, with 10000+ curves. I even used the same sigma as for the normal mode.

Am I missing something? :question:

Or is this not the correct exe to use?[/QUOTE]

What specific invocation did you use? What flags? What GPU?
Post 253 has an experimental version for ECM on large (up to 4090-bit) numbers. The regular version is good only up to 1018 bits.

Yeah, if you can post the full command line you used, we can try and diagnose it. I'm out of town, but returning tomorrow, and I can try to factor the same number, since I've had no issues with the exe.

Edit: Also, if you run the test.gpuecm, does it pass without issue? It does on my laptop.

Edit part 2: I ran the following command: [CODE]echo "2^541-1" | ecm_gpu_4096.exe -v -gpu -savea test_file.txt 500000 0[/CODE] and get the following results from part 1: [CODE]********** Factor found in step 1: 6115209994009
Found probable prime factor of 13 digits: 6115209994009
Composite cofactor (2^541-1)/6115209994009 has 151 digits
********** Factor found in step 1: 4312790327
Found probable prime factor of 10 digits: 4312790327
Composite cofactor ((2^541-1)/6115209994009)/4312790327 has 141 digits[/CODE]

Edit part 3: Using [CODE]ecm_gpu_4096.exe -one -resume test_file.txt 1000000
(I did a run of 910 curves with B1=1e6)[/CODE] I get [CODE]********** Factor found in step 2: 77146448294831869472151022106713
Found probable prime factor of 32 digits: 77146448294831869472151022106713
SIGMA=817374218[/CODE]

:party:Three cheers for me - IDIOT OF THE DAY! First round of virtual beers on me. Will buy it with my GIMPS credits :grin:

I should have read my post before hitting the submit button. This GPU is in my home computer, and I couldn't remember what posts' exe I used when I posted from work.

I'm trying to run it on a GTS 450, cc 2.1. 64 bit Win 7 ultimate.

I did try the exe as in post 253, but it kept crashing. I used in a batch file:
ecm_gpu_4096 -v -gpu -gpucurves 200 10000 0 < input.txt

So instead I used the exe as in post 220. Same batch file format. The batch file runs to the end, but no factors found.

VBCurtis mentioned regular version. Where can I get it, or is it similar to post 220?

Adolf

Adolf-
At the top of post 275, note the first line of code uses "-savea" to save the end-of-stage1 checkpoints. The idea is that GPU-ECM runs stage 1 only, while old-fashioned ECM with -resume flag and the save file as input will run stage 2.

It may be that you are simply not finding any factors in stage 1 with B1=10000, and since you aren't saving the checkpoints, stage 2 is not being run.

Also, -gpucurves is used to override the setting ECM chooses for number of concurrent curves per run; I don't think you want to use this without a specific reason. Just use -c to control how many curves you want done; the program will adjust it to a multiple of the number of curves your GPU can handle at a time.

If you want to control the load on a GTS450 you should probably pick a multiple of 48 for the -gpucurves. The maximum for that card would be [B]192[/B], unless it's OEM in which case it's 144.

Don't know if anyone else is interested in this, but I've been playing around and see how high I can push the GPU-ECM. I'm currently at a 65530-bit version. It works fine using 2^64000-1 as a test number. Finds factors in stage 1 and 2.

[QUOTE=wombatman;379167]Don't know if anyone else is interested in this, but I've been playing around and see how high I can push the GPU-ECM. I'm currently at a 65530-bit version. It works fine using 2^64000-1 as a test number. Finds factors in stage 1 and 2.[/QUOTE]
I would be at least mildly surprised[sup]*[/sup] if you can't push it [b]much[/b] further. Whether it is worth doing is an entirely different matter.

Paul
* And would submit a bug report to Cyril

It is a highly composite number (think of the algebraic factorizations), so results on it would be dubious.

Try (2^63997-1)/383983/626890933111 for better results. Can you find additional factors?

To be clear, the number (2^64000-1) was arbitrary and only used to make sure that it could find any factors at all. I'm also checking with a known 40-digit factor that should be found in Stage 2 (and is). I'll try out the number you suggested and see if anything turns up.

Edit: Also, why does it being a highly composite number make the results dubious? Still teaching myself the basics of ECM, so I don't know enough to know what I don't know.

The ECM code can recognize special input forms. For example, it is known that ecm switches to a special branch for factoring the 2^4096+1 c1133 cofactor, [U][I]even if[/I][/U] you give the decimal representation on input. Try it (and use -v switch, to see what is going on in detail).

If it can do that, it can (I don't know if it does in this version, but it might in the future version) recognize algebraic factorizations and run itself on cofactors which are at least twice smaller. So, you will be getting timings that you'd expect to be [I]typical [/I]for the bit size of the input number but instead you will get timings for a much smaller number.

If you take a 2^prime-1 as an input, you will not depend on the implementation details.

[QUOTE=Batalov;379181].[/QUOTE]
:goodposting:

Follow-up question: If it can find the two known factors (apart from any larger ones it may find) of 2^63997-1, would you have confidence in it working properly?

Using non-base 2 numbers (like [URL="http://factordb.com/index.php?id=1100000000535556578"]this one[/URL]) suggests that there's something strange going on. My results are very hit-or-miss.

To clarify a bit more: if I put in (5^480*12-1) and use B1=100000 with 480 curves (the default number of curves), I find the factor 11 in stage 1 and factors 97369 and 94165528343 in Stage 2. My concern is that I don't seem to find relatively small factors sometimes, even when I run enough curves to have the equivalent of multiple tXX. If anybody finds a large factor (25-35 digits?) with a known sigma from a composite larger than 2^1018-1, please let me know.

With 3^1009-1, I find the factor 2 in Stage 1.
I find 10091, 54534433, and 15283224119, but not 684071451517 with B1=100000 in Stage 2.

[QUOTE=wombatman;379212]Follow-up question: If it can find the two known factors (apart from any larger ones it may find) of 2^63997-1, would you have confidence in it working properly?[/QUOTE]
As a baseline, I already have confidence that the code is working properly, because it is a well-respected team of researchers with a modern bug- and task-tracking pipeline. If the build quality needs checking, try the test cases included with the software ([I]make; make check[/I]; and only then, [I]make install [/I]- almost everyone knows the conventional three commands. Yet many people skip the middle part ... for speed or whatever other reasons?).
[QUOTE=wombatman;379236]My results are very hit-or-miss.[/QUOTE]
ECM with random initial values (which is the default) is by definition random (or you can call it hit-or-miss). Running 890 curves at 1e6 and not finding a factor proves no bug (or the absence of a bug).

What you want to do is find a specific sigma that does produce a factor (in controlled environment, e.g. with old/CPU code in case that you are testing the GPU), then (unsure about this step because of the new GPU parallelism; check the documentation/source) transform the sigma into the new GPU-compatible sigma, and expect a factor from the code under testing.

Unclear about what you are trying to achieve.

To be clear, all of my concerns are with GPU-ECM only. CPU-based ECM is not causing me any issues. I did the make/make check/make install and everything completes perfectly.

Unfortunately, I can't do the make check portion with a Windows-based build of GPU-based ECM via Visual Studio, so I'm only able to use a file I was given that essentially runs some basic Stage 1 checks for a GPU-enabled build. This is what it checks:
[CODE]# Exit statues returned by GMP-ECM:
# 0 Normal program termination, no factor found
# 1 Error
# 2 Composite factor found, cofactor is composite
# 6 Probable prime factor found, cofactor is composite
# 8 Input number found
# 10 Composite factor found, cofactor is a probable prime
# 14 Probable prime factor found, cofactor is a probable prime


#test for stage 1 on GPU
echo 458903930815802071188998938170281707063809443792768383215233 | $ECM -sigma 3:227 125 0
checkcode $? 14

#test for stage 1 on GPU
echo "2^349-1" | $ECM -sigma 3:279 587 0
checkcode $? 6

#2^1018-1 is the maximum number that can be used
echo "2^1018-1" | $ECM -sigma 3:92 4 0
checkcode $? 2[/CODE]

I'll try and figure out how to convert the sigma from CPU-based to GPU-based.

My goal is to try and confirm that the GPU-ECM build is working properly with a higher bit-limit than 1018. To use a recent example, I am concerned when I don't find a 12-digit factor (684071451517, of 3^1009-1) while doing 480 curves on the GPU with B1=100,000, which is greater than a t25. Maybe I have the wrong impression, but wouldn't I reasonably expect to catch that 12-digit factor?

Maybe they mean it when they said "2^1018-1 is the maximum number that can be used". For this particular implementation, that is. If you are just changing some #define and recompiling, then there's no guarantee that you are not breaking internal dependencies that are not easily explained - you have to have a working knowledge of all internals. I don't know ecm code all too well at all, so I will give you an example from the programs that I know in some more intimate detail:
1) NewPgen: you cannot just up some limits and get it to use more memory - it is written with 32-bit asm and to extend its capabilities, one needs to rewrite asm, and this is much hairier than one would want, so it is best tweaked within its limits;
2) the K-F siever: there is no magic way to go around the bulk of the code written with short ints -- and that makes adapting the "17e" siever from old code practically impossible; if you convert short ints into ints you won't have enough memory on most comps, and if you'd want to use 16-bits with 1-bit somehow cleverly packed away you then would want to discard almost everything and write from scratch. Etc.
3) mmff: one cannot just add 32 in some places and the code starts working with larger numbers; you have to implement quite a bit - which is easier that writing from scratch, but still tedious (copy the template code, then make everything wider and then scratch your head and write quite a bit extra for a couple evenings; and then debug until it works).

When Paul playfully says that the code very likely can be pushed much further [TEX]\ne[/TEX] "we double a few #define'd limits and everything just works". More likely, quite a bit has to be re-implemented if some values just jump out of their Procrustean beds ([I]even if[/I] occasionally, while most of the time fitting in them).

I certainly concede that it's far more complicated.

I guess I'm ultimately just confused with why it still seems to work, if only partially. For instance, running (((3^1009-1)/2)/8410464655934379916957) (the factors mentioned in my last post) and using B1=1e6, I find another factor--684071451517 at sigma 3:473815648--with the remaining composite of 448 digits being well past the apparent limit of 2^1018.

Regardless, thanks for taking the time to help out with my confusion. I do very much appreciate it.