Some results from a live GNFS180 polsel

[Batalov]

Thanks. Because sometimes...

[Andi47]

Originally Posted by frmky

The poly is
...

I just did a test run (Core 2 Duo @ 2.0 GHz, 64-bit-Linux):

# norm 9.833432e-18 alpha -9.052498 e 6.697e-14
n: 278490841076279407188741439481565179355926725853710201632331620642982062389901741890579963524423782637435949041666525000702723914662388812510545494307250950777886431051612811386531
skew: 536967657.44
c0: 486705885709926708065232033951307588813625602275
c1: 5584390886742987582391695130327092942465
c2: -2589293749660254385400621955533
c3: -205785074447711087191729
c4: -211349858750
c5: 101640
Y0: -77187904731145180346916804885190882
Y1: 27609235740881943367
rlim: 130000000
alim: 130000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6
# Parameters not optimized!

./gnfs-lasieve4I15e -a em43.poly -o em43_test1.out -f 60000000 -c 5000
Warning: lowering FB_bound to 59999999.
total yield: 4645, q=60005047 (1.06234 sec/rel)

[10metreh]

Originally Posted by Batalov

Thanks. Because sometimes...

I suppose the result of that is:

[frmky]

Originally Posted by Batalov

Could you please run (just for a day) our number?
It was posted here.

Here's the best from a 1 day (4 GPU-day) run:

# norm 6.382388e-18 alpha -6.977213 e 4.690e-14
skew: 96396127.95
c0: -21089523035205834558658893161383589790490875
c1:  25365708430996095210154238905975753526
c2: -72843247438343083950607872141
c3: -286810051133678582204076
c4:  1191598470970
c5:  75300
Y0: -104562293217428138402097394839773048
Y1:  30927533733738342637

# norm 6.052477e-18 alpha -7.456015 e 4.572e-14
skew: 71177217.42
c0: -176168744305195828043372966990512601113397184
c1: -48474401617643499835075365201872549504
c2:  63762059797096003748769347572
c3:  446546902426598975662414
c4: -125855215039143
c5:  60120
Y0: -109378093201325720088775462145703197
Y1:  28451743180686818239

[Batalov]

Thanks, Greg (and Jason, in the GPU thread) -- that's good enough.
(I have a 6.3e-14 poly from pol51, anyway.)
Then it was the old card that was the problem, not the code.

[jrk]

Originally Posted by jasonp

Technically the E value is the probability that one sieve value will be smooth, given the sieving area and the factor base bounds. That probability goes up with increasing factor base bounds, and may go up or down as the sieving area increases. Both pol5 and msieve fix all of those parameters, so that E values across factorizations are all directly comparable.

Are you talking about these values?:

        const double rfb_limit = 5000000;
        const double afb_limit = 10000000;
        const double sieve_area = 1e16;

Besides becoming incompatible with pol5, is there danger in raising these limits unconditionally? Say, would raising them make the score less accurate for smaller numbers? Please forgive my ignorance.

[jasonp]

Those three are what we're referring to.

The numbers are already used for inputs that are much smaller than would be appropriate if you actually used those values for the sieving, so I doubt it makes much difference.

In fact it might be cool to try to optimize those three at the same time that translation and skew are optimized, in the last part of stage 2; but I doubt that would work, because the E value would never drop as a result of a larger factor base. You'd need to add another term into the objective function that quantified the runtime of a siever, maybe by multiplying the E value by the number of relations needed and the time to find one relation. In that case the objective function becomes the total sieving time, which is really what we want to minimize, but now we're not dealing with a continuous function anymore.

[jrk]

Originally Posted by jasonp

Those three are what we're referring to.

The numbers are already used for inputs that are much smaller than would be appropriate if you actually used those values for the sieving, so I doubt it makes much difference.

In fact it might be cool to try to optimize those three at the same time that translation and skew are optimized, in the last part of stage 2; but I doubt that would work, because the E value would never drop as a result of a larger factor base. You'd need to add another term into the objective function that quantified the runtime of a siever, maybe by multiplying the E value by the number of relations needed and the time to find one relation. In that case the objective function becomes the total sieving time, which is really what we want to minimize, but now we're not dealing with a continuous function anymore.

I take it then that the final norm limit needs to be raised as well if the afb/rfb limit is increased. Quickly testing a c110 shows that increasing afb/rfb to 1e8 causes the 'e' score to be multiplied (vs using default alim/rlim) on average by about a factor of 91, and for a c129, about 152.

Is there a quick way to estimate how much to adjust the final norm limit for a given input size if afb/rfb are multiplied by fixed constant?

[jrk]

Originally Posted by jrk

Quickly testing a c110 shows that increasing afb/rfb to 1e8 causes the 'e' score to be multiplied (vs using default alim/rlim) on average by about a factor of 91, and for a c129, about 152.

And for a c151, about 330. So it is not a log scale factor w.r.t. input length.

[jrk]

Looks like the factor that is needed to scale the 'e' cutoff when afb/rfb are increased to 1e8 fits nicely to this curve:

3.15 * exp(0.0134 * log(N))

(for degree 5 at least, did not check degree 4 or 6)

Later tonight I will re-test some polys using the new score and see if they are ordered more accurately (according to their sieving speed).

[jrk]

It turns out that scaling the 'e' cutoff by the factor written above does not work as expected. No polynomials are found then, even though polys scoring higher than the scaled cutoff can be found otherwise

(e.g. there is a 3.17e-10 with the new scoring but it isn't found when the cutoff is 2.69e-10). Something else is happening. Perhaps no scaling is needed at all, then?