Pascal's OPN roadblock files - Page 40

chris2be8 · 2016-04-01, 15:47

135676061629^19-1 is done:

Code:

p68 factor: 79635064094310037830645808630238979916842816602955253387792094206661
p122 factor: 24278112974759485763933791981097601121853224166709762343101936275633631974531044244600392566770714905096375091798556447233

There are a few numbers left in the most wanted list that are small enough for me to do. So reserving:
151068118561^19-1

Chris

chris2be8 · 2016-04-04, 15:33

53041017196666952234619819994982127672443220243418249007541741030212106804476059^3-1 is done:

Code:

p64 factor: 1083000123107068270733009827376476882510958865270189171822077137
p94 factor: 1091944940457896832937775063909880834458528001568212121577251753071393980783500894064924253967

And reserving:
6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1

Chris

chris2be8 · 2016-04-07, 15:54

321381569252585866953628783126948367071187906389518216907098417372109834635071531^3-1 is done:

Code:

p71 factor: 29032391505219456656574077295856600917457813817735894170745004802770829
p87 factor: 130655419999791598455282873249671150644436326030004224752728322966413022058935308204173

Chris

chris2be8 · 2016-04-14, 15:55

151068118561^19-1 is done:

Code:

p86 factor: 13168251261447086222529106003413582219673091219134273228635229205633692974206401006811
p117 factor: 127521279955406778018268352684989547268937847439690196654027039726274513550542345907805063608735355562846772849462089

Chris

chris2be8 · 2016-04-17, 15:45

6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1 is done:

Code:

p64 factor: 6144947125025633693162221212151808353911892992946890145396846651
p93 factor: 171502932285504588894559496321471476064429992828722843243067496208336947767466817848733178063

Chris

RichD · 2016-05-05, 01:44

This is a followup to this post.

I tried 3LPB with some success. The following polynomial & parameters were used:

Code:

n: 93279832932678885982491327274510953769646671804250585173949381396533884838015343380578179958902524702743577609136955094165823424785868918382341305541015034575413635998174157065849573034448811318011391066252444362245200432150814809755443305857
skew: 1
c8: 1
c7: 1
c6: -7
c5: -6
c4: 15
c3: 10
c2: -10
c1: -4
c0: 1
Y1: 1327736012762191
Y0: -1762882919585641022025519120482
alim: 90000000
rlim: 90000000
lpba: 31
lpbr: 31
mfba: 93
mfbr: 62
alambda: 3.6
rlambda: 3.6

I ran trial sieve on 5K blocks at various intervals. The algebraic side was the better performer.

Code:

special-Q
    30M   80M  130M  180M  230M  280M  330M  380M  430M  480M  530M  580M  630M  680M
algebraic side ( -a )
   4153  2416  1681  1608  1283  1383  1204  1257  1006   925  1071   860   904   566
rational side ( -r )
   2324  1264  1090   812   695

With such low yields, and to get to the needed 200M+ relations, one would have to sieve to over 900M using the 14e siever. Not very efficient.
By doing a little sieving on the rational side, say 30-220M, then 45-50M rels could be picked up on that side. Meaning the algebraic side could stop around 550M.
It would appear this is a two part sieving project. Accumulate 75-80% on the algebraic side and the rest on the rational side.

This is all inefficient compared to the traditional yields. Is there something that can be improved upon?

VBCurtis · 2016-05-05, 05:42

If I understand the parameter meanings correctly, the lambdas are only increased from 2.6 or 2.7 to 3.6 when using 3LP. So, I think rlambda should be 2.7 rather than 3.6, since that side is 2LP. I'm not certain about this, but the CADO helpfiles had an explanation of lambda that leads me to believe this. Surely someone will be kind enough to correct me if I'm mistaken...

With yield that low, I'd use 15e if I were doing it myself; but then, I'd also use 32 bit large primes and aim for 300-320M rels rather than 31bit and 200M. Yield should improve by 75% while only needing ~60% more relations. But I imagine this will be NFS@home, so the 14e queue will be the choice.

A not-quite-relevant data point: I just completed a SNFS-241 with 15e/32, needing 290M raw relations to build a TD 104 matrix of size 8.3M. I didn't try larger target densities.

RichD · 2016-05-05, 13:19

I was thinking, without looking into it closely, that 32 bit jobs would need around 400M rels. Since the yield didn’t (nearly) double, I abandoned that road. Though I seem to recall it was in the neighborhood you mentioned. Further data points are needed.

rlambda=2.7 is an oversight on my part. Since I rarely work with 3LP jobs it slipped my mind.

In the coming weeks I will try to refine my testing with these suggestions.
Thanks.

RichD · 2016-05-05, 13:47

Now I am confusing myself. On my other box I found the following parameters in the poly file.

Code:

rlim: 90000000
alim: 90000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 93
rlambda: 2.6
alambda: 3.6

Not sure which one I used to collect the data points I posted earlier. Arg!

chris2be8 · 2016-05-05, 15:53

You might want to increase alim as well as using 3LP on that side.

Also consider raising lpba to 32 as follows (that should need about 50% more relations than lpba=lpbr=31):

Code:

lpba: 32
lpbr: 31
mfba: 96
mfbr: 62
alambda: 3.6
rlambda: 2.6

A related question, here's some output from the siever for a gnfs 101 job:

Code:

Thu May  5 17:30:51 2016=>nice -n 19  "/home/chris/lasieve4_64/lasieve4I12e" -F -o spairs.out -v -n0 -a m101-22720408341975460027074353838899663659623294490773487546911374704466493450000974597687616799147775773.job
gnfs-lasieve4I12e (with asm64): L1_BITS=15, SVN $Revision$
FBsize 105499+0 (deg 4), 135071+0 (deg 1)
total yield: 45404, q=1380007 (0.00302 sec/rel)
710 Special q, 1053 reduction iterations
reports: 191668545->21803968->19707101->8139549->4931453->2904500
Number of relations with k rational and l algebraic primes for (k,l)=:

Total yield: 45404
0/0 mpqs failures, 584/49 vain mpqs
milliseconds total: Sieve 40060 Sched 0 medsched 22650
TD 32890 (Init 3600, MPQS 5170) Sieve-Change 41520
TD side 0: init/small/medium/large/search: 910 3690 1110 1650 8120
sieve: init/small/medium/large/search: 2560 10140 1150 5640 2550
TD side 1: init/small/medium/large/search: 430 2410 1160 1350 3030
sieve: init/small/medium/large/search: 1030 5830 1370 5300 4490

What does it all mean? In particular can it be used to tell if raising (or lowering) bounds on one side would be desirable? I'm particularly curious about TD side 0 vs TD side 1.

Chris

RichD · 2016-05-26, 15:44

Thanks for the suggestions chris2be8. Hopefully in the coming days I will get back to this.

I noticed the roadblock files have recently been updated.
The best way to access them are through OPN Homepage and click on the "Pascal's site" link in the third section.
Because several of the "T-file" names have changed (in the Composites section).

2016-04-01, 15:47	#430
chris2be8 Sep 2009 3²×233 Posts	135676061629^19-1 is done: Code: p68 factor: 79635064094310037830645808630238979916842816602955253387792094206661 p122 factor: 24278112974759485763933791981097601121853224166709762343101936275633631974531044244600392566770714905096375091798556447233 There are a few numbers left in the most wanted list that are small enough for me to do. So reserving: 151068118561^19-1 Chris

2016-04-04, 15:33	#431
chris2be8 Sep 2009 3²×233 Posts	53041017196666952234619819994982127672443220243418249007541741030212106804476059^3-1 is done: Code: p64 factor: 1083000123107068270733009827376476882510958865270189171822077137 p94 factor: 1091944940457896832937775063909880834458528001568212121577251753071393980783500894064924253967 And reserving: 6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1 Chris

2016-04-07, 15:54	#432
chris2be8 Sep 2009 3²×233 Posts	321381569252585866953628783126948367071187906389518216907098417372109834635071531^3-1 is done: Code: p71 factor: 29032391505219456656574077295856600917457813817735894170745004802770829 p87 factor: 130655419999791598455282873249671150644436326030004224752728322966413022058935308204173 Chris

2016-04-17, 15:45	#434
chris2be8 Sep 2009 100000110001₂ Posts	6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1 is done: Code: p64 factor: 6144947125025633693162221212151808353911892992946890145396846651 p93 factor: 171502932285504588894559496321471476064429992828722843243067496208336947767466817848733178063 Chris

2016-05-05, 01:44	#435
RichD Sep 2008 Kansas 6500₈ Posts	1327736012762191^17-1 This is a followup to this post. I tried 3LPB with some success. The following polynomial & parameters were used: Code: n: 93279832932678885982491327274510953769646671804250585173949381396533884838015343380578179958902524702743577609136955094165823424785868918382341305541015034575413635998174157065849573034448811318011391066252444362245200432150814809755443305857 skew: 1 c8: 1 c7: 1 c6: -7 c5: -6 c4: 15 c3: 10 c2: -10 c1: -4 c0: 1 Y1: 1327736012762191 Y0: -1762882919585641022025519120482 alim: 90000000 rlim: 90000000 lpba: 31 lpbr: 31 mfba: 93 mfbr: 62 alambda: 3.6 rlambda: 3.6 I ran trial sieve on 5K blocks at various intervals. The algebraic side was the better performer. Code: special-Q 30M 80M 130M 180M 230M 280M 330M 380M 430M 480M 530M 580M 630M 680M algebraic side ( -a ) 4153 2416 1681 1608 1283 1383 1204 1257 1006 925 1071 860 904 566 rational side ( -r ) 2324 1264 1090 812 695 With such low yields, and to get to the needed 200M+ relations, one would have to sieve to over 900M using the 14e siever. Not very efficient. By doing a little sieving on the rational side, say 30-220M, then 45-50M rels could be picked up on that side. Meaning the algebraic side could stop around 550M. It would appear this is a two part sieving project. Accumulate 75-80% on the algebraic side and the rest on the rational side. This is all inefficient compared to the traditional yields. Is there something that can be improved upon?

2016-05-05, 05:42	#436
VBCurtis "Curtis" Feb 2005 Riverside, CA 2·2,437 Posts	If I understand the parameter meanings correctly, the lambdas are only increased from 2.6 or 2.7 to 3.6 when using 3LP. So, I think rlambda should be 2.7 rather than 3.6, since that side is 2LP. I'm not certain about this, but the CADO helpfiles had an explanation of lambda that leads me to believe this. Surely someone will be kind enough to correct me if I'm mistaken... With yield that low, I'd use 15e if I were doing it myself; but then, I'd also use 32 bit large primes and aim for 300-320M rels rather than 31bit and 200M. Yield should improve by 75% while only needing ~60% more relations. But I imagine this will be NFS@home, so the 14e queue will be the choice. A not-quite-relevant data point: I just completed a SNFS-241 with 15e/32, needing 290M raw relations to build a TD 104 matrix of size 8.3M. I didn't try larger target densities.

2016-05-05, 13:19	#437
RichD Sep 2008 Kansas 3392₁₀ Posts	I was thinking, without looking into it closely, that 32 bit jobs would need around 400M rels. Since the yield didn’t (nearly) double, I abandoned that road. Though I seem to recall it was in the neighborhood you mentioned. Further data points are needed. rlambda=2.7 is an oversight on my part. Since I rarely work with 3LP jobs it slipped my mind. In the coming weeks I will try to refine my testing with these suggestions. Thanks.

2016-05-05, 13:47	#438
RichD Sep 2008 Kansas 2⁶×53 Posts	Now I am confusing myself. On my other box I found the following parameters in the poly file. Code: rlim: 90000000 alim: 90000000 lpbr: 31 lpba: 31 mfbr: 62 mfba: 93 rlambda: 2.6 alambda: 3.6 Not sure which one I used to collect the data points I posted earlier. Arg!

2016-05-26, 15:44	#440
RichD Sep 2008 Kansas 2⁶·53 Posts	Thanks for the suggestions chris2be8. Hopefully in the coming days I will get back to this. I noticed the roadblock files have recently been updated. The best way to access them are through OPN Homepage and click on the "Pascal's site" link in the third section. Because several of the "T-file" names have changed (in the Composites section).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Passive Pascal	Xyzzy	GPU Computing	1	2017-05-17 20:22
Tesla P100 — 5.4 DP TeraFLOPS — Pascal	Mark Rose	GPU Computing	52	2016-07-02 12:11
Nvidia Pascal, a third of DP	firejuggler	GPU Computing	12	2016-02-23 06:55
Calculating perfect numbers in Pascal	Elhueno	Homework Help	5	2008-06-12 16:37
Factorization attempt to a c163 - a new Odd Perfect Number roadblock	jchein1	Factoring	30	2005-05-30 14:43