Msieve 1.50 feedback

[firejuggler]

Post any feedback, you know the drill

searching leading coefficients from 1 to 7443508
using GPU 0 (GeForce GTX 560)
error (line 186): CUDA_ERROR_FILE_NOT_FOUND
Msieve Error: return value -1. Is CUDA enabled? Terminating...
WARNING: gnfs failed to find a factor. This really shouldn't happen.

any idea?

[jasonp]

The zip file has two .ptx files; the precompiled binary should read in stage1_core.ptx from the same directory, but for your card you should probably rename stage1_core_fermi.ptx so that it gets read instead. Does that change anything?

I should really make the build system compile both files and choose the correct one at runtime.

[firejuggler]

My bad, I forgot to copy the ptx. It's working now.

[RichD]

I'm tracking down another problem (which may be posted in a different thread later) and came across this anomaly. I run poly select on an older PowerPC 32-bit system. Not good for anything except low level ECM and poly finding.
And also checking the MAKE process for msieve on said system. :-)

This was generated for the remaining composite from 11^211-7^211 using v1.50.

N 261975750276710823664375795494855610183438525059108945746163526602755873209839065561606521308453837409681403408384774129737507021172215241
SKEW 435308.50
R0 -272557679420217265085741558
R1 1077294171599227
A0 -440522390137732549472016061469025
A1 10983825791577845860011027220
A2 -29479481793724932253703
A3 -342245302039949762
A4 62223473682
A5 174168

I reverted back to v1.49 using ./msieve -np 174000,174300 and I get this.

N 261975750276710823664375795494855610183438525059108945746163526602755873209839065561606521308453837409681403408384774129737507021172215241
SKEW 379123.26
R0 -272541785044793789287822496
R1  2283795032998967
A0  593593115511257917997312038890015
A1 -32945875798453634311839156
A2 -38386335943043264175359
A3 -75905349610538410
A4  362604942214
A5  174216

It appears a change was made between the two versions and was it for the better?

[jrk]

Originally Posted by RichD

It appears a change was made between the two versions and was it for the better?

Nothing is wrong.

Two things changed between 1.49 and 1.50 that would result in different polynomials being generated.

- the degree 5 root sieve had a fix that allows it to produce polynomials with better root properties relative to 1.49.
- the way some internal parameters are chosen for the collision search were modified.

These two things mean you will likely get different (and hopefully better) polynomials with 1.50.

Btw, your first polynomial (from 1.50) scores slightly higher with a murphy score of 2.813e-11 while the second one scores 2.660e-11. I would sieve with the first one. For a job this small, it is probably not worth doing any trial-sieving to find which one will perform better in practice since it will not take very long to sieve anyway.

[RichD]

Ah, the infamous Murphy score. I thought there was an inverse correlation between "him" and the SKEW. Meaning, I thought the lower the skew the better.

I'm mostly done sieving and I'm trying not to post a noob question in GNFS.

Thanks for the heads up.

BTW, how is that Murphy score calculated?

[jrk]

Originally Posted by RichD

I thought the lower the skew the better.

The skew is optimized for each polynomial generated, and a larger or smaller skew doesn't imply that a polynomial will be better or worse. Aside from sieving, the most accurate way we have for ranking polynomials is to compare their Murphy scores.

Originally Posted by RichD

BTW, how is that Murphy score calculated?

The Murphy score is written to the msieve.log file during polynomial selection. I found the scores by running msieve -nc once with each of your polynomials in the msieve.fb file.

[jasonp]

Originally Posted by RichD

BTW, how is that Murphy score calculated?

On the off-chance you meant 'what is the algorithm for calculating the Murphy score': I'm afraid the answer isn't simple. In practice we do a numerical integration across the sieving region, where the integrand is a product involving Dickman's function. The Murphy score is the probability that an 'average' relation has only small factors, and this is what Dickman's function measures.

There is no direct relationship between larger skew and better Murphy score, but a larger skew often means a larger search space for a better alpha score, and a better alpha score means the input to Dickman's function is smaller, so the Murphy score would improve.

Thanks for testing the build on PowerPC BTW; I have both 32-bit and 64-bit PowerPC systems but it isn't worth even turning them on

[poily]

Hi! I'm trying to play with the CUDA polynomial selection on my MBP with modest GT 330M and I get

deadline: 20 CPU-seconds per coefficient
coeff 12 specialq 1 - 128933 other 8232 - 19756
aprogs: 475 entries, 1314 roots
batch size 18
error (line 425): CUDA_ERROR_LAUNCH_OUT_OF_RESOURCES

It seems it doesn't depend on the factored number.

So, what kind of resources that GT 330M lacks does msieve use for CUDA polynomial selection and is there any way to make it work on my MPB?

Btw, jasonp, why CUDA and not OpenCL? Or is it NVIDIA sponsored project?

[jrk]

Hi! I'm trying to play with the CUDA polynomial selection on my MBP with modest GT 330M and I get

Hi. Will you be willing to help me debug the problem (preferably via PM so we don't spoil this forum)? I would like to find out what is going wrong on your card. Thanks.

[jasonp]

Originally Posted by poily

Btw, jasonp, why CUDA and not OpenCL? Or is it NVIDIA sponsored project?

When the original version of the code was written, to a good approximation there was *no* OpenCL. Earlier versions of the code spent all of their time doing multiple-precision arithmetic, and it was straightforward to make CUDA perform the low-level operations for that. It's less clear how you get OpenCL to produce high-half multiply results (for example) without per-vendor tuning, which would defeat the purpose of switching to another language.

Modern versions of the polynomial selector spend most of their time sorting arrays of integers, so there's less need for multiple precision arithmetic. Maybe someday, and if jrk wanted to have a go at it then he's welcome to, but I don't have the time anymore.

(Regarding your specific problem, the polynomial selector needs very little memory and should be able to adapt to cards with few compute units, so it's puzzling to run out of resources)