GPU polynomial selection, extreme edition

[Batalov]

Originally Posted by debrouxl

...CUDA allocates huge amounts of virtual memory, but uses very little of it

Bingo.
CUDA pretends to allocate huge amounts of virtual memory - *always*. You can check any CUDA application (including all of the PrimeGrid gpu apps, and of course mfaktc and CUDALucas). Some of us ran them all.

There may be some internal call to make it stop pretending -- but it is a cosmetic thing. It really doesn't use it.

Cpu(s):  0.7%us,  0.3%sy, 98.9%ni,  0.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:     16077M total,    14375M used,     1701M free,      464M buffers
Swap:     8187M total,        0M used,     8187M free,    11351M cached

  PID USER      PR  NI  VIRT  RES  SHR S   %CPU %MEM    TIME+  P  SWAP nFLT nDRT COMMAND
 6251 root      20   0 28.1g  12m 5384 S      0  0.1  93:28.67 4        90    0 boinc
12093 serge     20   0 28.1g  46m  18m T      0  0.3   0:01.98 2  28g    4    0 GeneferCUDA
12094 serge     20   0 28.1g  46m  18m T      0  0.3   0:00.00 2  28g    0    0 GeneferCUDA
...etc, e.g. mfaktc

[xilman]

Originally Posted by Batalov

There may be some internal call to make it stop pretending -- but it is a cosmetic thing. It really doesn't use it.

Yes and no. Some operating systems allocate swap space based on the VM usage. Such systems can run into serious problems if an applications pretend they wish to use vastly more memory than they do in practice.

[Batalov]

That's a good point. - if this is a real value.

I suspect that it is really an OS reporting issue, though. (top [or ps -ealf] merely reports what OS kernel thingies tell it, but it may be misinterpreting what the NVIDIA driver that is plugged into kernel tells the kernel... that's a pure speculation. No time for googling, Dr. Jones.) My belabored point was that five-seven popular programs written by different authors (all with good reputation and coding practices) show the same symptoms.

[debrouxl]

Running root optimization on the polynomials produced for L1378 (C163) in 15 GT540M minutes produced several flares above 1e-12, the best one being

R0: -134825682608863836023447416351593
R1: 56733343012153357
A0: -144444957608110084026863042074597515644266000
A1: 1200529404987000239112555461613643500
A2: 9859244668373197761123704696
A3: -53719812647360942973
A4: -129622286734
A5: 72
skew 321455485.99, size 9.524e-16, alpha -8.400, combined = 1.083e-12 rroots = 5

In CPU-days, the best that polsel5 had produced was:

skew: 592795.71
# norm 1.01e+23
c5: 532249140
c4: -248879344732604
c3: -1206402050592703197287
c2: 81313550902775921744220510
c1: 78668809459566613994208640605912
c0: -8238356642097791539804548047423071296
# alpha -6.63
Y1: 17618391595787698177
Y0: -5701855317702382982622720266899
# Murphy_E 8.11e-13

I'll tell the person who performed polynomial selection.


FWIW, in the .dat.ms file, of the 1613 polynomials (1509 unique), 28 have norm between 1e21 and 1e22, and the rest has norm above 1e22. None of the size-optimized hits with norm above 1e22 has contributed any polynomial to the final result: the full set and the reduced set have produced files which have the same size. The upper bound on the norm, for keeping the stage 1 + size optimization result, may be a bit high ?

[frmky]

On the C180, overnight I ran
./msieve -np1 "min_coeff=10000 stage1_norm=1e26" -nps -npr -v

I chose this stage1 norm by lowering it until only a slow trickle of hits, 1 every few seconds, accumulated in msieve.dat.ms when run without -npr. I then added -npr and ran it overnight. It searched coeff from 10000-2308068 overnight, and it found 112 polynomials. Unfortunately this didn't give anything better than I had already found. The 10 best overnight were

# norm 1.609924e-17 alpha -6.682848 e 9.393e-14 rroots 5
# norm 1.460274e-17 alpha -6.101288 e 8.953e-14 rroots 3
# norm 1.460274e-17 alpha -6.101288 e 8.953e-14 rroots 3
# norm 1.429868e-17 alpha -6.027727 e 8.770e-14 rroots 3
# norm 1.414912e-17 alpha -5.994256 e 8.708e-14 rroots 3
# norm 1.392168e-17 alpha -5.632756 e 8.648e-14 rroots 3
# norm 1.353708e-17 alpha -6.203593 e 8.392e-14 rroots 5
# norm 1.327999e-17 alpha -6.246455 e 8.307e-14 rroots 3
# norm 1.310630e-17 alpha -6.112107 e 8.226e-14 rroots 5
# norm 1.291233e-17 alpha -6.017755 e 8.134e-14 rroots 5

with the best being

# norm 1.609924e-17 alpha -6.682848 e 9.393e-14 rroots 5
skew: 29423873.34
c0: 1447569421580328755975083928524168482814016
c1: 940956812105196620760067954840917188
c2: -171439410731435927807369135092
c3: -119357929588159904699
c4: 181966997721236
c5: 1159536
Y0: -45925768838163524607487262843181501
Y1: 8256671793614417

While the 10 best from an earlier search yielded

# norm 1.865586e-17 alpha -6.364541 e 1.047e-13 rroots 5
# norm 1.831708e-17 alpha -6.556447 e 1.037e-13 rroots 3
# norm 1.792160e-17 alpha -6.370706 e 1.020e-13 rroots 5
# norm 1.805045e-17 alpha -6.230405 e 1.009e-13 rroots 5
# norm 1.748545e-17 alpha -6.603055 e 1.007e-13 rroots 3
# norm 1.740781e-17 alpha -6.100284 e 9.963e-14 rroots 5
# norm 1.697462e-17 alpha -7.037334 e 9.832e-14 rroots 3
# norm 1.668744e-17 alpha -6.235448 e 9.757e-14 rroots 3
# norm 1.650505e-17 alpha -6.209273 e 9.661e-14 rroots 5
# norm 1.646463e-17 alpha -6.520661 e 9.656e-14 rroots 3

with the best being

# norm 1.865586e-17 alpha -6.364541 e 1.047e-13 rroots 5
skew: 115371823.59
c0: -13031510749541527373838317314004889545180224
c1: 4346920293444856845184820183496193240
c2: 21275953702008787746349840478
c3: -1517307953666691442834
c4: -1667150132179
c5: 19404
Y0: -104072270739531074107036134995084355
Y1: 11417459397746012741

[frmky]

Originally Posted by debrouxl

Running root optimization on the polynomials produced for L1378 (C163) in 15 GT540M minutes produced several flares above 1e-12, the best one being

The skew is a bit large. Using a larger starting coefficient should bring that down.

[rcv]

Originally Posted by debrouxl

Who has good GNFS candidates between difficulty 140 and 210, so that we can tighten the bounds for existing jobs, before setting our sights on the 200+-digit RSA numbers (in several steps, from RSA-210 to RSA-896 and above) ?

There are about 70 Brent Table composites (of the kind being reserved in this thread) ranging from 147 to 175 digits for which GNFS is better than (or about equal to) SNFS. That same thread has some (limited) educated guesses on the amount of ECM that has been performed. Maybe "first holes" are more ripe than others?!? [Xilman, on the other hand, *knows* how much ECM his numbers have received.]

[xilman]

Originally Posted by rcv

[Xilman, on the other hand, *knows* how much ECM his numbers have received.]

Well, by and large that's the case. Some ECM has been run but not reported to me in detail. Xyzzy, for instance, has found a good few factors over the years but I don't really know how much work he's done to find them. Mike's not the only such contributor.

However, I have a very good idea of the minimum work done and my estimates are likely no more than 5% below reality.

[Xyzzy]

Xyzzy, for instance, has found a good few factors over the years but I don't really know how much work he's done to find them.

It really wasn't much work at all. We just asked the computer to work on them and it did all the hard stuff.

[xilman]

Originally Posted by Xyzzy

It really wasn't much work at all. We just asked the computer to work on them and it did all the hard stuff.

I 'll rephrase that. I don't know how much work has been done by Xyzzy's computer(s).

[ixfd64]

I don't do NFS, but this is incredible. Well done, Jason!