Their best is 3.51e19; the full 5000 will probably take 5 days on one core

Size optimization finished on batch 1 (nearly 48h wallclock time for 4 processes on Xeon E31230, 2 processes finished ~30' earlier) and batch 8 (~44h30 wall clock time for 8 processes on FX8150; 6 processes finished 2h earlier).
FWIW, both runs used MPIpatched msieve with a single .dat.m input file, so poily's latest patch works for me :wink: MPI root optimization has started. EDIT: BTW, poily, it would be great to make the same kind of change for root optimization as you did for size optimization: the ability to trigger multiprocess root optimization from a single input file, if no .dat.ms.mpi* files are found :wink: 
I suddenly have two [i]more[/i] cores that are free, so I'm taking batch 6. (I suppose it will take 4 days to do, using half the cores.)
PS If we do the root sieve, do you want the sizeopt hits as well as the final polys? Edit: When using `split n`, be sure to right `split n l/2` as opposed to `split n 2`. That doesn't split lines :razz: 
i'm far from being done, but so far best poly give 2.837e019
[code] # norm 5.520074e020 alpha 12.511594 e 2.837e019 rroots 4 skew: 81766141.19 c0: 3607869805213281554823252296618828604677914930359987025344 c1: 23220164568489045138114308221677930169305838193010240 c2: 9203124297129543437723323024998562111194036 c3: 9334995343944464727631510927880010416 c4: 324816754181582556026397511033 c5: 2223278394876459083044 c6: 7232286821760 Y0: 6203084729795742043403960083120441126010795 Y1: 42260925725431380236248723 [/code] 
The three best polys, in batch 1 (processed by the Xeon E31230 with 8 processes in ~29h wall clock time, 7 of the 8 processes finished at 1617h) are
[code]# norm 6.453437e20 alpha 12.047099 e 3.248e19 rroots 6 skew: 84355332.37 c0: 40946290090445266551161549499305741933274180644750016085425 c1: 10467357875909381144128954908126047238982795499683785 c2: 575409405642562087310720821835776371535397053 c3: 9572582929973485805475819618000250061 c4: 148894749080944910994034682372 c5: 724347752270183267004 c6: 1859803545600 Y0: 7778737956208683626717082871144859356558432 Y1: 10686505327134712299646993[/code] [code]# norm 6.056026e20 alpha 11.631907 e 3.052e19 rroots 4 skew: 48793635.82 c0: 9335896655809604327925621788999250854933506382363022965344 c1: 1925306846817736254699271114907020489847742878092288 c2: 169310545848405710260883307959917839585756986 c3: 3496004302313744686041859045254926483 c4: 275085812586209584750675391032 c5: 1408333791906605513980 c6: 478010332800 Y0: 9755452962557811620933593496014011645343335 Y1: 4282423141698728009631007[/code] [code]# norm 5.969626e20 alpha 11.556799 e 3.019e19 rroots 6 skew: 47942131.68 c0: 18012875627631792901670781168326202449068477209742252483200 c1: 1457681444502169713650799905383394058738666204734748 c2: 139260042798502345861170120050843951277513880 c3: 5797429652761017495601014198560882931 c4: 259974699150207277836260389632 c5: 1402165548484195645180 c6: 478010332800 Y0: 9755452962567021682782058132587572724643997 Y1: 4282423141698728009631007[/code] The best poly produced from batch 8 (FX8150, ~25h wall clock time, 7 of the 8 processes finished around 15h) has larger norm but worse e: [code]# norm 6.632671e20 alpha 11.607950 e 2.967e19 rroots 4 skew: 49069361.13 c0: 28745311041103203356576951005989940082831495232341768515776 c1: 205998030496036644387588200533512340837882272321360 c2: 132018394189437555571701225591789662744633256 c3: 1365610013934000246262086253251260366 c4: 19443724695135903573441283643 c5: 392511937028479386086 c6: 5858173601280 Y0: 6424804940317563889082609710168513250186575 Y1: 451681905409118609701262291[/code] 
[QUOTE=firejuggler;328350]i'm far from being done, but so far best poly give 2.837e019
[code] # norm 5.520074e020 [B]alpha 12.511594[/B] e 2.837e019 rroots 4 [/code][/QUOTE] This is crazy. The young 'uns may not know it but there was a time when alpha < 5 was considered really lucky. 
and what does it say about my personality? (no seriously... what does the low alpha mean? I won't ask about double rainbow, don't worry)
and for the sake of it my lowest alpha value [code] # norm 4.628932e020 alpha 12.956412 e 2.448e019 rroots 4 skew: 111461741.54 c0: 4596185303540975912941768799404404251911067990661592486450560 c1: 280987050579580684349518348073004894589766436497544888 c2: 5453326966044145207308567141134658983582007302 c3: 92528123968159463596593396717045851089 c4: 560963993141923165266152827450 c5: 2978793911777564174904 c6: 6711846261120 Y0: 6280776226247745384246196650168744854827871 Y1: 80764498754829792133232269 [/code] new record holder for my batch [code] # norm 5.554255e020 alpha 12.726487 e 2.853e019 rroots 4 skew: 88161163.72 c0: 592294109350104075885455758432520983785765035911272504595840 c1: 44228198432626906079450591344684081042731028765034896 c2: 1266780839981054007483109448136912523638841412 c3: 25584881562241130646568639974012624680 c4: 32136804857417066806626443393 c5: 3165936771052409436964 c6: 7232286821760 Y0: 6203084730713792276611133070779722382751981 Y1: 42260925725431380236248723 [/code] not terribly better, I know 
The alpha value is a measure for how many very small prime factors the polynomial values contain on average. We are looking for smooth polynomial values (= no large prime factors), and there will be more of those in the search region if the polynomial values tend to contain a lot of very small primes. The alpha value tells that, thanks to having many small primes, polynomial values F(a,b) are about as likely smooth as as an integer around F(a,b)*exp(alpha), so with alpha=12, the polynomial values are about as likely to be smooth as if they were smaller by a factor of ~16000.

1 Attachment(s)
Hm, I was under impression the patch should also work for poly root optimization... But it didn't due to copypaste mistype, here's fixed version of the patch.
I finished the batch 7, started poly root optimization of best 5000. 
The other thing that really jumps out at me from the list of best polynomials is that all of them are coming from stage 1 hits found by the CADO tools. I think the Msieve hits are the ones with lots of highorder zeroes in the leading algebraic coefficient, and in all the stage 2 that I've run locally the best E value I've been able to find from an Msieve stage 1 hit is around 3e19.
Paul has been suggesting that targeting a leading rational coefficient size that is somewhat smaller than the maximum possible, for a given choice of stage 1 size bound, gives a better chance of a good polynomial after size optimization. Looks like I should try a few experiments. I think all of modern GNFS polynomial selection is basically a struggle to increase the amount of skew without making stage 1 stop working; the end result is a playground of absurd alpha values. It doesn't hurt that the playground is enormously larger now that we're in degree6 territory (an alpha value < 5 is still pretty unusual for degree5 polynomials). Shi Bai's dissertation found that for RSA768 a large sampling of sizeoptimized polynomials had a mean alpha value of 0.2 and standard deviation of about 0.8; so finding an alpha value of say 10.0 is a 12sigma event. 
Here's another 9.5 million. I've stopped it for now.
[url]https://www.dropbox.com/s/meef9g9dkq1j0pz/rsa896_4.dat.m.gz[/url] 
All times are UTC. The time now is 22:58. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.