CUDAP-1 r.45
 

I updated my svn repository and started the program without switches (only the exponent to test). Same GTX 580.

Before the update, I had the following results:

[code]
M65171233 found no factor (P-1, B1=610000, B2=15860000, e=6, n=3584K CUDAPm1 v0.10)
M62651599 found no factor (P-1, B1=585000, B2=15063750, e=6, n=3456K CUDAPm1 v0.10)
M62650493 found no factor (P-1, B1=585000, B2=15063750, e=6, n=3456K CUDAPm1 v0.10)
[/code]

Now, I am working with the following parameters:

[code]
M61603063 fft length = 3888K
Using b1 = 555000, b2 = 12348750, d = 2310, e = 2, nrp = 35
[/code]

I have a smaller exponent using a bigger FFT and e=2 instead of e=6 (useful for Brent-Suyama extensions, I think).

Is this a normal behavior? :surprised: :help:

Luigi

[QUOTE=ET_;350715]I updated my svn repository and started the program without switches (only the exponent to test). Same GTX 580.

Before the update, I had the following results:

[code]
M65171233 found no factor (P-1, B1=610000, B2=15860000, e=6, n=3584K CUDAPm1 v0.10)
M62651599 found no factor (P-1, B1=585000, B2=15063750, e=6, n=3456K CUDAPm1 v0.10)
M62650493 found no factor (P-1, B1=585000, B2=15063750, e=6, n=3456K CUDAPm1 v0.10)
[/code]Now, I am working with the following parameters:

[code]
M61603063 fft length = 3888K
Using b1 = 555000, b2 = 12348750, d = 2310, e = 2, nrp = 35
[/code]I have a smaller exponent using a bigger FFT and e=2 instead of e=6 (useful for Brent-Suyama extensions, I think).

Is this a normal behavior? :surprised: :help:

Luigi[/QUOTE]

Yes and no. The function where the fft lengths are assigned has two sections, one for timings taken from a 570, and one for timings taken from a titan. The 570 timings would be more appropriate in your case. Look at the function choose_fft_length on line 1332.

As for the smaller e, older versions automatically selected e = 6. This latest version acually makes an attempt at chosing an optimal value for e, which is apparently e = 2 in your case.

[QUOTE=owftheevil;350718]Yes and no. The function where the fft lengths are assigned has two sections, one for timings taken from a 570, and one for timings taken from a titan. The 570 timings would be more appropriate in your case. Look at the function choose_fft_length on line 1332.

As for the smaller e, older versions automatically selected e = 6. This latest version acually makes an attempt at chosing an optimal value for e, which is apparently e = 2 in your case.[/QUOTE]

I assume you meant line 1371 (my soirce code has the function located there), or maybe my code is (still) outdated?

Provided that my card is choosing Titan's timings, should I modify them or keep with the chosen parameters? Or wait for some new GTX 580 timings?

Luigi

A new version with some memory optimizations is up at sourceforge. There is also a new ini file option to control the amount of memory the program will not try to use. A line such as

[CODE]UnusedMem 100[/CODE]

in the ini file will leave at least 100 MB of vram free. More will probably be left free due to inaccurate reporting of free memory by CUDA and optimizations of the number of relative primes processed in a pass.

Here's a windows build with CUDA 5.0.

I just completed a test run on 50001781. The factor was found: 4392938042637898431087689

There were two instances of "Couldn't write checkpoint," once in stage one, and once in stage two.

I don't know if this has any significance.

Just tested with the Sep3 version above.

Improvements measured:

6144k FFT candidate 6.8ms -> 5.5ms
4000k FFT candidate 3.8ms -> 3.2ms

I also updated to latest drivers.

Full speed ram now works (so far).

-- Craig

[QUOTE=owftheevil;351683]A new version with some memory optimizations is up at sourceforge. There is also a new ini file option to control the amount of memory the program will not try to use. A line such as

[CODE]UnusedMem 100[/CODE]in the ini file will leave at least 100 MB of vram free. More will probably be left free due to inaccurate reporting of free memory by CUDA and optimizations of the number of relative primes processed in a pass.

Here's a windows build with CUDA 5.0.[/QUOTE]

Is this build considered production-ready? I have run it without incident on some of the test cases in the readme.

Has PrimeNet been updated to handle CUDAPm1 results files?

Yes, the manual results form has supported it for a while now.

[QUOTE]Is this build considered production-ready? I have run it without incident on some of the test cases in the readme. [/QUOTE]

As far as I can tell, the current version doesn't have any bugs that would keep it from finding factors.

[QUOTE=owftheevil;352414]As far as I can tell, the current version doesn't have any bugs that would keep it from finding factors.[/QUOTE]

Cool! Thanks for everybody's work on this!

One more question: is "SaveAllCheckpoints" still disabled? I did a trial run of a live assignment, hoping to compare checkpoints with P95 on the same exponent, but no checkpoints were saved.