Msieve 1.44 feedback
 

[QUOTE=jasonp;204613]Now available at sourceforge. This includes a merge of the GPU code into mainline, as well as GPU and non-GPU windows binaries.

Happy factoring,
jasonp[/QUOTE]Running msieve 1.44 on 4 cores of a 8-core RedHat Linux box went very smoothly. The only problem is that no factors were recorded anywhere I can see. Certainly not on the screen output and they don't appear to be in either of the log files (which are attached). :sad:

Anyone have any ideas?

Looks to me like the sqrt failed silently but that's a wild guess at best.

Paul

P.S. All the available files are preserved, just in case, but at 1.7Gbyte it's unlikely that anyone will want to take a detailed look at them.

[QUOTE=xilman;204825]Running msieve 1.44 on 4 cores of a 8-core RedHat Linux box went very smoothly. The only problem is that no factors were recorded anywhere I can see. Certainly not on the screen output and they don't appear to be in either of the log files (which are attached). :sad:

Anyone have any ideas?

Looks to me like the sqrt failed silently but that's a wild guess at best.

Paul

P.S. All the available files are preserved, just in case, but at 1.7Gbyte it's unlikely that anyone will want to take a detailed look at them.[/QUOTE]One idea: does anyone have code to convert msieve's .dat file into CWI-format relations?

If so, I could use the CWI toolkit to complete the factorization. Seems a shame to let the sieving go to waste.


Paul

[QUOTE=xilman;204825]Looks to me like the sqrt failed silently but that's a wild guess at best.[/QUOTE]Yup, that was it. Running a sqrt interactively produced:[code]



[pcl@maat example]$ "..//msieve" -s c12_157.dat -l ggnfs.log -i c12_157.ini -nf c12_157.fb -t 4 -nc3


Msieve v. 1.44
Mon Feb 8 02:14:19 2010
random seeds: cbd55578 7eb82c39
factoring 8028909702551763295176249947317408338149202590221234911329182732937136650241291109745914860307106279676737633899892269769090620267138886704570188077187628121 (157 digits)
no P-1/P+1/ECM available, skipping
commencing number field sieve (157-digit input)
R0: -34182189187166852111368841966125056
R1: 1
A0: 1728
A1: 0
A2: 0
A3: 0
A4: 0
A5: 157
skew 1.00, size 2.605451e-12, alpha -0.575580, combined = 1.446413e-10

commencing square root phase
reading relations for dependency 1
read 539594 cycles
cycles contain 1808664 unique relations
read 1808664 relations
multiplying 1808664 relations
multiply complete, coefficients have about 53.48 million bits
initial square root is modulo 47617231
Segmentation fault
[pcl@maat example]$
[/code]Ho hum. A debugging we will go.

I would try
[FONT=Arial Narrow]../msieve -s c12_157.dat -l ggnfs.log -i c12_157.ini -nf c12_157.fb -t 4 -nc3 2,12[/FONT]
if it fails
[FONT=Arial Narrow]../msieve -s c12_157.dat -l ggnfs.log -i c12_157.ini -nf c12_157.fb -t 4 -nc3 3,13[/FONT]
[FONT=Arial Narrow]etc...
[/FONT][FONT=Verdana]Maybe it was an isolated incident. If so, later we could debug that first dependency.[/FONT]

Bsquared had a similar segfault in the square root, and sent me a GDB trace ages ago. Will look into it soon.

[quote=xilman;204826]One idea: does anyone have code to convert msieve's .dat file into CWI-format relations?

If so, I could use the CWI toolkit to complete the factorization. Seems a shame to let the sieving go to waste.


Paul[/quote]
I'm sure there's such a utility out there, though I don't think there's any distributed publicly. Probably somebody on the forum could get one for you. However, since this incident seems to be unique to msieve 1.44, you might try swapping it out for a 1.43 or earlier binary and rerunning -nc3. I imagine that would finish up the job quite nicely.

Could u make an easy way to distribute poly finding? i might be easy already, but if you could tell it what percentage of the poly finding you wanted to do or something then we could have different people doing gpu searches at once without any duplication. or can u just do np and there is already little chance of dupes like ecm? or is that what the option to set coefficients is? problem with that option is I have no clue on coefficients what to pick. Thanks man!
ps I got ride of those weird cuda errors by doing windows updates or something.

[QUOTE=Joshua2;204855]Could u make an easy way to distribute poly finding? i might be easy already, but if you could tell it what percentage of the poly finding you wanted to do or something then we could have different people doing gpu searches at once without any duplication. or can u just do np and there is already little chance of dupes like ecm? or is that what the option to set coefficients is? problem with that option is I have no clue on coefficients what to pick. Thanks man![/QUOTE]
For large inputs, specifying different ranges for the np parameter is probably OK for now. For small inputs (like the c125 you are doing in the aliquot thread), the selection will need so little time that it is probably not worth separating it on multiple machines, but you can still use np to do it.

There's been a few ideas thrown around for doing something different, but nothing conclusive yet.

thx! does it damage the search to run einstein@home cuda at the same time? Everything seems to be ok doing it, but I can't tell how much they slow each other down. things still seem to spitting out pretty fast, and Einstein uses mostly cpu. i guess i should be fine? i've run folding@home with einstein and had no problems

i found some people saying u can test gpu load with gpu-z, but its showing up as 0%. I have an OC GTX 275, maybe its just really powerful for the task?

Any program that uses the GPU gets the entire GPU when it runs, so if two programs want to run then each will take half the time available on the GPU.

The next generation of GPUs from Nvidia will allow multiple sets of kernels to be executing on the card at the same time, if multiple kernels will all fit on the card at once. Of course msieve will take up the whole thing by default :)